|
> who is going to pay for the person to patch it every week, or upgrade it to the latest version, or upgrade the SAN disk, or upgrade the hardware every 3 years, etc. etc. Let's take this a step further - who is going to hire these people? And fire them? And train them? These are all transactions costs that get hidden in the "$0.20/hr cost" of spinning up an EC2 instance. You're implicitly arguing that NoOps is not only a functional model, but also scalable and much less costly than having a {Dev|Sec}Ops staff. The last time this was publicly debated between Adrian Cockcroft and John Allspaw, it was immediately obvious to everyone that there is no such thing as NoOps. You can have developers support their own apps in production on the cloud, but that takes away time from developers and comes with its own set of downsides (most prominently, a disinterest in what they consider mundane or boring). Once your developers are spending, in aggregate, more than 40 hours a week do ops work, you'll gain efficiency by hiring a DevOps Engineer whose entire career focus is all the things developers aren't typically great at. I've seen this in-person as an employee at medium, large, and a Fortune 50 business. I haven't yet seen a single app, not even serverless, that requires zero maintenance. I have also seen highly-distributed, performant apps run on cheap hardware with no SAN or VMware to drive up the cost and complexity. That same app, made up of mostly microservices, was much more expensive to run on on the cloud. You might want to stop throwing around terms like TCO when you also clearly don't understand how to calculate it. I'm starting to be of the mindset that us-east-1 is already "Too Big To Fail". I guarantee you that conversations are being had in boardrooms right now about how to reduce dependency on that region, if not AWS entirely. |
If you're not blasting your AWS account manager and asking what their plans are to avoid this happening in the future, then your CTO is not doing their job.
If AWS itself is not internally working out how to "get off us-east-1" for its global services, then it is failing in its role as infra provider.
AWS has a lot of stuff about how to make your infra redundant and resilient to failure, in their environment, mostly about replicating across AZs and then across regions.
The fact that their "global" services are not actually "global" but are "everything goes to us-east-1" is broken and if they're not fixing it, then that is when you start looking at other alternatives.