[scarface74]

A serious enterprise is not going to bet their cloud infrastructure on Linode. AWS offers a lot more than just a bunch of hosted VMs.

A serious CTO whose neck is on the line is not going to go with a small player.

To paraphrase an old saying.

“No one ever got fired for buying AWS”

For an MS shop, the same could be said for Azure.

[mr_toad]

If you go with AWS because they have the best SLA, or GCE because they have better managed K8 offerings, then fine.

But going with AWS because ‘no-one ever got fired’ for it, or picking Azure because you play squash with a guy from Microsoft’s sales team is just lazy. Not that I’m saying it doesn’t happen.

Forbes and Gartner might ignore the other players, doesn’t mean we can’t be better informed.

[scarface74]

Well, let’s look at where the phrase originated and how that turned out.

If someone had bought a mainframe IBM system in 1980 to run their COBOL system over their competitor, 40 years later, they could still buy a compatible system from IBM. It’s competitors - not so much.

On the other hand, idealism has its place, but when things hit the fan because of your choice of vendors, it’s a lot easier to justify a buying decision by saying the vendor was in the second quadrant of Gartner’s Magic Square.

[pas]

more than VMs. yes, and that's the vendor lock in part.

sometimes it's okay though.

but AWS monoculture is not a bright future.

[scarface74]

All of the services with no lock in

Elastic Cache - hosted Redis and Memcached

Aurora - compatible with MySQL and Postgres

RDS - hosted versions of Mysql, MariaDB, Sql Server, and Oracle.

Redshift - yes it uses a proprietary/columnar store engine but it is compatible with Postgres.

Etc.

But the bigger point is that you’re always locked into your infrastructure, do you think your CTO is going to move from their million dollar Oracle infrastructure because you used the Repository Pattern?

[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