Thanks for agreeing on one of my point. For the other don’t tell me you don’t like flashy gui (probably not, I am looking at Zenoss sceenshots). I recently started using django and am learning python while doing so, I love their first Zen of “Beautiful is better than ugly.”

Can’t comment about scale as my client are small/mid size deployments. I agree that there are many open bugs with Hyperic and wish they fix all of them tomorrow but I won’t stop using it if they can’t.

Kamal

I think I am the only one out there who has questioned the value of this service. I think that is a good thing. In fact it has created this debate. Would you prefer in the future I just oooh and ahhh every time you guys make an announcement. I am not sure if you have followed my blog. I have on a number of occasions praised Hyperic innovations. I was disappointed in this service and I expected more and I am just taking a pass on this one.

CloudStatus is monitoring Amazon’s service, not your application.

I understand what you do and in fact you restated it in this comment. Not monitoring what you call the application (I prefer to call it the service) is why, IMO, you add very little business value to anyone other than developers and the blog-o-sphere.

Well, this is an important metric that even Amazon has numbers on.

Of course they do, however, they are not a monitoring company. You are.

If your application requires 30 instances up in order to be available, or your app just needs 1 instance + a ton of software, this number is still useful.,

Again you are making my point…. Just measuring the start of the instance is of little value to the business service. Take your second example “1 instance + a ton of software”. If you are telling me that Cloudstatus can tell me when a “ton of software” is loaded, configured, and available to the service then I am all ears. What a business needs to know is when the service is available and how degradation in service availability affects the business. Take the LAMP stack. What the business needs to know is how long it takes a new server to be started and configured in relation to the stack.

In the case of EC2 queuing models, a business needs to know what the relationship of jobs in the queue related to the amount of instances that are available. Stacey, claims that your Cloudstatus grew out of customer requirements. Since most of the successful EC2 business models today seem to resolve around batch processing, (e.g., Smugmug, Animoto, NY Times), I am not sure how you guys missed this one. Make me king for a day and I would have found a way to monitor a services queue requests and then relate that to instances.

Also, I am not clear that a few synthetic applications starting EC2 instances and measuring the startup time relates to other applications in the AWS network. Are all EC2 instance creations the same or does mileage vary depending on Network routes, EC2 Zones, and a number of other factors. Other than ballpark numbers will the Cloudstatus numbers give me meaningful data.

What we tell you (in the case of EC2) is how much time Amazon needs to process your request and give control of the instance to you. This is important! If that number were 20 minutes instead of 60 seconds, you’d be outraged!

I am going to go out on a limb here and say that taking 20 minutes to start an EC2 image is probably and outage and I am not sure a business needs Cloudstatus to tell us that.

How can Amazon claim elasticity when they are bringing up instances as fast as RackSpace can rack them?” “How can I respond to a surge in traffic if bringing up an instance takes an hour?”

Now you are really zoning in on my point. Elasticity is not just starting an instance. It is using autonomics. Autonomics ties monitoring with provisioning. If I were a monitoring company and I wanted to add monitoring value to the cloud I would look at what companies like 3Tera, Elastra, and Rightscale are doing to provide elasticity. In fact the open source project Sclar project also includes this kind of elsaticity. Theses vendors use monitoring metrics to autonomiclly provision servers. They use simple metrics like loadavg, number of users, and network traffic. Elasticity in the clouds is the ability to dynamically provision instances when you need them and destroy them when you don’t. Static AJAX charts or emails can not aid in a customer’s need for elasticity. I take it that your assumption is that users of the cloud will have to go to cloudstatus.com to find out how thier business is running. That doesn’t seem a likely scenario. What the cloud industry needs is common open source, non hype, monitoring tools that understand this and can tie those metrics, or make available, to the specific cloud API’s. These were some of the things I thought Hyperic was going to provide when I heard about the Cloudstatus announcement.

Also, can Rackspace dynamically add a server to a customer’s application in twenty minutes with a dynamic on-demand request?

CloudStatus provides normalized metrics that are applicable to everyone using the services.

Why not ping google.com while you at it…

We’ve distributed the monitoring of Amazon through many instances so we can provide many datapoints — not just a ’single synthetic’ one.

How many? What locations? Are you using different Zones? How often?

Well, if you look at CloudStatus, it’s readily obvious that you’re not going to get faster than a 3 second latency in your queue — and that’s something you can make business and application architecture decisions on.

Again you are hitting the nail on the head. Most people know through the blog-o-sphere that it takes on average about 60 seconds to start an EC2 instance. I have to admit I have not seen any one specifically measure SQS and show metrics and now we know. These numbers are useful to developers, however, traditionally monitoring is not used by developers it is mostly used after the application is deployed.

If you want specific information about when your complex 30 instance application becomes available, then you need a different tool … might I suggest Hyperic HQ?

From the Hyperic PR campaign this is what it looked like Cloudstatus was going to provide. Now that you have confirmed and cleared the “Hype” behind the video and the other viral articles we now have a clearer view of what Cloudstatus is and is not.

In the end the real value Cloudspace adds will be determined by the users of EC2 and not blogger like me or bloggers that have gone through the Hyperic PR “Junket”.

