My first maxim I've been saying in comments is that "no one ever changes Infrastructure just to save a few dollars". You architect with plans to do it, but 99 Times our of 100 you will do a risk rewards calculation and realize it's not worth it.
The second maxim is "no one ever got fired for buying IBM". If you're going to bet on a horse, there is always a chance that things go sideways. You might as well bet on the fastest horse with the best record.
If you had a choice between IBM, DEC VAX, and Stratus VOS back in the day and you went the safe route to go with IBM, you would have been vindicated two decades later. IBM is still selling compatible systems.
I could go through the trouble of staying "vendor neutral" and use tools like Consul+Vault with an AWS backend, Nomad, and Terraform (been there done that) but the time I'm wasting being vendor neutral, I can spin up equivalent services on AWS that cost less and I don't have to maintain them.
Most of the things that I depend on AWS for now, I was doing the equivalent of on prem before and after AWS existed. I'm glad to not have to do that anymore and just being able to press a few buttons.
This isn't "script all your resources in Terraform so you can move to Google Cloud, hypothetically". We're talking about a database system here. By now, we've learned many times over that an open-source platform is a huge benefit; if we're at the point where Microsoft is being forced to admit it via things like SQL Server and .NET Core, I'd say that the closed-source platform ship has more or less sailed at this point. Aurora moves you off an open platform and onto a closed one. This is a bigger concern than "Amazon probably won't shut it down tomorrow".
And on top of that, in the realm of database engineering, Amazon is absolutely a newcomer, they've got another good 15 years before they can even start to be in contention for "reliable and trustworthy database vendor". Goes doubly when you consider that Aurora is essentially just a bunch of performance hacks to (old versions of) InnoDB and Postgres. Presumably, upstreams like MariaDB and PostgreSQL have forgone similar enhancements for a better reason than "only Amazon employees are smart enough to figure it out".
> And on top of that, in the realm of database engineering, Amazon is absolutely a newcomer, they've got another good 15 years before they can even start to be in contention for "reliable and trustworthy database vendor"
They did hire a bunch of experienced engineers. I'd rather have them actually contribute to postgres (which amazon pretty much doesn't do, some bug reports aside).
> Presumably, upstreams like MariaDB and PostgreSQL have forgone similar enhancements for a better reason than "only Amazon employees are smart enough to figure it out".
Some of them are harder to do if you don't have as much control over the environment as amazon does...
Based on what I've heard, these aren't hacks on Postgres - more a pluggable storage engine. Haven't cross checked this, but I think both MySQL and Postgres have a swappable low level storage API. AWS has made engines that use their specific infrastructure to make all these changes - there are technically no changes in either the MySQL or Postgres engines themselves - only the storage layer.
That's why no announcements cover change fundamental change to either database - all the features we're seeing a the kinds you'd do on a personal scale with SSD RAIDs and ZFS (or other copy on write FSes), except on a datacenter scale.
There are millions of companies that still use SQL Server and Oracle. Open source is not the be all and end all.
Have you seen the code see to know that they are just “performance hacks”? Have you thought that when you can actually spend millions on a project you might be able to throw some top notch engineers at it?
The second maxim is "no one ever got fired for buying IBM". If you're going to bet on a horse, there is always a chance that things go sideways. You might as well bet on the fastest horse with the best record.
If you had a choice between IBM, DEC VAX, and Stratus VOS back in the day and you went the safe route to go with IBM, you would have been vindicated two decades later. IBM is still selling compatible systems.
I could go through the trouble of staying "vendor neutral" and use tools like Consul+Vault with an AWS backend, Nomad, and Terraform (been there done that) but the time I'm wasting being vendor neutral, I can spin up equivalent services on AWS that cost less and I don't have to maintain them.
Most of the things that I depend on AWS for now, I was doing the equivalent of on prem before and after AWS existed. I'm glad to not have to do that anymore and just being able to press a few buttons.