Wow. The benefits of Google App Engine without the limitations? Sure, an app on GAE is probably cheaper in terms of monthly expense, but factor in the development costs for a Java team unfamiliar with App Engine and Beanstalk is probably a far better investment.
AWS is not without it's "cool" storage: SimpleDB, S3, RDS. Not to mention, being within AWS with full control of your machines, you can setup any database you'd like.
To me, the limitations of App Engine are things like having to use a crippled version of the programming environment (as you don't get your own computer, so they've neutered things down to something "safe") and a bunch of limitations on CPU time, request length, and background processing.
(edit: I had somehow read what you said to mean, "no, but with these new limitations", so arguably I should just delete my response here, but I think that a specific list of things might be valuable still)
I agree. It's definitely meh without a useful and truly scalable database. That's the hard part. SimpleDB isn't particularly useful, and RDB isn't particularly scalable.
It's easy to find holes in this announcement: Beanstalk doesn't have X, or they compare unfavorably to AppEngine and Heroku in certain areas. The bigger news here is that Amazon has staked a flag in the ground and decidedly shown their intention to enter the PaaS arena.
What has AWS done in the past? They've introduced a new product, then over time:
1) Made it easier to manage
2) Made it more automated
3) Added additional bits of functionality
Why would we not expect them to do the same with Beanstalk?
I'm not sure how useful this really is. It just handles the application layer, leaving you on your own for dealing with the database. Now, Amazon has some services to help you out (RDS, SimpleDB), but SimpleDB is kind of crap, and RDS is expensive.
More importantly, that loses some of the simplicity, meaning that you still have to think about infrastructure to a degree.
Heroku is git push to deploy, and if you have a standard Rails app, that's it.
Whereas to deploy a standard Rails app, after you package up your app as a .war with JRuby (and deal with possible gem incompatibilities), you have to spin up an RDS instance too. And change the config in your Rails app so that it knows how to talk to the RDS instance. And if your RDS instance crashes, they backed it up for you, but you still have to manually restore from the backup.
And once you're already thinking about infrastructure to that degree, you've lost a lot of the benefit of a PaaS.
RDS pricing appears competitive to Heroku's dedicated databases. It's hard to compare them directly since RDS separates instance type, on-demand and reserved instances, provisioned storage, replication (crossing availability zone boundaries), and number of requests. Heroku on the other hand provides a fixed amount of storage (and one that's twice the max one can provision for RDS), a mix of instance types, and a connection cap limit. It's not clear if Heroku provides multiple availability zone instances similar to RDS.
Ignoring provisioned storage and request costs one can have a small on-demand RDS instance for ~$80/month. Heroku's instance (RAM/CPU) equivalent (Ronin) is $200/month.
As one of the two people working on something similar to Heroku or GAE (we're called ep.io), Beanstalk is simultaneously worrying and quite interesting - while it is an interesting player into the market, it's not _that_ hands-off, from what I can see, especially when it comes to databases, or things like Redis, which it's nice to have managed for you as well.
It's possible we'll see people springing up on EC2 offering those as separate services, however.
The other interesting part is that, since they don't do shared hosting but make you use a whole EC2 instance, there's potential for it to cost considerably more for smaller sites, but only once you get past that free plan of theirs (then again, the disk I/O on the Micro instances is truly awful)
AWS never fit into my definition of a "cloud" solution. It's a VPS with a rich API and a lot of addons (load balancer, EBS, S3...).
From what I'm reading, Beanstalk changes this and clearly puts AWS in the category they've long claimed to be in. Not that their service wasn't great/unique before. This just puts them that much further ahead.
It's along the lines of what Heroku does with their routing mesh layer (as far as I understand it).
Can we please all agree to disagree that there is no formal definition for cloud? I tripped across an article the other day where they were suggesting that these "PaaS" offering's weren't considered a "Cloud" by purists, and only "IaaS" (Infrastructure) - servers, cpus, network, storage - should be considered such. I was one of the original employees at Loudcloud - we certainly considered "Databases", "Applications Servers" to be cloud services.
Cloud = "That service/infrastructure/platform that you need that will be hosted by someone else in their data center"
If we wanted to be precise, we could refer to it as "Storage Clouds", "App Server Clouds", "Database Clouds", etc...
Amazon's execution with EC2 over the past few years has been excellent. If Amazon makes a Rails version of Beanstalk, Heroku should be worried as Beanstalk could take some market share from Heroku.
“We’re working with AWS to provide an Elastic Beanstalk Ruby on Rails container that leverages the optimized Engine Yard stack which has been battle-tested by thousands of high-growth companies.” John Dillon, CEO of Engine Yard
automatic scaling would be a good benchmark for the true definition of cloud.
a lot of "cloud" services these days are nearly identical to VPS services of yore, with the added new ability to create/destroy VPS nodes whenever you want. very few of the big "cloud" providers actually handle auto scaling (as it's difficult in a world where all apps are not made the same).
With GAE you have to write your application from the ground up to use Google's APIs and the design they force upon you. I'm not sure it's a fair comparison; in either situation you have to be cognizant of the environment your application will be running in if you want to take advantage of the environment.
Not necessarily. If you have a popular website you can put all your images and big content on S3 and just include the URLs in your HTML. It'll magically automatically scale then.
If you wanted something similar for Python or PHP then you could use VMWares VApp stuff which gives you the PaaS solution on top of hardware hosted by Colt which gives you the IaaS solution.
The reason that the VMWare offer gives you Python, PHP or other stuff, is that under-the-hood VMWare are using Chef and you can run your own custom Recipes, hence you could deploy whatever you want as a managed platform... though you would lose the Eclipse right-click deploy (though honestly if you're deploying from CI you're probably not going to be using this anyway).
The key point is that you could create a virtual datacenter, hosted with a 3rd party like Colt, and then use Chef to manage it as a platform, and deploy directly to it as if you owned your own "Elastic Beanstalk".
As an aside, I for one am getting tired of the never-ending list of acronyms and strange product names that are coming out from every vendor.
From what I can gather the current beta version only supports Java (i.e., war packaged) apps, but the intention is to support other kinds of application containers in the future.
Conceivably one could use jython or quercos to deploy python or php applications.
The real question is: can this offering compete with the specialized PaaS services we have seen emerge in the last year - heroku, GAE, djangy.djangozoom/eldairon, various node.js services, phpfog, etc...
The specialized services will be less work to maintain for developers, and will offer unique additional features that Amazon will have a hard time keeping up with if they try to spread themselves too thin.
Because Iwork mainly in Python, I just checked out the offerings you mentioned for Python that aren't GAE. Both Djangy and Djangozoom are in private beta still, so I can't imagine they're that far along. Eldarion doesn't look self serve, although maybe that's just their site.
It seems likely that, not only can Amazon compete, but could probably dominate. Heroku is a big outlier and really the first to demonstrate that the need/power of a PaaS. It doesn't look like there's anything nearly as mature for Python. Don't know about other languages/frameworks, but if it's like Python, Amazon has a big opportunity here.
Agreed - the only one I have actually used is GAE, and I was definitely not trying to endorse the other services as "too good to beat." Just trying to say that with all the different stacks out there for different languages and purposes there will be a benefit to specialization, which might not benefit from amazon's skillset as much as the provisioning of VPS's and other infrastructure has.
For python hosting, GAE is probably the only real competition at this point. There is a HUGE opportunity to eliminate sysadmin work on all these stacks for smaller developers especially. I am just not sure if Amazon will domiate both the infrastructure and platform layer.
This is cool, but not earth shattering. It is essentially a management stack/abstraction layer/deployment tool on top of existing AWS services: EC2, CloudWatch, load balancing, route 53, autoscaling, AMIs. It is a PaaS sort of... but single-tenant and not in the same sense as a multi-tenant, higher level PaaS like AppEngine or Heroku. Elastic Beanstalk gives you flexibility (full root access - do whatever you want), but with that comes more responsibility from a management perspective, and more opportunities to shoot yourself in the foot.
Cool new feature. Not too tough to see this coming though. One of the biggest barriers of entry to AWS has always been scaling/deployment. With companies like Cloudkick and Scalr helping to alleviate this, but being somewhat platform agnostic (Cloudkick supports aws, rackspace cloud, etc) Amazon would want to have an all-encompasing solution that has more of a vendor-lock in to their products. With solutions like Beanstalk and their free web tier, AWS is becoming easier to step right into each day. I predict that in a few years there will be no such thing as shared web hosting...
Sounds like a great idea, though the naming is a bit unfortunate, there might be some confusion between the Git hosting and collaboration application: beanstalkapp.com.
There's still plenty of room for competition. Beanstalk is limited in its ability to innovate because it is simply a management layer on top of AWS, which will restrict its potential feature offerings.
I think smaller developers stand to reap huge productivity benefits from easier to use and more feature-rich platforms such as Heroku.
Why is being a "simple" management layer atop AWS limiting? Bear in mind that Heroku is, in your terms, simply a management layer atop AWS. Using it as a technical yardstick and considering Amazon's strong financial position and commitment, it stands to reason that there is a long runway for Beanstalk's innovation.
