Yesterday we refreshed the GoGrid product site, located at http://www.GoGrid.com .

The new site contains a variety of new as well as updated product and service information including:

• A Flash tour of the product – a high-level overview of the product and feature

• Feature details – a bit more detailed information on GoGrid

• Listing of Technical Specifications – initial server images that GoGrid will launch with (refreshed regularly)

• Listing of Pre-Paid plans – start your budget planning and savings early

• Information on 24/7 Customer Support – info on support

• A series of initial FAQs – see if any of your questions have already been answered.

• Knowledge Base Articles relating to GoGrid – updated regularly

• Community section – with feeds from the GoGrid blog

• And much more…

Sign up now for the Private Beta and be sure to check back soon for more announcements!

As I strive to better understand these new emerging technologies such as “cloud computing”, I frequently find myself reading various blog articles, many professing to be the end-all definition related to the topic. It is not very often that I actually come across an article that is informative, understandable and compelling enough to warrant note.

The post by Alex Iskold is a perfect example of one of these excellent articles. An important definition from his post:

The idea behind cloud computing is simple – scale your application by deploying it on a large grid of commodity hardware boxes. Each box has exactly the same system installed and behaves like all other boxes. The load balancer forwards a request to any one box and it is processed in a stateless manner – meaning the request is followed by an immediate response and no state is held by the system. The beauty of the cloud is in its scalability – you scale by simply adding more boxes.

Some may say that this article is a bit “heavy” on Amazon as the “killer service.” But I believe his point is that Amazon has put a lot of weight behind and person-hours into their products and they will be hard to duplicate, at least for players developing “cloud” products. But some of his general comments hold true regardless of the product: “Free from the need to solve the scalability problems, startups are able to focus on the specific problems their product or service is trying to solve.”

I recommend this as a good read on what Cloud Computing is, a la Amazon, and for people really trying to make heads or tails of grid, utility, cloud and distributed computing.

In closing, Alex’s line “…we are witnessing a fundamental shift in our ability to compute and this is just the beginning…” truly sums it up for all players and customers in this market. I echo that whole heartedly.

I guess I could have jumped on the bandwagon and started criticizing Amazon for the issues that it had on Friday with their S3 offering. But part of me wanted to see how it all shook out, what the cause was, what would change, if anything, and how their customers would take it. According to the blogosphere, the Amazon service was down for over 2 hours (which seems to be accurate after reading through this forum thread on the Amazon developer forum).

This official Amazon AWS response clip from the forum seems to explain the outage:

Early this morning, at 3:30am PST, we started seeing elevated levels of authenticated requests from multiple users in one of our locations. While we carefully monitor our overall request volumes and these remained within normal ranges, we had not been monitoring the proportion of authenticated requests. Importantly, these cryptographic requests consume more resources per call than other request types.

Shortly before 4:00am PST, we began to see several other users significantly increase their volume of authenticated calls. The last of these pushed the authentication service over its maximum capacity before we could complete putting new capacity in place. In addition to processing authenticated requests, the authentication service also performs account validation on every request Amazon S3 handles. This caused Amazon S3 to be unable to process any requests in that location, beginning at 4:31am PST. By 6:48am PST, we had moved enough capacity online to resolve the issue.

As we said earlier today, though we’re proud of our uptime track record over the past two years with this service, any amount of downtime is unacceptable. As part of the post mortem for this event, we have identified a set of short-term actions as well as longer term improvements. We are taking immediate action on the following: (a) improving our monitoring of the proportion of authenticated requests; (b) further increasing our authentication service capacity; and (c) adding additional defensive measures around the authenticated calls. Additionally, we’ve begun work on a service health dashboard, and expect to release that shortly.

Sincerely,
The Amazon Web Services Team

What this boils down to was that is seems like Amazon was hit by an intentional (or not?) DoS (Denial of Service) attack using these authentication protocols. Good for Amazon for coming right out (albeit only on the developer forum initially) and admitting the issue as well as listing out some actionable solutions. This is an important move, by them, with the admission of mistakes.

I have mentioned this before, it’s tough being a hosting provider (as Joyent and Twitter experienced recently). But then I remember that we (all of the ISPs and hosting providers) who are working on providing grid/virtualized/cloud computing, or any new product offering, are breaking new ground. That means, like any new or innovative product, that there will be issues, bugs, downtime and other problems. That is the price you pay with emerging technology. Software is developed by humans, to err is human, so therefore, applying simple high school logic, software will have errors.

S3 is an incredible product and might be a good match for many companies. Just remember to have a back-up strategy. Amazon’s core competency is selling books and other products, not necessarily hosting. They are making a good run at it though. My thought is that S3 spun out of a glut of extra computing power and resources being available during non-holiday times. If so, what a great idea of off loading extra server capacity during non-holiday shopping crunch times. But again, hosting is not their core business.

So I ask you, the reader and customer/potential customer of any new, bleeding edge technology, to be forgiving when things don’t work as expected. Being an early adopter of technology means that you accept the risks associated with that. Your rewards may be great (new product & better pricing), but also the potential for “disaster” is also much higher compared to more traditional routes.Some points to make sure you don’t get caught by surprise:

• Develop a backup solution
• Use your backup solutions regularly
• Understand your SLA (Service Level Agreement)
• Look for ways to set up redundancy. Set up a High Availability Network.
• If you can afford it, diversify your network; set up various mirrored POPs (points of presence) with different service providers
• Develop a contingency plan: if your network goes down, can you:
  • easily inform your clients
  • get a temporary site up quickly
  • get timely and informative information from your ISP
• Put it all down in writing
• Do a disaster recovery dry run to work out the kinks
• Do cross-training of core skills

The most important suggestion I can make is one that Douglas Adams articulated so clearly in his book, The Hitchhiker’s Guide to the Glaxay. The two words “Don’t Panic” are boldly inscribed on the cover of The Guide. You might want to follow the same lead and put those word on your IT strategy and contingency plans. And be sure to do some research on a variety hosting providers. They can make or break your business!

The Dilbert cartoon continues its virtualization theme and the topic is a new “creative” way to ensure that you don’t have any bugs!

Obviously the GoGrid team doesn’t subscribe to this methodology, only to the cartoon.

Scott Adams continues his Virtualization story, now with Dogbert as the virtualization “consultant.”

I’m glad the monkeys aren’t on the GoGrid team!