3 ms·

> Well, in this case in particular, Aurora is "wire compatible" with MySQL. The only thing you have to do to move away from Aurora is migrate your data to anot

> Well, in this case in particular, Aurora is "wire compatible" with MySQL. The only thing you have to do to move away from Aurora is migrate your data to another MySQL instance and change your connection string. Don't be fooled, the compatibility is there so that it's easy to port applications to Aurora, not so it's easy to take them out. Amazon still offers MySQL RDS. If you move to the much-more-expensive Aurora, it's generally because your MySQL RDS application is struggling, and Amazon says "Aurora knows special tricks to make the engine faster." Some management headaches, like adjusting for disk growth, are handled by Aurora transparently, which is nice, but for the most part, I saw workloads going to Aurora because they were too slow on standard MySQL. That means that instead of optimizing or fixing your application, you're relying on a single vendor's Secret Go Juice to make your application usable/performant. In such cases, unless the mainline distribution catches up in the meantime, you're going to be stuck because your stuff will be too slow on other stacks. From the risk management POV, Aurora is at best a temporary solution while the program is refactored/optimized to be performant on standard distributions.

scarface74 8y ago
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.
- cookiecaper 8y ago
  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".
  - anarazel 8y ago
    > 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...
  - sudhirj 8y ago
    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.

scarface74 8y ago

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.

cookiecaper 8y ago
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".
- anarazel 8y ago
  > 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...
- sudhirj 8y ago
  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.