This keeps happening repeatedly - so let there be no more startups offering missing features of EC2. Go back! Build something else! Amazon has made it clear that you should not build a general cloud offering on top of EC2 - it must be niche, or not an enhancement of their offering, or they will simply do the same thing and kill you. And I don't think its that they're copying anyone. They've given lots of notice. Its just that their product vision fits with most anyone's who looks at what EC2 is missing.
Yeah, our marketing web site has gotten old, and it'll change within a couple of days. We haven't been selling auto-scaling and assorted features for a while. As Amazon is moving up the stack so are we. We're integrating a lot of the various features and really provide a platform for all the config management, automation, access control, etc. Plus pre-configured stacks that you can fully customize. If you actually try to use Amazon's monitoring and auto-scaling you'll find you have a lot of wheels to reinvent...
RightScale can provide services that span service providers. Currently, AWS is the principal cloud service provider but likely later this year there will be others (i.e Slice Host, FlexiScale, GoGrid, Sun). Services spanning service providers may include migrations, load balancing and redundancy.
It appears to me that RightScale is positioning itself to be a market for cloud computing services. It will be interesting to see if they pull it off.
Also, from the description of the monitoring service (i.e. no agent required) it is likely the monitoring data is collected at the host not the guest OS. So there is probably no process monitoring it follows that application profiling and similar services will not be possible with the data.
Amazon keeps adding really great features to AWS, but the technology that makes companies like Heroku interesting is being able to use them without caring how any of it works.
I Agree. But what's so special about this? Any startup must think about the defendability of its idea. Completing very obvious gaps in the Amazon-offering is surely hardly defendable.
IMHO, their strategy might have been "if we build what's missing in AMZN's portfolio, we might get acquired". Granted, not the best strategy, but this strategy has worked for some in the past.
You hit the nail on the head, except for the copying part. Amazon was already 1 - 2 years ahead of it's competition. This announcement extends that distance and puts a lot of pressure on the third-party commercial tools. There's still value to be had (like cross-vendor support) but that could wane as people realize many of the features they want are implemented in EC2 "out of the box".
Amazon is building an entirely new ecosystem and we'll start seeing news kinds of tools (commercial and open source) built in and around it.
Amazon shouldn't need to warn people of general good business practices. Anytime someone builds a business around a single entity in this case Amazon WS, they are prone for obsolescence when the entity includes "their" functionality into the core offering.
There are many cloud providers now. Startup should be diversifying their offerings to work with all cloud providers this will give their business the best chance for success.
A lot of those startups are offering a much easier starting point, though. They put a pretty face on what Amazon has provided. Building a scalable website infrastructure isn't as easy as a few clicks, even with these new features. There are lot of people who don't want to think about it and just start using EC2, knowing whatever's going on in the background is providing them adequate reliability.
In the case of websites, auto scaling is useful only if your application is not too dependent on DB but most web apps have DB as the bottle neck. The way auto scaling works is to launch new instances but that works only for application servers. You can't autoscale a DB by launching new instances.
So, even though this feature is useful it is not taking away the biggest headache in website scaling..i.e how to scale your DB.
Does anything prohibit someone from hacking together a way to scale their DB using this service? i.e. fire up instances that of a certain ilk? Not sure how detailed CloudWatch is, but you could conceivably automate anything that involves looking at numbers and taking steps to reduce load on your DB.
Hum, funny you say that, that's exactly what I'm working on: http://code.google.com/p/hotrepart/ The idea is to repartition a DB across multiple hosts while it's running. It's only a demonstrator project right now.
Monitoring and autoscaling I'll pass on. You can get better monitoring with collectd for free and autoscaling based on just load age or disk util and not app specific stuff is plain crazy.
The load balancer is pretty nice but I'll stick with haproxy until you can do httpand https on the same lb and also currently you can only do CNAME dns so no foo.com only www.foo.com and wildcard subdomains don't work unless you use tinydns(bind can't do it)
So I feel like this is a good start but I won't be using any of these services until they get more fully baked. The load balancer is the most interesting part but is currently seriously flawed.
I guess I spoke too soon and they did add support for multiple ports through the sam lb access point. So http and https can be served from the same lb. This makes the lb much more interesting.
amazons offering adds a pricing model to this space. if anything, i think amazons move into this space, although certainly anticipated, validates those that are also competing here. others who wish to compete know the price/value proposition they need to meet in order to have a chance.
While in my company we are loving S3 since it's really cheap and good, we can't say the same for EC2: the small instances are too slow, and the bigger instances are too costly and still can't compare with a decent Linux box. Overall we made our math and to have our servers in the server farm is going to cost less compared to EC2. Of course it's not going to be as simple to manage as EC2 is, but it is an acceptable compromise for now.
I think that here there is space for new startups if they are able to provide better performances at the same cost. I wonder if a configuration where in a cloud real hardware is selected in order to run an instance could work, instead to use virtualization technologies. This does not allow to take advantage of the fact that most boxes are not under high load most of the time, but maybe could work if it will be possible to use very low energy in this condition.
AWS CloudWatch seems remarkably expensive: 15 cents per instance per hour! Considering that all they are doing is aggregating and distributing per-VM statistics.
Woops: Brainfade. Yes, 1.5 cents/instance/hour, not 10x that. Still, quite expensive I think.
With Amazon CloudWatch... at a rate of $0.015 per hour for each Amazon EC2 instance you choose to monitor...
As an example, a developer may want to monitor 10 Amazon EC2 instances 24×7 for a 30-day period. The Amazon CloudWatch cost would be $108 (or $0.015 per Amazon EC2 instance hour x 10 Amazon EC2 instances x 24 hours per day x 30 days)...
That is close to what it costs to run a single instance to collect all your statistics (75$ if its small + your time is worth something!).
Yeah, my bad. Still, I think it's quite expensive. If all they are offering is some simple runtime stats, then a 15% surcharge on the cost of a small instance is pretty expensive. If you have 50 instances, you're paying $540/month just for monitoring.
That is close to what it costs to run a single instance to collect all your statistics
Assuming you need a completely separate instance which couldn't do anything else but monitoring, which is unlikely to be the case.
If anyone is willing to share... Who here does this solve a specific problem for, and are you actively/planning on implementing it ASAP? What is your use case? It's a sweet feature, and I can't wait to see how it manifests in the hands of hackers.
We have several application components that use software load balancers (HAProxy) so we can manually scale each component quickly. The load balancing service will let us shut down each of those instances for a decent savings. Our QA environment is a copy of prod (scaled-back, but identical, including LBs) - more nodes to shut down, more money saved.
This is easy to implement and is basically found money, so we'll be doing it ASAP.
My expectation is that an Amazon (LB) access point is more reliable than a generic EC2 instance. For these components, we'll be paying less for something that's both more reliable (hopefully) and easier to manage.
Auto-scaling is powerful and easy to set up (even in the private beta, before tools were available), but as we're heavily integrated with RightScale (specifically, using templates throughout) migrating to pre-configured AMIs would take some effort. We'll have to do some internal review before making a decision on rolling out auto-scaling to existing apps.
Monitoring is, as expected, also provided by RightScale. Amazon requires you have CloudWatch turned on for instances in auto-scaled pools (for obvious reasons), so that's one way we may end up using it. RightScale's blog post mentioned they'll be integrating their alerting and reporting with CloudWatch, but I'm not sure it's worth the extra $0.015/intance-hour to have the data come from Amazon instead of RightScale. I expect that, for now, CloudWatch is more relevant to:
1) users not on RightScale, Cloudkick, etc.
2) users who want direct access to their monitoring data (for archival, custom graphs, whatever - not currently possible with RightScale, not sure about other cloud management vendors)
Amazon's move up the application stack (Elastic MapReduce, for starters) may create additional use cases for CloudWatch, but that's entirely up to Amazon.
What I'd really like to see in the near-term is an open source tool to read in and graph CloudWatch data that's been archived somewhere (SimpleDB would be cool, but S3 would work too). Of course, I can see why people would be hesitant to start down that path given that Amazon has a console that's begging to include this functionality.
The day someone comes up with solid evidence that they are using the system to skim money off unsuspecting customers is Amazon's last day as a hosting company.
Trust of a web host is of paramount importance. I know a lot of people who stuck with more expensive hosts just because they trust them and have a good working relationship with them.
re: trusting Amazon to scale, as they say in the release notes, they provide a detailed audit of scaling activity. After all the work Amazon has done to help their customers, I doubt they're interested in grabbing a little cash from inappropriate scaling.
Unscrupulousness is easier if the other party is complicit: much more profitable to make people want to lower the thresholds before spinning up a new server ("We recommend setting the trigger when your CPU load is 0.1 and disk iops is 10/s") versus the gauche act of the visible rip-off.
The load balancer seems nice. We used HAProxy, but it seemed like the sort of thing that Amazon could easily take care of on their own. I see that it has health checks, but I wonder if it's generally as nice and configurable as HAProxy.
This keeps happening repeatedly - so let there be no more startups offering missing features of EC2. Go back! Build something else! Amazon has made it clear that you should not build a general cloud offering on top of EC2 - it must be niche, or not an enhancement of their offering, or they will simply do the same thing and kill you. And I don't think its that they're copying anyone. They've given lots of notice. Its just that their product vision fits with most anyone's who looks at what EC2 is missing.