[pas]

AWS has quite a few other solutions that you haven't mentioned that are not so portable.

I'm not advocating simply ignoring AWS's strengths because let's say Lambda/EBS/ELB/etc. is proprietary, but this is a very real, very simple risk. As AWS can, it will raise prices.

And sure, maybe it doesn't matter because you can always just fall back to using whatever you use on simple VMs, and AWS will always have some competition in the simple VM hosting space and VM prices will therefore will be low.

However, I'm on the opinion that institutional inertia will "kick in" (to use a rather bad figure of speech for something that is about as agile as a drum of molasses) and will simply let AWS rent-seek.

[scarface74]

So you’re going to “move to the cloud” and just host a bunch of VMs.

Congratulations, you now have the worse of all worlds. You’re spending more than baremetal, you’re spending just as much on maintenance and management instead of letting someone else do the “undifferentiated heavy lifting” and your developers are moving slower than they would have if they took advantage of your cloud vendors offerings.

Win????

[pas]

You can't just "move to the cloud" by firing Ops people and giving an AWS account to your Devs.

Or, well, you can, but then don't forget to set your billing limit to infinity as well. Because AWS wants to make money.

Anyway, I'm not saying RDS/Aurora/etc. is bad, but eventually the heavy lifting will be available for anyone ( https://github.com/beekhof/rss-operator and similar projects ), and it's not like AWS likes to pay when they don't perform according to their SLA.

[scarface74]

There is more to the cloud than “managed Kubernetes”.

While you can’t fire all of your ops you can reduce the headcount by a combination of managed services/servers, automation, outsourcing to managed service providers, and an auto healing fault tolerant infrastructure