I just finished convincing old-school management to move to Office365/Azure/Teams after we've been doing everything on-premise, saying we can reduce our maintenance and increase in reliability since we're a small operation. Needless to say this isn't a good look for me.
If it makes you feel any better, I've been that guy on both sides of the coin - both on the cloud and on-prem. Things go down.. even the cloud.
I worked for a company, where I really did have nearly 100% uptime at my local data center in our office. I wasn't a luddite, and the cloud wasn't something I was afraid of or didn't understand. I just, at the time, had an infrastructure in place before the cloud existed, and it worked well enough at a great price point. We were on the same electrical grid as a hospital, our infrastructure handled our scale, and just really didn't have problems for a long span of time.
Still, someone came in and said.. what, you are still doing stuff on-prem and not the cloud!? How legacy! How dated! And so the push to the cloud came next.
We migrated to the cloud (and some colo facilities for some equipment we chose to keep), and on the 3rd day of being freshly migrated, the cloud provider had a major outage and went down for longer than we'd ever had on prem. The next month, the colo went down and their diesel generators failed, and it was down for an entire afternoon.
Oh sure, there was some SLA money returned in that event from the colo...
I'm just saying, I've been on both sides. Tell them the truth - even the cloud has outages, but it is certainly more "convenient" to have hundreds of engineers work on fixing an outage at global scale, and all you have to do is wait for it to start working again - then it is to have to fix it all yourself.
> Tell them the truth - even the cloud has outages, but it is certainly more "convenient" to have hundreds of engineers work on fixing an outage at global scale, and all you have to do is wait for it to start working again - then it is to have to fix it all yourself.
Yep, that’s the argument I’ve made, both to management and even our non-techie customers. When we show them our new SaaS product, they get concerned about cloud outages. Our response is “if AWS goes down, you have bigger things to worry about since other things will be down too.”
The plus side I’ve mentioned that our company’s software developers are freed from doing network IT maintenance and infrastructure and can continue focusing on our actual core products instead.
Why are your software developers doing "network IT maintenance and infrastructure" in the first place? Is it because of "DevOps" maybe?
It's one thing to experience the sysadmin practise getting taken over by developers. The next thing is usually the latter needing to be "freed" from this burden... Seems like a big fad.
The variable here is not just the size & skill of the team but their needs. In most cases a single company or team will need a simpler, smaller-scale deployment, probably running on one or a handful of machines and not requiring the insane complexity that a public cloud provider is running behind the scenes to provide their service.
This eliminates a lot of moving parts and things that can fail. Imagine an Nginx server running on a single machine. There's very little that can go wrong here beyond hardware failure (and certain types of failures can be mitigated with things like RAID), and yet it is probably enough to host most internal websites.
Now compare this to something like Azure App Service which is obviously more complex to be able to support many tenants, load-balance, etc. There is much more that can go wrong with the entire App Service infrastructure (due to its complexity and moving parts) than with a single machine running Nginx, and the complexity will also delay disaster recovery efforts (this outage is now lasting for more than an hour - you can reinstall an entire Linux web server from scratch in half that time).
If they have enough resources. When everyone is busy working on the revenue generating products for the company, taking time away to work on internal network infrastructure immediately becomes a cost center.
Microsoft Teams (The chat/collaboration service) and team foundation server (The source code repository and DevOps platform) are two completely different products that happen to both have the same word in their name. Although I can understand the trauma ;-)
