photo by: Jean-Yves
Have you reached stylesheet Nirvana? Are you the designer people go to for a fresh, clean, gorgeous look?
Have I got the dream job for you! 🙂
Come build beautiful stuff that millions of people all over the world can enjoy. We’re private, profitable, growing fast – and you could be a vital part of it.
One great thing about Web2Open is that it’s free – anyone can attend!
See ya there!
I realize I’m already way behind blogging about other new Amazon Web Services features like the recent EC2 release with static IPs, availability zones, and user kernels not to mention the new block storage service. I’ll still try to get to them – but I didn’t want to wait for this one.
I’ve been pushing Amazon hard to do something like this, and I’m thrilled it’s finally out. They have a great new service status dashboard complete with historical data and a mechanism for communicating to us, their customers, about any issues they may be having. Especially cool is that the data is provided via RSS, so you can programmatically poll the status and take steps as necessary. Awesome! Get all the details here.
One possible gotcha is that it looks like the dashboard is hosted at Amazon. We’ve run into outages (very rare) where all of amazon.com is down. In those cases, it’d be nice to have an externally-hosted site where they could post updates. Our customers asked us for this recently, so on January 29th, we were happy to comply. Perhaps Amazon could post to their TypePad blog in events like these, rare as they may be?
Next, they now offer paid premium support. Need some sort of help that’s not provided on the AWS forums or via searching Google? No worries – whip out your credit card and pay for it. Looks like they have two plans which should cover lots of use cases I’ve seen in my own comments and on the forums.
I’d still like to see a pay-per-incident model, personally, even with an extremely high price-tag for each incident. We rarely use support for AWS, but at the same time, we’re very big customers of theirs, so the monthly price is quite high. But if we really come up against a big problem, it’d be nice to know I could pay for support just that one time. I imagine most of their customers will like their Silver and Gold monthly packages, but for us, they’re just not quite the right fit. Do they work for you?
I’m pretty thrilled about this release, but maybe our use case is different from yours. Do you like these new features? Are they missing things you’d like to see?
I know I’m a little late to the discussion, but Brian Aker posted a thought-provoking piece on the imminent death of MySQL replication to scale reads. His premise is that memcached is so cool and scales so much better, that read replication scaling is going to become a think of the past. Other MySQL community people, like Arjen and Farhan, chimed in too.
Now, I love memcached. We use it as a vital layer in our datacenters, and we couldn’t live without it. But it’s not a total solution to all reads, so at least for our use case, it’s not going to kill our replica slaves that we use to scale reads.
Why? Because we still need to do index lookups to get the keys that we can extract from memcached. And we have to do lots of those indexed queries. Most of the row data lives inside of memcached, so this turns out to be a great solution, but we still need read slaves to provide the lists of keys. Bottom line is that we still use read replication heavily – but we use it for different things that we did in years past.
And then, of course, there’s the issue of memcached failure. For us, it’s very rare, and thanks to the way memcached works, it rarely hampers system performance, but when a node fails and needs to be re-filled, we have to go back to disk to get it. And doing that efficiently means read slaves again.
For us, memcached plus MySQL replication is true magic. Brian’s a very smart guy, and I realize he wrote the post to get people thinking and talking about the issue, but at least for us, read slaves are here to stay. 🙂
The big deal? They’re releasing a Community version that doesn’t have all the same features as the Enterprise version of Online Backup, including compression and encryption. The Community version is open-sourced under GPL, the Enterprise version is not.
Personally, I think this is awesome. Don’t get me wrong – I love open source. We couldn’t have built our business without it, and we love it when we get a chance to contribute back to the community.
But let’s not forget that MySQL is a business. And that business helps the community and improves the software. They have customers (I’m one – we’re a paying MySQL Enterprise Platinum customer), and they have to solve those customers’ problems. This is a virtuous cycle where the community benefits directly as MySQL thrives financially.
Every time a business like us pays MySQL for a service or feature, MySQL can then invest in better software that benefits all. The end result in MySQL’s case is more GPL’d code. In a very real way, without companies like mine, there wouldn’t be a new backup tool at all – let alone the differences this debate is focused on.
Every day, I hear someone saying “Man, I love SmugMug so much! It has [insert features here] which I love! Why isn’t it free?”
The answer? “It wouldn’t be SmugMug if it was free.” MySQL’s situation is very similar.
I wish more open source projects would make it easier for this cycle to ignite. Some of them, like Red Hat, refuse to even take our money. Talk about stupid. There are *lots* of businesses out there willing to pay for extra services and features, and the community can harness that revenue in amazing ways, including getting more (or better) GPL’d code.
Couple more thoughts:
- I wouldn’t be surprised if future releases add new Enterprise-only features and some existing Enterprise-only features migrate down to Community.
- The Community version is open-sourced, so I’m sure the community will develop their own compression and encryption features.
- This is really no different from Enterprise Monitor, which has been only for Enterprise customers for awhile.
- Lots of other projects do this (and I would argue this benefits those projects and their communities, too)
- I’m 99% sure that this was the plan before Sun acquired MySQL.
First: Very cool.
Next: I think it’s interesting that Google has basically taken a sniper scope out and aimed it at a specific cloud computing target. App Engine is only for web applications. No batch computing, no cron jobs, no CPU/disk/network access, etc.
I think this is very smart of Google. Rather than attacking Amazon head-on, Google has realized there’s a huge playing field for cloud computing, and are attempting to dominate another portion of it, one where they have a lot of expertise. Very good business move, imho.
Will we use it? I wouldn’t be surprised. I’ve long thought that we’ll continue to mix in web services from a variety of providers, and it looks like App Engine can solve a slice of our datacenter need that other providers don’t yet provide.
I’m more than a little concerned, though, by how much vendor lock-in there is with App Engine. At first glance, it doesn’t look like the apps will be portable at all. If I want to switch providers, or add in other providers so I’m not relying solely on Google, I’m outta luck.
I’m hopeful other languages get supported, too. I think Python is great – don’t get me wrong – but we have a lot more experience with other languages, so there’ll be a learning curve.
Finally, I’m dying to find out what pricing for an application of our scale will look like. I can see some immediate, obvious things I’d like to try to do on App Engine, but the beta limits aren’t gonna cut it for us. 😦
Will it replace Amazon? It sure doesn’t look like it from where I sit. In fact, I don’t see this as much of a competitor to Amazon Web Services. There’s some overlap in some small area (hosted web apps on EC2), but I doubt that’s the bulk of Amazon’s business. As I said, we’ll likely end up using both (and other providers as they come along, too).
My favorite bit? In theory, Google has solved the data scaling problem. I don’t mean raw binary (blob) storage, which S3, SmugFS, MogileFS, and plenty of other things have solved, but the “database” scaling problem. Every popular web app runs into this problem, and it’s typically solved with a combination of memcached, federation, and replication. But it’s messy. In theory, Google has automated that piece for us. I can’t wait to play with it and see if that’s true.
I also can’t wait to see who else is going to wade into this fray. Sun? Microsoft? Yahoo? IBM?
Bring it on!