5 ms·

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 justifi

by flomo 7y ago

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.

tjpnz 7y ago
>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.
- kyriakos 7y ago
  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.
  - cheschire 7y ago
    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.
    - hvidgaard 7y ago
      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.
      - y4mi 7y ago
        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
        hvidgaard 7y ago
        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.
        deleted 7y ago
        [deleted]
        y4mi 7y ago
        > 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
        hvidgaard 7y ago
        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.
- onyva 7y ago
  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.
tracker1 7y ago
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.
- casselc 7y ago
  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 https://docs.microsoft.com/en-us/aspnet/config-builder
cyxxon 7y ago
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...

by flomo 7y ago

tjpnz 7y ago

>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.

kyriakos 7y ago
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.
- cheschire 7y ago
  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.
  - hvidgaard 7y ago
    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.
    - y4mi 7y ago
      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
      - hvidgaard 7y ago
        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.
        deleted 7y ago
        [deleted]
        y4mi 7y ago
        > 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
        hvidgaard 7y ago
        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.
onyva 7y ago
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.

tracker1 7y ago

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.

casselc 7y ago
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 https://docs.microsoft.com/en-us/aspnet/config-builder

cyxxon 7y ago

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...