Hacker News Reader

Comment by flomo | Hacker News Reader

Like 10 years ago, I thought it was great when we garnered a client which was one those "Microsoft only" type shops, because I like C#/NET. But the only justification for using it was really "IT made us do it". And I saw how the IT leadership in these places were older people perhaps maybe fighting older political battles. In any case its been many years since I've stumbled across a pure Microsoft shop. I think Azure means they know they lost, but also have legacy business to support.

View on HN

I work in a 99% MS shop, basically (well, apart from our SAP installations). Most of this was indeed setup like this due to homogenization (all our admins know everything, it all works together, no weird stuff on some servers, etc), but it has actually created a weird situation where we have some smaller services running on old unix servers and no real admin in the org... we actually have on older guy coming in once a week to check on these servers. If it wasn't so sad it was hilarious. I mean, I used to do some unix server stuff en years ago, but here I am an SAP dude, so while I do have some auths on one of those servers, I can probably basically restart some daemons and that's it.

Oh yeah, and iPhones. We have those - not complaining, really, but those were sold internally as "it looks better if we have those premium phones and not old junk". Ah well...

>But the only justification for using it was really "IT made us do it". And I saw how the IT leadership in these places were older people perhaps maybe fighting older political battles.

I've seen this happen too in predominantly Linux shops. In the early 2000s Microsoft worked hard to cultivate relationships with future IT leaders and those relationships have a way of enduring. Even if your CIO can't get everyone onto Windows they might still find a place for Office 365 without much time spent weighing up the alternatives.

That’s really how it works. I can attest to that as a former IT guy in a large organization. It’s a personal relationship with a clueless CTO. But to be honest, they’ve just replace IBM guys doing the same.

Big difference, IBM representatives actually knew their stuff. Microsoft would rely on its enterprise sales guys to cultivate this relationships, pushing CTO to make the most stupid decisions and using system engineers to sugar coat and hide the details.

I remember one being told off by a sales person when saying “yes, it’s a bug” in one of these sales pitches.

IT made them do it for good reasons though. Managing a large number of users and workstations in an enterprise environment is one of the things that Microsoft stack stands out.

Pull the boundaries in. Provide all of the enterprise services through the web. Provide hardened VMs for those services that can't be migrated. Suddenly your workstations are thin clients, and it doesn't really matter anymore if someone decides they want BYOD.

Now you can get after the actual interesting problem of intellectual property theft and corporate espionage. Things which the firewalls of old did nothing to prevent but provide a layer of obfuscation.

It's naive to think that just because your production critical software is web based, you can just have everyone BYOD. That is asking for rampant malware on the company network, and targeted attacks that steals company secrets.

You're completely missing the point. The internal network I'm describing should be nothing more than server metal and virtual workstations. Your border is miniscule at that point. You no longer have to fret about network ports in conference rooms. You no longer have to worry about testing your OS and software patches on the 20 iterations of lifecycle replacement hardware that is floating out in your company. You don't even need to invest heavily in workstations, as thin clients will suffice for most situations. Business continuity becomes a piece of cake because you're no longer factoring in the physical workstation beyond ensuring your cold site has a box of laptops in the corner.

Your concern about rampant malware won't even matter because the only way people can access the web services is through the VMs. The thin clients and physical workstations won't even be able to access most of those services that are mission critical.

In the situation where a company provided physical workstation is necessary, that machine would be just as isolated from the internal network as anyone else. Developers can use one of those, or use VMs that are VLAN'd off. And if your developers are automating their builds and containerizing, then your developers are going through layers of services and automation before their code goes out to production, so even they won't need access to production environments from their relatively insecure dev laptops.

From the lens of a programmer it's definitely possible to do BYOD without any real danger to the domain.

They need access to a few webfrontends and be able to use their SCM server...

But in order to do that, they'll have to be able to test locally or have a really hardened access to their servers. Significantly harder than just forcing everyone on company hardware without root/admin access

Developers get special treatment, because the nature of their work often require them to have local admin access. But the majority of people do not need that, and if I'm in charge of company network and security, I would not allow anything but approved machines on the internal network.

> Developers get special treatment, because the nature of their work often require them to have local admin access.

That is extremely rare at larger b2b enterprises

Each and every organization I've heard of that did that, reverted to give developers local admin pretty quickly because the requests to the IT administrators for every time a developer needed admin to install a required dependency, start whatever at admin to debug, change reg settings, test installations, ect.

Senior scientists in corporate R&D often require local admin access as well. The image analysis and spectum simulation programs I needed to run and keep updated were not on the radar for our corporate IT folks. They were very good at what they did and were cooperative when we explained our needs and showed that we were competent to manage our own systems and were willing to reach out and ask questions before doing something unfamiliar. Even in R&D, most chemists could use a standard workstation. It was mainly analytical chemists/material scientists working with specialized instruments and doing custom software development that needed local admin access.

“The company network” is no different from the coffee shop WiFi next door, just has more bandwidth.

We still restrict web access to company managed machines but it’s a layer, not an essential boundary.

Provide all of the enterprise services through the web.

Thats like 10 years of projects right there

I work in a mostly MS shop currently. Of course, all the orchestration scripts I've written for CI/CD etc around our projects are using Docker and Node. Then again, in the main project I'm on, everything I didn't make is .Net Framework and not Core... so going to spend months migrating the crap to actually make progress with some other needs.

There are some things I do like about C# and .Net ... the culture is rarely one of them. Though I still prefer it to Java for the most part.

Basically in the same boat. If you haven’t looked recently, the container support in Windows is getting much better - including prod support for Windows worker nodes in Kubernetes 1.14. But just using Docker with gMSAs was a big help to our CI/CD and simplifying/standardizing deployment of our apps which are a mix of legacy ASP.NET, WCF, and traditional Windows services.

If you can target at least 4.7.1 you can use configuration builders [0] to use environment variables/json/cloud parameter stores/etc to modify legacy web.config or appsettings without code changes. You can also use the .Net core config libraries directly in legacy .Net apps if the devs are willing.

[0] https://docs.microsoft.com/en-us/aspnet/config-builder

Reply on news.ycombinator.com