To save us both a lot of time … Let’s just agree to disagree…

In your effort to make news, you’ve quite obviously missed the entire point: CloudStatus is monitoring Amazon’s service, not your application.

I’ll address your EC2 comment first, “They measure from the time the instance is started until it is available.”

Well, this is an important metric that even Amazon has numbers on. If your application requires 30 instances up in order to be available, or your app just needs 1 instance + a ton of software, this number is still useful.

What we tell you (in the case of EC2) is how much time Amazon needs to process your request and give control of the instance to you. This is important! If that number were 20 minutes instead of 60 seconds, you’d be outraged! “How can Amazon claim elasticity when they are bringing up instances as fast as RackSpace can rack them?” “How can I respond to a surge in traffic if bringing up an instance takes an hour?”

And I think that’s where you missed the boat — CloudStatus provides normalized metrics that are applicable to everyone using the services.

We’ve distributed the monitoring of Amazon through many instances so we can provide many datapoints — not just a ‘single synthetic’ one.

Let’s move on to SQS. Say you’re writing an application and considering SQS. What kind of optimal performance can you expect? Well, if you look at CloudStatus, it’s readily obvious that you’re not going to get faster than a 3 second latency in your queue — and that’s something you can make business and application architecture decisions on.

Again, these are metrics which provide information about what you can expect from Amazon’s service.

If you want specific information about when your complex 30 instance application becomes available, then you need a different tool … might I suggest Hyperic HQ?

– Jon

Most paid enterprise solutions actually publish reliable reliability statistics since they have built the cloud for the long run and are not just a one hit wonder out for the quick buck.

Ok, I have to give it to you hyperic has added value with a couple ajax charts. Typical hyperic flashy gui releases and the rest is left up to the community to fix. Cross your fingers it scales.

Sorry about the comments – there were 6 in there for moderation that I simply hadn’t gotten to since I am on the showfloor. It was actually bad communication on my part to offload that to someone else on my team while I am using my PC as a demo computer here at Velocity. Your comment is published now – I never deny anyone except spammers selling blue pills or printer ink or whatever.

As for how directly useful it is to your exact implementation, of course it can’t cover every corner, but we are ramping up and destroying instances all over AWS every minute and running a battery of tests with origination internally to AWS and externally. While we can’t cover the whole thing it is as the product page says a reasonable result of the general service levels.

(http://www.hyperic.com/products/cloudstatus.html)

“The results should be interpreted as an indication of general service levels, and point further investigation toward application behavior or cloud performance.”

-Stacey

Thanks for the update. First off I was disappointed to see that you guys yanked my comment on your blog. That doesn’t seem real open.

My point stands…

I do not see how looking at single synthetic points in a huge network like AWS can give you meaningful information to make business decisions on. In you PR yesterday Hyperic suggest that Cloudware does a lot more than what you have described in this comment (e.e., your Video and other Business references). If your point was to satisfy developers and the blog-o-sphere then you have created a good tool. However your PR, IMHO, suggests a lot more than that.

I look forward to see any future customer solutions that you guys add to the clouds. I have and am a Hyperic fan and will be the first one to point out (as I have done before) when you guys do something not Hype[PR]ic.

John

I am sorry you didn’t get the full picture from the news yesterday. http://www.cloudstatus.com is a reference tool for developers and users to look at when they notice their performance is degrading in the cloud.

The genesis of the new product came of course from our existing install base. Hyperic HQ, our flagship product, has an ever-increasing number of open source users and enterprise customers running in the cloud. When our customers suffered some degradation in performance – they basically had no easy way to triage if the problem was their application or the cloud itself. CloudStatus fixes that.

CloudStatus is a tool to look at general trends overall in the cloud so you can get that indication. In fact, just yesterday, there was some problems with SQS, that folks verified on CloudStatus in the forums: http://developer.amazonwebservices.com/connect/thread.jspa?messageID=93358&#93358.

The idea is to start with this free service, and then to expand it (we’re looking for forum conversation as well as working with Amazon and other cloud providers directly). The goal will be to have personalized versions of this that will work with your Hyperic HQ deployment in the cloud. This will line up your application with the cloud infrastructure its deployed against. That said, I do think that CloudStatus as a free service will continue to be extremely relevant for developers and users beginning in the cloud to benchmark their performance with independent relative trending of the services they are using. The real monitor of their application soup to nuts – will take Hyperic HQ and the future CloudStatus service.

Also – disclaimer on FPS, you should note it is actually the sandbox. Its noted in the service. This is because we are ramping up various locations and committing multiple transactions of $.01 each a minute. The bank constantly shuts this down suspecting fraud. We are trying to reason with them… but it may take time. This does bring up a great point though – many developers would probably line to see these trend reports in both the sandbox and production since they have various performance differences and it would be good to have the relative information for future capacity planning. You’ll also see that there was an outage in the sandbox on Friday, which definitely worried several developers that their tests weren’t working!

I hope that gives you a better picture of where this service is going. If you have any more questions, you know where to reach us!

-Stacey

Actually what amuses me is how many bloggers did not do any analysis on the Cloudstatus offering. A lot of them just took the press release and reworded it.