Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Aurora - New MySQL-Compatible Database Engine

aws.amazon.com

Post reply on HN
Print view View original

111–120 of 138 posts

Re: Aurora - New MySQL-Compatible Database Engine

#111

Post by tracker1 »

freshflowers wrote: post #62
bcantrill wrote: post #49

(Disclaimer: I work for an AWS competitor.) To me, there is a very interesting contrast to be had between this announcement and Microsoft's announcement: it feels like Microsoft is discovering the business value of being open at the same time that Amazon is living in the time warp of proprietary everything. Has Microsoft internalized that open source is (or can be) a differentiator in the cloud? Amazon is clearly sti…

Apples and oranges. Cloud services are something very different from a development stack. Amazon puts all its SDK stuff open source on Github, and I don't see Microsoft open sourcing its tech behind Azure.

Actually, the azure SDK bits are pretty much all on Github as well.. Azure's CLI interfaces are either via node.js modules (npm install -g azure) or, iirc powershell extensions.

I will agree on a lot of the tech.. I think, by comparison DocumentDB is horribly locked-in without an API-compatible version you can self-host (even if it doesn't use the same tech, or perform as well) is a big warning flag imo.

In this case, being MySQL compatible is anything but a lock-in.

Re: Aurora - New MySQL-Compatible Database Engine

#112

Post by vidarh »

nl wrote: post #95
Thaxll wrote: post #83

Earlier quoted context omitted.

Because renting bare metal servers and put your cloud on it is cheaper and better in a lot of cases.

When you are actually using it as a private cloud for multiple internal clients I can kind of see the point (as I mentioned in my previous comment). If not, then what utility is OpenStack providing? Bare metal works well. I see many people using either Docker on bare metal or maybe a VM layer as an additional security layer, but using Docker as the deployment target.

The utility it is providing is deployment/management of the underlying resources. Docker does not do that. Some of the stuff people are building on top of/around Docker will provide it, but it's not there.

But I agree with you that OpenStack is not good enough to be worth it for that with perhaps the exception of very large multi-tenant deployments (in which case, my first goal would be to start rewriting large chunks of it). And parts of it are just so horribly over-engineered it is scary, because it makes me wonder what it is they're missing to think it was necessary to make things that convoluted, and what they're missing because they've made it so convoluted.

Re: Aurora - New MySQL-Compatible Database Engine

#113

Post by vidarh »

tracker1 wrote: post #110
chuhnk wrote: post #50

Earlier quoted context omitted.

I have to agree with this. Amazon sees the competitive landscape and their move is to attempt to create some form of vendor lock-in by providing the services that their customers have asked for or are probably hosting themselves. This is by no means a bad move and will result in holding on to a lot more customers as well as creating new revenue streams from those services. For someone like myself however, it complete…

How is this a case of creating vendor lock-in at all? The service itself is API compatible with MySQL... you can migrate to... MySQL, MariaDB, or a host of other services that are exposed in a MySQL compatible interface.

It is vendor lockin because it means you avoid thinking about how to deal with scaling beyond the single box.

So when the moment comes and you want to move away from AWS and you have scaled well beyond the capacity of a single box, what then? Suddenly you have to figure out sharding, replication and HA setups from scratch. While that may be the right choice for you if you're an early stage startup and it lets you defer engineering costs until a point where you're hopefully better funded, it's also dangerous:

It's far easier to get things like sharding and caching and use of read-replicas and multi-master replication right if you think about it from the beginning (if you've ever tried to retrofit any of this onto an application not designed with it in mind you know what I'm am talking about). It'd be awesome not to have to worry about this, but if you don't, you tie yourself into a platform you'll find it harder and harder to move off.

As a product, this solution would be a killer - it sounds fantastic. As an AWS-only service, I for one will treat it as if it doesn't exist, because getting tied to AWS for the long term is not an option for most of the projects I do.

Re: Aurora - New MySQL-Compatible Database Engine

#115

Post by vidarh »

loco77 wrote: post #99
wmf wrote: post #73

Earlier quoted context omitted.

The fact that you can't run it outside of AWS?

The point is you can run MySQL or any of its variants on your own hardware or anyone else's. Nobody forces you to use Amazon's implementation.

Once you have scaled to beyond the performance available on a standard setup on a single box without preparing to scale out, you face increasing costs in a migration because you potentially have to re-engineer your app to be able to run on a very different stack.

Compatibility at the connection level is just one part of a whole lot of issues to take into account when considering whether or not you can migrate elsewhere easily.

Given how expensive AWS is, that's something to seriously consider.

Re: Aurora - New MySQL-Compatible Database Engine

#116

Post by vidarh »

frozenport wrote: post #46
Xorlev wrote: post #40

Earlier quoted context omitted.

You probably aren't the target audience if your database fits in RAM.

You can see notable changes in performance if your database gets fragmented, and tweaking the .my.cnf script seems like a massive distraction from my actual work. Having somebody handle these and improve performance for long queries would be wonderful.

I you manage to have "long queries" with a 300MB dataset, you're doing something seriously wrong unless your definition of "long" is very different from mine. Or you're running on harware from the 90's.

Run "explain" on all your queries and review your indexes to begin with.

That dataset is so small that there should also be no need to be continuously tweaking the config file. 10 minutes looking at a performance guide, and ensuring you have enough ram to load everything into cache should be enough to get your configuration to a "good enough" shape - there's just nothing reasonable you'll be doing with a 300MB dataset that should need anything but getting the very basics of the config right to perform decently.

Re: Aurora - New MySQL-Compatible Database Engine

#117

Post by nl »

vidarh wrote: post #112
nl wrote: post #95

Earlier quoted context omitted.

When you are actually using it as a private cloud for multiple internal clients I can kind of see the point (as I mentioned in my previous comment). If not, then what utility is OpenStack providing? Bare metal works well. I see many people using either Docker on bare metal or maybe a VM layer as an additional security layer, but using Docker as the deployment target.

The utility it is providing is deployment/management of the underlying resources. Docker does not do that. Some of the stuff people are building on top of/around Docker will provide it, but it's not there. But I agree with you that OpenStack is not good enough to be worth it for that with perhaps the exception of very large multi-tenant deployments (in which case, my first goal would be to start rewriting large chunk…

I mildly degree with your assertion that the Docker tools aren't there yet. Some are pretty usable, and additionally if you include the category of DevOps tools then they are pretty good.

I agree entirely with you on the rest of your comment.

Re: Aurora - New MySQL-Compatible Database Engine

#118

Post by loco77 »

vidarh wrote: post #115
loco77 wrote: post #99

Earlier quoted context omitted.

The point is you can run MySQL or any of its variants on your own hardware or anyone else's. Nobody forces you to use Amazon's implementation.

Once you have scaled to beyond the performance available on a standard setup on a single box without preparing to scale out, you face increasing costs in a migration because you potentially have to re-engineer your app to be able to run on a very different stack. Compatibility at the connection level is just one part of a whole lot of issues to take into account when considering whether or not you can migrate elsewhe…

Well if only AWS provides the scaling you need then what would you migrate off of AWS to? You could re-arch your app to scale out for some use cases as you suggest, but that's also an indicator that using AWS allowed you to get to market faster with a much simpler system that didn't require a far more complex design, many more engineering hours and more admin.

Re: Aurora - New MySQL-Compatible Database Engine

#119

Post by loco77 »

vidarh wrote: post #113
tracker1 wrote: post #110

Earlier quoted context omitted.

How is this a case of creating vendor lock-in at all? The service itself is API compatible with MySQL... you can migrate to... MySQL, MariaDB, or a host of other services that are exposed in a MySQL compatible interface.

It is vendor lockin because it means you avoid thinking about how to deal with scaling beyond the single box. So when the moment comes and you want to move away from AWS and you have scaled well beyond the capacity of a single box, what then? Suddenly you have to figure out sharding, replication and HA setups from scratch. While that may be the right choice for you if you're an early stage startup and it lets you def…

There's nothing stopping you from using a scale-out architecture with Aurora, and nothing stopping you from running MySQL on your own hardware with loads of SSDs to get the throughput you are after.

Re: Aurora - New MySQL-Compatible Database Engine

#120

Post by skj »

loco77 wrote: post #65
skj wrote: post #2

oh neat, AWS following GCP instead of the other way around.

Your profile says you work at Google...

I certainly do. On cloud no less. The reality is that Amazon got to market several years before Google, so GCP had some catching up to do. That trend is changing, and this is one indication.
Post reply on HN