The panel was moderated by Shlomo Swidler (Founder, Orchestratus) and the members included:

• Shashi Mysore, Product Specialist, Eucalyptus Systems
• Adrian Cole, Founder, jClouds
• George Reese, CTO, enStratus
• Michael Mayo, Rackspace
• Mitch Garnaat, President, CloudRight
• Justin Kitagawa, Lead Senior Software Engineer, GoGrid
• Sam Ramji, Vice President of Strategy, Sonoa Systems

Each panel member was allowed a few minutes to discuss how their service can be controlled programmatically via an API or other method. This is an important discussion point because many companies and developers are looking to build applications that span clouds. However prior to doing this, these developers must fully understand how a cloud is architected and can be utilized. Obviously, when building a cloud as a vendor, there are challenges and hurdles that must be overcome in the process. Each of the panelists discussed their design decisions and then answered questions presented to them by the moderator as well as by audience members.

As an attendee of this panel, I thought it important to present GoGrid’s thoughts on our own API and how we came to make the decisions behind its development. Below is a video of Justin’s presentation which covers:

• Who and What is GoGrid?
• The GoGrid Portal
• The GoGrid API
• The Anatomy of a GoGrid API Call
• A Sample API Request
• Sample Code
• GoGrid API Objects & Actions
• Challenges in Developing
• Who is the API for?

The full presentation is also available below:

If you are interested in how the GoGrid API works, I encourage you to look at the GoGrid Wiki where you can find the “Getting Started Guide” as well as the following items:

• Anatomy of GoGrid API Call
• Common API Call Patterns
• API Frequently Asked Questions
• API Libraries and Tools
• Download a GoGrid API Quick Reference Guide
• API Version Log

Also, I’m personally curious to find out if and how you are using the GoGrid API. Have you created a program to hook into our API to control scaling or deployment of servers? What about creating your own interface to our service? Please leave a comment and let me know!

• GoGrid Dedicated Servers
• List View of GoGrid Objects
• Edit F5 Load Balancers via the API
• New Login Page
• Self Service Support Links

More details about these features can be found on the following GoGrid blog post. For a quick overview of the new features in the form of a screencast, please watch the video below. I quickly cover many of the items listed above including:

• Walking through the new login page
• Deploying a GoGrid Dedicated Server
• Overview of the new GoGrid List View
• Dedicated Servers showing in the Jobs Tab
• Showing of Self-Service Links in the portal
• Editing Load Balancers using the GoGrid API

If you have more questions about these new GoGrid features, I recommend that you attend our webinar (on February 24, 2010) where you can get more information about this important release. Be sure to register for the webinar and come prepared with questions!

• GoGrid Dedicated Servers
• List View of GoGrid Objects
• Edit f5 Load Balancers
• New Login Page
• Self-Service Support Links
• Other Items

We hope that you share our excitement about this release! Now, let’s get into the details. Also be sure to see our video that talks about many of the items listed here (Available on GoGrid YouTube channel and the GoGrid Facebook Fan Page as well.)

GoGrid Dedicated Servers

Let’s face it, we have been doing dedicated hosting for over 8 years so we do know a little bit about it. Last year, we introduced a first-to-market service that we internally called “Hybrid Hosting” which allowed users to connect GoGrid cloud infrastructure with a separate dedicated infrastructure, all within a private network. This proved to be incredibly successful, and something that many of our customers had desired. So, we decided to take it to the next level by offering Dedicated Servers within the GoGrid infrastructure.

So why is this so revolutionary and useful to our end-users? Here are some things off the top of my head:

• Now you have the flexibility of the cloud, coupled with the control and performance of dedicated hardware!
• You can deploy GoGrid Dedicated Servers from within the GoGrid portal
• GoGrid Cloud Server and GoGrid Dedicates Servers share the same IP space which means that you can easily set up private network infrastructures
• You receive one bill for your cloud or dedicated servers
• Support for both cloud and dedicated are handled in the same account
• You can restart and even delete dedicated servers on-demand via the GoGrid portal
• GoGrid Cloud & Dedicated servers have free inbound traffic and share the same data plan

Let’s get into the details.

Add Dedicated Server

We have updated the Add menu to include Dedicated Server as an option. Similarly, we have collapsed the previous Database Server and Web/App Server into Cloud Server. To deploy a new GoGrid Dedicated server, simply click on the Dedicated Server icon.

Once you choose the Add Dedicated Server option, you will be presented with a Server Details screen that asks for a server Name, Description and IP address (one of your GoGrid contiguous, static IP addresses). After that, you need to select the server option that makes the most sense to you. Current options are (note: these may change in the future and are current as of the writing of this article):

Note: custom configuration are available but interested users must contact a GoGrid Account Manager to order.

After entering the appropriate information and selecting the configuration option and pricing plan, click the Next button, and you will be asked to choose an image:

As of this writing, the options include:

• CentOS – versions 4.5 & 5.4 (32/64 bit)
• Debian – versions 4.0 & 5.0 (32/64 bit)
• Fedora – version 11 & 12 (32/64 bit)
• RHEL – version 4.8 & 5.4 (32/64 bit)
• Ubuntu – version 8.04, 9.04 & 9.10 (32/64 bit)
• Windows Server 2008/2003 – various options: Enterprise, Web, SQL Server (note: some images may have additional licensing charges)

Once you select the Image you would like on your GoGrid Dedicated Server, you will be prompted with information regarding the Pre-Paid Plan commitment and billing process. If you agree to the terms, simply click Yes, Add it.

In the top bar, you will see a confirmation that of your Dedicated Server job request:

It is important to note that it can take up to 2 business days to deploy a GoGrid Dedicated Server.

You can also check the status of your deployment request in the Jobs tab (where Dedicated Server deployments now appear in-line with Cloud Servers, Load Balancers and Cloud Storage):

The picture above shows the Dedicated Server in a “Processing” state. Once it is approved, deployed and active, the log will change to reflect that state:

Once your server is live, you have a variety of ways to manage it. For starters, should you need to, you can actively restart it from within the new List View within the GoGrid portal (see the List View section below for details).

Similarly, you can delete the Dedicated Server from the portal. Do note that since you are on a monthly plan, you will have until the end of the active month to access that server before all connectivity and data is removed from it.

Also, as with your GoGrid Cloud Servers, you can retrieve, edit and update the passwords for your GoGrid Dedicated Servers from within the Passwords tab within the Support section.

We have also integrated all of the GoGrid Objects (Dedicated & Cloud Servers, Load Balancers and Cloud Storage) into the Add a Case menu within the Support section. This way, you can request support on any GoGrid infrastructure item in one place:

Some important things to note about GoGrid Dedicated Servers:

• Dedicated Servers do not (currently) display on the Grid View but do within the List View (see section below)
• There is currently no API support for controlling GoGrid Dedicated Servers
• Under the current Service Level Agreement, provisioning time is up to 2 business days (as noted within the ordering process)
• You are billed monthly (or yearly) for GoGrid Dedicated Servers, not hourly
• Outbound bandwidth charges for Cloud and Dedicated servers are combined (inbound is free for both)
• If you accidentally delete a Dedicated Server, please open a support case immediately and we will be happy to cancel your delete request.
• If you delete a server, the IP address assigned to that server is still “held” (not available for other servers) until the server is fully removed from your account
• Restarting a Dedicated Server does not show immediate feedback the way it does with Cloud Servers. Please “ping” the server to know its actual state.
• Windows Dedicated Servers are priced per processor so please ensure that you have chosen the proper image

List View of GoGrid Objects

So, where do you find your GoGrid Dedicated Server? Easy! Within the new List View. Many GoGrid users have asked for an easier way to view all of their GoGrid objects within a list. We now have a new tab called List which displays: Load Balancers, Cloud Servers, Dedicated Servers and Cloud Storage. There are definitely some GREAT things about the new List view like being able to see a large number of servers in one view, being able to copy and paste various fields like IP address, Object name, OS info, description, etc. Read on for some more details.

Selecting that tab presents you with all of your GoGrid structure within a list format where you can sort, group and rearrange various fields within each object set. To rearrange fields, simply drag them to the column you want them in. Clicking on a column will give you the ability to group and sort on those fields. Below is the Cloud Servers list:

Load Balancers appear as well:

As does Cloud Storage:

And, of course, Dedicated Servers!

Some important things to note about the new List View:

• If you have 30 or more Cloud Servers deployed within GoGrid, the new List View will quickly become your best friend.
• Just like within the Grid View, you can Restart, Delete and Retrieve passwords via menu actions at the top of the list panel.
• If you have a MyGSI deployed within your Cloud Server environment, it will show as “true” within the Sandbox field
• You can select values within the list and copy them to your clipboard. This is useful for copying IP addresses, for example.
• The Grid View will remain the default for the time being.

Edit F5 Load Balancers

You can now edit F5 Load Balancer details using the GoGrid API. We realized that many of our users wanted this functionality a long time ago. With this release, we have taken the first steps to make this fully functional. However, while you can edit via the API, as of this writing, you cannot edit via the portal (something we will change in the future). You can actively change the Load Balancer pool information without taking the Load Balancer offline. This is helpful if you want to add or remove servers from your Load Balancer.

We have added “grid.loadbalancer.edit” to the supported methods within the GoGrid API. There is Role Based access to use this method (Super User & System User are the role types that can invoke this method).

More information on this new API method can be found on the GoGrid Wiki. Do note that this feature is currently listed as a “beta.”

However, below is a way to edit your load balancers by simply using an call using a pre-defined URL. First, you will need to have an API key and Share Secret. You can create an API key under the My Account section and API Keys tab. Then you will need to create an MD5 Signature (documentation is on the Wiki on how to do this).

Here is the info:

• Craft the base URL with the following format:

  http://api.gogrid.com/api/grid/loadbalancer/edit?v=1.4

• Then you need to chain on (append) the following items:
  • &sig=your sig
  • &api_key=your key
  • &format=“xml” or “json” or “csv”
  • &name=name of LB to edit
  • &realiplist.0.ip=real IP 0 – first real IP to add to the LB
  • &realiplist.0.port=port for real IP 0
  • &realiplist.1.ip=real IP 1 – second real IP to add to the LB
  • &realiplist.1.port=port for real IP 1
• Then, take that full URL and paste into a browser and hit Enter. That should edit the Load Balancer based on the variables you entered.

Below is a sample (with dummy data) of what the URL should look like.

http://api.gogrid.com/api/grid/loadbalancer/edit?v=1.4&sig=md5hashsignature&api_key=abcd1234apikeyhere1234&format=xml&name=My+Load+Balancer&realiplist.0.ip=192.168.10.5&realiplist.0.port=80&realiplist.1.ip=192.168.10.6&realiplist.1.port=80

(Note: the line above is a single text string, it only has been broken into separate lines for readability.) The URL above has the following variables:

• Sig = md5hashsignature (see the documentation here)
• API Key = abcd1234apikeyhere1234
• Format = XML
• Name = My Load Balancer (Note: if your load balancer has spaces in the name, you should URL-escape them with either a “+” or “%20″) so that would look like “My+Load+Balancer” or “My%20Load%20Balancer”
• IP address of 1st server = 192.168.10.5
• Port of the 1st server = 80
• IP address of the 2nd server = 192.168.10.6
• Port of the 2nd server = 80

New Login Page

The GoGrid Web Portal login page also now has a new look & feel. We wanted to provide relevant information and links within that page so that you don’t have to go searching around for information. In the new login page, you can now find:

• New to GoGrid section – Getting Started Guide and GoGrid Wiki/Forum/Blog links
• Featured Content – important content related to GoGrid’s Features or Services will be displayed here
• GoGrid Exchange – looking for a particular partner image? This link takes you to the GoGrid Exchange.
• Featured Exchange Partner – look for highlighted Partners here

Self-Service Support Links

Making our user experience better on GoGrid is paramount. To that end, we have added a variety of links to make things a bit easier on the end user. For example, you can now quickly visit the GoGrid Wiki page that describes how to request that SMTP be unblocked for your GoGrid infrastructure:

Similarly, we have added some other helpful links within the portal to the GoGrid Wiki and User Forums:

And, as mentioned previously, we will provide full support within the GoGrid portal for all objects within GoGrid’s infrastructure. You can also use the Live Support Chat link to instantly chat with a GoGrid Support Specialist.

Other Items

As mentioned in this blog post, we are also end-of-life-ing a few older Red Hat Enterprise and CentOS servers.

Also, we have added a link to the GoGrid CDN within the portal. From this link, you can access the login page for the GoGrid CDN.

There was some pretty exciting stuff in this release and we would love to get your feedback. Drop us a note or leave a comment on this post if you have suggestions, comments or questions.

I have personally enjoyed documenting our achievements, analyzing trends, reviewing opportunities, showcasing new clients and partners as well as musing about Cloud Computing in general. Much of the writing on the GoGrid blog during 2009 was my own, however, the people who have helped provide me inspiration are countless, ranging from those within GoGrid to others creating the cloud community at large.

The journey through 2009 has definitely been an exciting one. Looking back on 2009 should make all users, creators and consumers of the cloud very proud. We have done a tremendous amount in 2009! So without further ado, below are a few selected posts of interest from the GoGrid blog for each month during 2009.

January 2009

• “Cloudcenters Are Datacenters In The Sky” – in this post, Randy Bias outlines his vision of what the “cloudcenter” meme truly is and how it is unique
• “Building A House In The Cloud – Cloudcenters Vs. Infrastructure Web Services” – in this post, I tried to simplify some of the differences between our new term of “cloudcenter” and “infrastructure web services” using a comparison to building a house.
• “GoGrid Releases API Specification To The Cloud Computing Community Under Creative Commons License” – GoGrid released our Application Programming Interface (API) under the Creative Commons Attribution Share Alike 3.0 License which allows users to share, distribute, display and make derivative works based on our API
• “New Windows Server 2003 & 2008 Images Added To GoGrid” – we continued to build out our Windows Server 2003 and 2008 image offering as the first to market with Windows Server 2008 in the Cloud
• All January posts are here

February 2009

• “Robert Scoble & FastCompany.TV Visit & Interview GoGrid” – we had some fun with Robert when he came to visit the GoGrid offices. Of course, this was a few weeks prior to him moving to a competitor of ours.
• “New Larger RAM Instances Now Available On GoGrid” – as the GoGrid infrastructure began to grow, we realized that customers wants larger instances with more persistent storage and RAM allocations.
• ““10 Obstacles To Cloud Computing” By UC Berkeley & How GoGrid Hurdles Them” – UC Berkeley came out with a comprehensive study on Cloud Computing. I didn’t agree with a lot of what was written so I posted my rebuttal.
• “Press Release: Appistry EAF Community Edition Available On GoGrid” – one of our first technology partners, Appistry, makes their product available on GoGrid.
• All February posts are here

March 2009

• “GoGrid Whitepaper: “Scaling Your Internet Business”” – Randy Bias produced a great whitepaper that discusses how web applications scale, scalability with the cloud, thinking through a choosing a scaling strategy and options available.
• “Navigating The Layers Of The Cloud Computing Pyramid” – a deeper analysis of the Cloud Pyramid, a term I coined in 2008.
• “Understanding GoGrid And Cloud Standards” – Randy Bias provides an analysis of the Cloud and standards therein, especially as related to the Open Cloud Manifesto (OCM).
• “Message From GoGrid Founders Regarding Denial Of Service Attack” – GoGrid survived heavy a DDoS attack which was targeted at a variety of hosting and internet service providers.
• All March posts are here

April 2009

• “New Feature: Job History – A Log File For GoGrid” – we continued to roll out new features and enhancements to GoGrid, including the Job History.
• “How To Set Up High Availability Web Applications In The Cloud Using GoGrid” – this was an interesting project that we undertook to showcase how to set up a redundant and resilient web application infrastructure using GoGrid.
• “Planning For The New GoGrid Feature – MyGSIs” – MyGSIs (personal server images) were just around the corner and I wanted to ensure that current GoGrid users were up-to-speed on the functionality therein.
• “Press Release: “ServePath Named ‘Cool Vendor’ By Leading Analyst Firm”” – GoGrid’s parent company, ServePath, was named “Cool Vendor” by Gartner.
• All April post are here

May 2009

• “McKinsey’s McCrazy! Flying Through The Clouds With Eyes 1/2 Closed” – McKinsey published a report “Clearing the air on cloud computing” which caused quite a stir within the cloud community. I was one of those “stirred up” readers and published my rebuttal to it.
• “Press Release: GoGrid And AppZero Partner To Ease Movement Of Windows Server Applications To The Cloud – another GoGrid technology partner, AppZero, was added to our growing list of Partners.
• “Network World Puts GoGrid In “10 Cloud Computing Companies To Watch” List” – recognition of GoGrid continued to grow within the technical press arena with Network World chiming in on GoGrid being one to watch
• “Video: GoGrid Cloud Computing Demo” – I started doing some screencasts of GoGrid in action and this was the first showcasing our award-winning GUI.
• All May posts are here

June 2009

• “Press Release: Cloud Computing Provider GoGrid Enables Highly Scalable Web Applications Using Zeus Technology” – Zeus Technology was added as a GoGrid technology partner, bringing an application traffic management solution to the GoGrid cloud.
• “Newsletter: GoGrid Customer Update V1.9” – since not all parties who were interested in GoGrid receive the GoGrid Customer Update, we started publishing it to the blog.
• “Last Chance – GoGrid Free Trial Credit Ends July 2nd!” – GoGrid was one of the only Cloud providers to offer a “free trial”. As our service matured, we decided to remove the $50 credit that all users were receiving.
• All June posts are here

July 2009

• “New Version Of GoGrid Released: Server Image Selection, RAM, API And Architecture Changes” – we revamped the Server Image Selection widget to allow for better usability.
• “Press Release: GoGrid Placed In Visionaries “Magic Quadrant”” – GoGrid was placed in the “Magic Quadrant” by Gartner, something that was very exciting for us!
• “Press Release: SOASTA Announces Cloud-Based Performance Certification Program For Websites And Applications” – GoGrid announces support for the CloudTest On-Demand service.
• All July posts are here

August 2009

• “Introducing GoGrid Version 2.0” – this was a huge accomplishment for us as we released GoGrid 2.0 to the general public which included: MyGSIs (personal server images), improved deployment times and other features & enhancements.
• “Press Release: GoGrid And Stratonomic To Enable Disaster Recovery In The Cloud” – GoGrid and Stratonomic partner to provide Disaster Recovery solutions using the GoGrid cloud.
• “GoGrid Officially Out Of Beta!” – after 1.5 years of running under a public beta (fully supported however under our SLA), we officially removed the beta tag from the GoGrid core infrastructure offering.
• “GoGrid Says: We’ll Load Your Data Into The Cloud” – we added a service to allow people to physically ship their hard drives to us for data loading to GoGrid Cloud Storage.
• All August posts are here

September 2009

• “3 GoGrid Executives Discuss Their Thoughts On VMWorld 2009, The Cloud & GoGrid” – after our recent participation in VMWorld 2009, I spent some time interviewing some of the GoGrid executives on their thoughts of the show.
• “GoGrid Updates MyGSI Features: Edit, Delete & Restore & Other Changes” – we continued to improve on the new MyGSI features and functions as well as some other infrastructure enhancements.
• “Video: Edit, Delete & Restore GoGrid’s MyGSIs & Billing Widget Explained” – another screencast showcasing some new GoGrid features related to MyGSIs.
• “Announcing Microsoft WebsiteSpark Fortified With GoGrid, ServePath & Hybrid Hosting” – GoGrid becomes a WebsiteSpark Hosting Partner.
• “Newsletter: GoGrid Customer Update – October 2009” – our newsletter to GoGrid customers discussed the recent enhancements to the service.
• All September posts are here

October 2009

• “Press Release: GoGrid & GigaSpaces Join Forces To Create An Enterprise-Grade PaaS Offering For Java And .NET” – GoGrid and GigaSpaces partner to enable GigaSpaces XAP in the GoGrid Cloud.
• “The Microsoft/Danger/T-Mobile Sidekick Fiasco Is NOT A Failure Of Cloud Computing!” – when Danger/T-Mobile had issues with their data service, people immediately started calling it a failure of the cloud. I wrote about how I disagreed with this statement.
• “Intel’s Latest Generation Microarchitecture, Codenamed “Nehalem” To Power GoGrid Cloud” – GoGrid pursues the use of Intel’s new Nehalem chipsets within the GoGrid cloud.
• All October posts are here

November 2009

• “CNN Copies GoGrid’s “Cloud Computing Explained” Video?” – CNN produced a “Cloud Computing Explained” video which was eerily similar to the one we produced (which has over 120,000 views)
• “Interviews At Sys-Con Cloud Computing Expo ‘09: F5 Networks And GoGrid” – while we were exhibiting at the Sys-Con Cloud Computing Expo, I spent some time with our partner F5 talking about the cloud.
• “Scale Your Web Presence Globally Via GoGrid Content Delivery Network (CDN)” – GoGrid announced a worldwide Content Delivery Network for GoGrid customers.
• “GoGrid Announces New Pricing & More Volume Discount Plans” – as GoGrid continued to mature, we decided to provide greater discounts and more RAM/Bandwidth allocation within each plan.
• “Newsletter: GoGrid Customer Update – November 2009” – our November newsletter was delivered to customers and we provided the update on the blog.
• “Rapidly Develop, Test & Deploy Windows Azure Applications Using The GoGrid Cloud” – GoGrid and Azure are showcased in a video demonstrating how the two can be used to work with Azure application development and testing.
• All November posts are here

December 2009

• “GoGrid Exchange: BitNami Open Source Web Applications Images Available” – GoGrid launches Partner GSIs with BitNami providing Open Source web Application images within the GoGrid cloud.
• “GoGrid Exchange: GigaSpaces XAP On GoGrid Enterprise Cloud Now Available” – GigaSpaces XAP becomes available within the GoGrid Exchange.
• All December posts are here

Whew! If you made it all the way to the end of this post, I congratulate you! If you have read all of the linked articles, you deserve an award or are truly a GoGrid Fan (by the way, be sure to become a fan of GoGrid on our Facebook page).

I hope that 2009 was as outstanding for you as it was for us!

In particular, myself and Steve Gillmor (of TechCrunch IT fame among others), had a somewhat heated, but friendly exchange over his scathing assessment of the situation. Steve invited me to a “News Gang” podcast of the Gillmor Gang on Friday, which was posted here. During that live podcast he asked us to clarify GoGrid’s position.

This post is really about making sure everyone is on the same page and understands how GoGrid views the OCM and cloud computing standards in general.

Background
It’s unnecessary to recap everything in detail. I think James Urquhart handled this fairly succinctly. Geva Perry also has a nice summary including a link to the draft document. In a nut:

1. Some folks tried to lay down some guiding principles for “open” cloud computing in the Open Cloud Manifesto
2. Some folks reacted badly feeling that the process wasn’t actually “open”
3. Bruhaha ensued

Who cares?

Well, we all should really. From our perspective this is a healthy, yet contentious debate. We think there were good points and missteps on all sides. In particular, we think it’s important to realize that given how interconnected we’re all becoming it’s actually very hard for any given group to monopolize the Internet, the “cloud”, or similar.

We believe the following to be true about what happened:

• The folks involved in the early Open Cloud Manifesto did not intend to “shut out” anyone
• The process around building the Open Cloud Manifesto could have been more ‘open’
• The manifesto is not about setting a standard, but starting a conversation
• This “conversation” is meant to be about principles that already apply to the Internet

Position on Open Cloud Manifesto
We continue to be an enthusiastic supporter of the Open Cloud Manifesto (OCM) and open cloud standards in general. That’s why we licensed our own API under an open license in January. The OCM is an important move forward in the emerging debate about what “Cloud” and “Cloud Computing” mean. We do not support any kind of exclusion in the OCM or of folks who want to be it’s supporters. We believe everyone needs to have a say in these guiding principles. In fact the OCM itself is largely about saying how much “The Cloud” needs to be open, unfettered, and democratized.

That means everyone needs to be involved.

Summary
Simply put: contentious conversations, vibrant arguments, and great people will all eventually yield the right results. We don’t think it’s possible for anyone to cordon off and monopolize this conversation, foist standards on others, and won’t support such efforts. And, we don’t think the Open Cloud Manifesto is anything but a well-intentioned attempt to move the conversation forward. One that was never meant to be ‘closed’ and come Monday when it’s officially released we’ll see that it’s a positive move and all of the folks who worked together on the OCM (including Reuven Cohen, IBM, and many others) should be commended for their attempts to get everyone on the same page even in the face of extreme controversy.

–Randy

The 20+ page study is authored by Michael Armbrust, Armando Fox, Rean Griffith, Anthony D. Joseph, Randy H. Katz, Andrew Konwinski, Gunho Lee, David A. Patterson, Ariel Rabkin, Ion Stoica and Matei Zaharia who all work in RAD Lab. (Interestingly, several of the companies mentioned within the study are also Founding Sponsors and/or affiliate members: Sun, Google, Microsoft, Amazon Web Services, etc.).

There has already been plenty of discussion and analysis of this study (by James Urquhart, Krishna Sankar and has even appeared on Slashdot.org). Needless to say, I felt compelled to get my two cents in, especially from the perspective of a Cloud Computing Infrastructure vendor.

From an academic standpoint, this document definitely has some legs. It is complete with carefully thought out scenarios, examples and even formulae, as well as graphs and tables. Some of the points that are brought up even got me scratching my head (e.g., using flash memory to help by “adding another relatively fast layer to the classic memory hierarchy”). Even the case analysis of a DDoS attack from a cost perspective of those initiating an attack to those warding off an attack on a Cloud was interesting to ponder. I commend these group of authors on undertaking such a grand task of not only writing by committee but also overlaying a very business school vs. mathematics and computer sciences approach to the writing and analysis.

Unfortunately, however, as I read through the document, I started scrawling madly in the margins with commentary that is somewhat contrary to what was written within the study.

A Few Comments from the “Peanut Gallery”

I don’t want my article to come off as a complete rebuttal to what is written in this study. Quite the contrary. I’m encouraged that one group within the academic community has taken considerable time and effort analyzing and writing about the Cloud. What appears below is a small “laundry list” of things that need to be called out and is a mixture of positive and negative comments:

• EECS’s Cloud Computing definition – “Cloud Computing refers to both the applications delivered as services over the Internet and the hardware and systems software in the datacenters that provide those services. The services themselves have long been referred to as Software as a Service (SaaS), so we use that term. The datacenter hardware and software is what we will call a Cloud.”^[1]
  My comments: I personally found this definition to be incomplete and potentially misleading. While the EECS is correct in including SaaS (Cloud Applications) as a subset of Cloud Computing, they have (consciously?) lumped everything else into a catch-all phrase of “hardware and system software.” For people to truly understand Cloud Computing, I feel that it is important to become much more granular in defining the layers of the Cloud (Cloud Applications, Cloud Platforms and Cloud Infrastructure – the “Cloud Pyramid”, a term I coined last year). I actually found it interesting that the group of authors couldn’t agree what the precise differences between the “X as a Service” were.^[2] In order for all of the assumptions and conclusions to take place, I would have thought that clearly defining what the “Cloud” is would be paramount to the success of the findings.
• 3 Important Technical Aspects of the Cloud – the group outlines three items of the Cloud: 1) “infinite computing resources” 2) “elimination of an up-front commitment” and 3) “pay for use of computing resources on a short-term basis as needed.”^[3]
  My comments: For the most part, I agree with these statements. However, #3 is a bit skewed towards an Amazon EC2 model. At GoGrid, we are pioneering the idea of a “cloudcenter” (a datacenter in the Cloud) which presents a different paradigm. EC2 has long been touted as being a way for quick batch processing where instances are spun up, consumed and then discarded. This falls within the third aspect that is defined above. However, when you take the view of creating a “datacenter in the cloud,” there is less of a “quick use function” and more of a scalable infrastructure notion designed to replace traditional datacenters and associate infrastructures.
• New Application Opportunities – several new or emerging opportunities designed to capitalize on the benefits of the Cloud are outlined: “mobile interactive applications,” “parallel batch processing,” “the rise of analytics, extension of compute-intensive desktop applications,” and “‘earthbound’ applications.”^[4]
  My comments: I’m actually glad to see these so carefully explained as they do cover many aspects that are potentially “unique” to the Cloud: dynamic storage, dynamic availability, scalable processing and compute power, and cost-effectiveness to name a few.
• Classes of Utility Computing – Amazon’s EC2 is at one end of the spectrum and Google AppEngine and Force.com is at “the other extreme” with Microsoft Azure falling somewhere in the middle. Also, “virtualized resources” are broken up into 3 classes: Computation, Storage and Networking^[5]
  My comments: For starters, since the group was unable to fully define the Cloud “spectrum,” it’s difficult to understand how they place EC2 at one end and having the spectrum “end” at Cloud Platforms (e.g., Force.com or AppEngine). The “full” spectrum must include SaaS as well as PaaS and IaaS in order to fully encompass the definition. Gmail and SalesForce exemplify SaaS and definitely should be contained within the Cloud mantra. Microsoft Azure, Force.com and Google AppEngine are truly Cloud Platform. Perhaps within the Platform layer, Azure and AppEngine are far between, they do, however, occupy the same Cloud space of “here is a development environment, you must work within it” (e.g., Python, .NET). Cloud Applications are simply “here is a web-based software application that is available for consumption and you have minimal flexibility in terms of controlling it.” Lastly, Cloud Infrastructure works as “enjoy full control over your infrastructure despite the fact that it is a bit more challenging to control.” For the most part, the 3 virtualized resources do fall within what is outlined. Storage can be expanded to include “Cloud Storage” (dynamic), “Persistent Storage” (traditional) and “Volatile or Temporary Storage” (typically associated with EC2 instances where storage disappears when the EC2 instance is destroyed or goes down).

I could probably nitpick through some other items, but I will leave that up to you.

Comments from a Cloud Vendor perspective

In Section 7 of the study, the EECS group presents “10 Obstacles and Opportunities for Cloud Computing” which definitely should be addressed. For this section, I’m putting on my “GoGrid Green” colored glasses and presenting points and counter-points to each of the 10 items outlined. Again, this is not intended to come off as a ping-pong match, but rather a commentary and opportunity for dialog. I encourage you to read this section prior to reviewing my responses. I have tried to briefly paraphrase each item (but that probably doesn’t do it justice).

1. Availability of a Service – “will Utility Computing services have adequate availability”^[6]
   My Response: The study outlines outages specific to the Cloud, citing S3, AppEngine and Gmail in particular. I have said this before, outages happen and they are not unique to the Cloud. Natural and human-caused disasters occur. Hurricanes and cable cuts can affect all sorts of infrastructure. As with a traditional datacenter, in-house or outsourced, traditional or in the Cloud, a disaster failover and redundancy strategy should be part of an IT department’s general strategy for success or just survival. One thing to consider is mirroring or creating redundancy on different types of infrastructures: if your primary is in the Cloud, have a dedicated failover; if your colo is on the East Coast, think about something on the West. Also look beyond simply the service and review the Support organization, the Service Level Agreement (SLA) and the provider’s expertise within the field. GoGrid, for example, has 24×7 Free support, the most robust SLA of any Cloud provider and over 9 years of hosting experience and expertise.
2. Data Lock-in – “the API’s for Cloud Computing itself are still essentially proprietary”^[7]
   My Response: Unfortunately it seems that GoGrid’s announcement back in January of this year where we discussed how our GoGrid cloudcenter API has been put under a Creative Commons Sharealike license was somehow overlooked when compiling facts for this study. Our idea behind this move is to start working standards from the ground up. GoGrid is also an active participant in many of the interoperability meetings around the country. Part of the reason why we released our API to the community at large is to demonstrate our commitment to open standards. We also have modeled the GoGrid cloudcenter extremely closely to a traditional datacenter where all of your hardware, protocols and connectivity is familiar. This helps lessen the “lock-in” scenario and avoids the use of proprietary API’s and other components. Also mentioned is “surge computing” which is another term for “cloud bursting” or “hybrid” clouds. Our Cloud Connect offering works exactly in this way, where users can opt to have high-end, large I/O databases, for example, reside within a traditional, managed hosting environment (through ServePath, our parent company). Cloud Connect allows for scalable and dynamic web front-ends, hosted in the GoGrid Cloud, to connect via a dedicate private network to higher-end servers in a managed hosting back-end.
3. Data Confidentiality and Auditability – “current cloud offerings are essentially public (rather than private) networks, exposing the system to more attacks”^[8]
   My Response: The statement above is rather alarmist in nature. I agree that many efforts should be made to ensure the resiliency and security of the Cloud, and these efforts are well underway at GoGrid as well as other Cloud providers. Again, however, this is not something completely unique to the Cloud. Any hosting provider or datacenter (or cloudcenter for that matter) must ensure that security and the integrity of the network and infrastructure is maintained at a high standard. GoGrid, for example, is SAS70 Type II audited and certified. The EECS’s statement, however, is not a completely honest assessment. Public vs. Private datacenters, dedicated hosting or clouds are very different. The concerns of publically hosted infrastructures are really no different whether in the cloud or in a datacenter; they will both be inherently a bit more vulnerable. However, I would say that companies whose business it is to solely do hosting will potentially have more robust security protection and attack prevention measures in place than a self-hosted or even private cloud would. In terms of HIPAA compliance or Sarbanes-Oxley, there are stringent requirements of data protection, privacy and isolation. While it may be difficult to pass accreditation for these types of compliances “in the cloud”, using a feature like Cloud Connect, for example, allows for compliance to take place on a dedicated, warehoused set of servers within a traditional datacenter, something much more palpable and acceptable.
4. Data Transfer Bottlenecks – “applications continue to become more data-intensive”^[9]
   My Response: It’s all about the data, I agree. The Cloud is an ideal environment for statistical analysis and number crunching. I personally know of one GoGrid user who would spin up multiple instances of GoGrid servers, upload a huge amount of data, run some analysis programs and then export the resulting summaries, all in a matter of hours and only costing a few dollars. The arguments presented by the EECS group are true; until we get the ability to transfer large amounts of data through very big pipes at a extremely lost cost, this could be a barrier for those customers who may be considering the Cloud as a data eating machine. However, when we at GoGrid designed our business model, we kept scenarios like this in mind and came up with an easy solution: make all inbound data transfers free. This way, GoGrid users can upload large amounts of data to their cloudcenter, move that data around within the private network therein, put some on Cloud Storage should they desire, analyze to their hearts content and then download the summary or result sets (typically much smaller in file size than the data going in). GoGrid does charge for outbound but you can see how the pricing model works to the user’s advantage in analysis scenarios.
5. Performance Unpredictability – “multiple Virtual Machines can share CPUs and main memory surprisingly well in Cloud Computing, but that I/O sharing is more problematic”^[10]
   My Response: This is a very good point and difficult to fully refute. It’s true that CPU and RAM can be virtualized, managed and isolated extremely well. Disk I/O performance can suffer at times. Again, this is part of the reason we offer a solution for this with Cloud Connect (see previous statements). It is frequently better to offload extremely intensive I/O processes to a dedicated environment, at least until virtualization technology gets more aligned with bare-metal performance. We even released a “custom patch” for 64-bit Linux users on GoGrid that helps increase disk drive performance. While some may says that this is a bit non-standard, it does show our understanding of this concern and marks an effort to resolve or minimize the impact.
6. Scalable Storage – short-term usage, no up-front cost and infinite capacity on-demand doesn’t apply to persistent storage^[11]
   My Response: I have to agree somewhat to this idea, however it is a bit of an oxymoron. Persistent storage requires that it is dedicated in some way, available at all times and easily usable. On EC2, for example, if your instance dies, you lose any persistence of data, which is part of the reason why they recommend using S3 (their Cloud Storage offering). This is logical from so many standpoints: redundancy & share-ability are two that immediately jump to mind. Again, at GoGrid we took a slightly different approach by making all GoGrid Cloud servers have persistent storage available from the beginning. The amount of persistent storage is directly tied to the amount of RAM you have allocated: if you choose a higher RAM instance, you get more persistent storage. However, I don’t see scalable storage to be an obstacle entirely. Amazon offers S3 and GoGrid has a similar Cloud Storage offering. Both are scalable on demand, billed by usage and usable by Cloud Servers. GoGrid’s Cloud Storage is mountable as a drive and shareable among a user’s GoGrid servers within the GoGrid infrastructure using industry standard protocols (e.g., SAMBA, CIFS, RSYNC & SCP). To that end, in my mind it does meet the 3 properties outlined with the omission of the “persistent” adjective.
7. Bugs in Large-Scale Distributed Systems – “one of the difficult challenges in Cloud Computing is removing errors in these very large scale distributed systems”^[12]
   My Response: This is actually one obstacle that I fully agree with. Often it is difficult to “mirror” physical, large scale computing environments within the Cloud. Unfortunately, it is not an apples-to-apples comparison. One simply cannot just “port” a physical, complex infrastructure over to the Cloud. If you do, you will fail. You need to architect your Cloud environment capitalizing on the efficiencies and features of the Cloud. Otherwise, you simply translate (and potentially compound) issues existing previously further. Another thing to consider is that all Virtualization or Hypervisor technologies have bugs, as with any software for that matter. The complexity of a Cloud environment is multi-fold: at the hypervisor and management layer, the hardware layer of the grid or utility architecture, as well as within the VM’s themselves. This is a complicated and delicate environment. The good news is, because this is technology that is around to stay, and is consistently being built upon, refined and improved, the end results are only improvements. Important to this again is interoperability and standards, similar to the Wild West becoming civilized and engineered. Bugs will be squashed and efficiencies gained through increased R&D efforts as well as customer adoption and validation.
8. Scaling Quickly – “automatically scale quickly up and down in response to load in order to save money, but without violating SLAs”^[13]
   My Response:  This is one of the key value propositions of Cloud Computing. You must be able to scale up and down based on demand (or even based on a budget). Much of this can be done using API’s or companies like RightScale. As I mentioned previously, Design for the Cloud. Traditionally, companies over-bought their infrastructure, saving it all for a rainy day. At ServePath, we know for a fact that CPU, RAM and Storage on our dedicated machines are only hitting about a 5% utilization on average. Many companies have built up their infrastructure for the “what if” scenarios. These inefficiencies are part of the reason why Cloud Computing has become so popular, a panacea of sorts. When you design for the cloud, you must ensure that your strategy capitalizes on scalability, both up and down, but also on redundancy and persistence. Of course, it all depends on the type of system you are architecting (persistent – a store-front or content driven marketplace, or temporary – data analysis, bulk processing).
9. Reputation Fate Sharing – “reputations do not virtualize well”^[14]
   My Response: I feel that this fully depends on how a Cloud provider crafts their offering. The example given in the EECS study is that of blacklisted EC2 IP addresses due to spamming. This is a valid concern but is due to how AWS releases their public IP address back “into the pool” once an instance is removed or destroyed. At GoGrid, we took a different approach. For starters, all users are assigned a contiguous block of static public IP addresses. When a GoGrid user deletes a server, that public IP address is released back into THEIR pool and not a general pool. Thus, if an IP address gets flagged by a spam-prevention service as being “bad,” the “bad reputation” is contained within a particular GoGrid user’s environment and not the entire GoGrid user base. Similarly, by default, we block all outbound SMTP traffic by default. Users who wish to use this protocol must request this block be lifted. Also, while somewhat inconvenient, this one-time action does help to maintain a positive reputation for a vendor as a whole. Be sure to carefully review a vendor’s SLA, Terms of Service (TOS), Privacy Policy and Acceptable Use Policy (AUP).
10. Software Licensing – “licensing models for commercial software is not a good match to Utility Computing” & “pay-as-you-go seems incompatible with the quarterly sales tracking”^[15]
    My Response: Software licensing models are being forced to evolve to be able to handle the on-demand nature of the Cloud. While Amazon took the approach of increasing the hourly charge to handle licensing of Windows Server vs. an open-source alternative, GoGrid, in order to maintain simplicity, rolled it all into one (no difference between Red Hat, CentOS or Windows). Licensing of Microsoft SQL Server on GoGrid, for example, is handled through a monthly (not hourly) charge. This helps with both a customers budget projections as well as from our own sales projections. Simplicity in explanation and execution is critical. If your user is confused as to how the billing works or how to project what charges they will incur, they will not execute. Token billing, tied to hourly charges will also become increasingly prevalent.

Summing it all up

If you made it both through the EECS group’s study as well as this blog post, I truly commend you, and you hopefully have a better understanding of the Cloud Computing term and properties therein, especially from the standpoint of an academic institution and Cloud Computing vendor. While I have challenged a few of the statements made within the study, there are others that stand up just fine. The important overall idea here is that serious brainpower and resources are being thrown at the Cloud, from understanding and analysis standpoint to development and execution therein.

A special message to the EECS group: I would personally like to invite you all cross the Bay (from Berkeley to San Francisco) to come and visit a Cloud Computing provider who is already overcoming the obstacles you have outlined. We would love to have a round-table discussion about the Cloud and help you with the next version of this study.

1. M. Armbrust, A. Fox, R. Griffith, A. Joseph, R. Katz, A. Konwinski, G. Lee, D. Patterson, A. Rabkin, I. Stoica, and M. Zaharia. Feb 10, 2009. “Above the Clouds: A Berkeley View of Cloud Computing.” Electrical Engineering and Computer Sciences. University of California at Berkeley. http://www.eecs.berkeley.edu/Pubs/TechRpts/2009/EECS-2009-28.html p. 4
2. ibid. p. 4
3. ibid. p. 4
4. ibid. pp. 7-8
5. ibid. pp. 8-9
6. ibid. pp. 14-15
7. ibid. p. 15
8. ibid. pp. 15-16
9. ibid. pp. 16-17
10. ibid. pp. 17-18
11. ibid. p. 18
12. ibid. p. 18
13. ibid. p. 18
14. ibid. p. 18
15. ibid. p. 19

The lower size RAM instances (0.5, 1 & 2 GB) are perfect for a web front-end, where either Apache or IIS are running. For extremely high-performance and high I/O instances, we have been offering Cloud Connect as a way to create a dedicated hybrid infrastructure where Cloud Web Servers running on GoGrid can be linked via private dedicated network connections to dedicated and managed servers within the ServePath network.

With the new 4 and 8 GB RAM options, you can now set up a infrastructure with a robust set of high-performance application servers within the Cloud. These types of high RAM instances are perfect for users who want to take advantage of the increased RAM, CPU cores and persistent storage, especially when used in conjunction with specific applications (e.g., Microsoft SQL server or other Enterprise applications) that require more larger amounts of resources like RAM or CPU.

The 4 GB RAM server images can be deployed via the GoGrid web portal and API. The 8 GB RAM server images currently may only be deployed via the GoGrid API. I recommend reading the API section of the GoGrid wiki in order to fully understand how to deploy 8 GB RAM instances.

The 4 and 8 GB RAM images, available for Red Hat Enterprise Linux 5.1, CentOS 5.1, and Windows Server 2003 and Windows Server 2008 64-bit operating systems bring a new level of performance to the GoGrid line. 4 GB Cloud Servers have 3 CPU Cores and 8 GB have 6 CPU Cores, ensuring dedicated CPU allocations and high performance.

All GoGrid Cloud Servers come with persistent storage. The new larger RAM allocations announced today, are delivered with increased persistent storage: 4 GB Cloud Servers have 240 GB of hard drive space and 8 GB have 480 GB of storage allocated at boot time. Additional storage can be added using GoGrid’s dynamically scalable Cloud Storage offering which includes a 10 GB free allotment to start with. Each 1 GB thereafter costs $0.15/GB/month.

Our current breakdown of GoGrid Cloud Servers and associated RAM/CPU/Persistent Storage is as follows:

Further information on the new 4 and 8 GB RAM GoGrid Cloud Servers can be found on the GoGrid site. Server Release Information on these new images can be found on the GoGrid wiki. We have also posted a Server Compatibility Matrix that graphically shows what server instances are available with the associated RAM allocations.

If you are a Windows user, we ask that you please our Release and Errata pages as there are some known issues specific to 8 GB Windows Servers which may require a workaround and that they should be aware of before using 8 GB GoGrid Servers with Windows.

Our full Press Release on this information can be viewed here as well as on the GoGrid site.

As always, please leave any questions or comments here on this blog post, or open a Support case via the GoGrid portal should you need technical assistance.

• Distinction and clarifications around the terms “Cloudcenter” and “Infrastructure Web Services” as they existing within the Cloud Infrastructure layer. (More reading on cloudcenters can be found here and here.)
• Understanding GoGrid’s approach to standards and interoperability, especially as they relate to datacenter and infrastructure standards
• Platform-as-a-Service (PaaS) providers such as Google App Engine and how Cloud Infrastructure (Infrastructure-as-a-Service) and GoGrid fits in
• Discussion around how we recently put our GoGrid API under a Creative Commons license as well as our efforts to involve other cloud providers and vendors, such as Flexiscale, RightScale and Eucalyptus, in building open standards from the ground up (more info here)
• How GoGrid is working with Puppet and Chef technologies to automate system administration and configuration management
• Using GoGrid’s Cloud Connect offering to “cloudburst” and create hybrid infrastructure topologies using the dynamic scalability of Cloud Web Servers and the robust, high I/O throughput of dedicated backend servers
• …and much more…

We encourage you to listen to this podcast to gain some insight on our thought leadership, concepts and ideas around Cloud Computing, GoGrid and the hosting industry in general. This (and all) podcasts are available in a variety of formats:

• Download Overcast Podcast #6 as an MP3 File
• Subscribe to Overcast in iTunes (Note: this link will attempt to launch iTunes.)
• Play from this site (click on the graphic below)

As always, feel free to leave any questions or comments you may have on this blog or on the Overcast post.

The Creative Commons Attribution Share Alike 3.0 license, under which the GoGrid cloudcenter API now falls, allows for the ability to:

• Share, distribute, display and perform the work
• Make derivative works

The GoGrid cloudcenter API re-use must, however, fall under the following Share Alike licensing conditions:

• There must be full attribution to GoGrid, author and licensor
• There is no implied endorsement by GoGrid of any works derived from the API usage or rework
• After any transformation, alteration or building upon this work, any distribution must be under the same, a similar or a compatible license
• You must make it clear to others about the terms of this license. The best way to do this is by linking to the GoGrid Wiki API page (link below)
• Any of the conditions mentioned previously can be waived with permission from GoGrid

Details on the GoGrid cloudcenter OpenSpec API license can be found within the GoGrid site and is specific to the API only. All content provided on the Wiki in the API “namespace” is covered by this Share Alike license, specifically under this URL: http://wiki.gogrid.com/wiki/index.php/API. Note however, this license applies only to content provided within the namespace plus any pages constrained by the URL plus a colon (“:”). For example:

INCLUDED under the license:

• http://wiki.gogrid.com/wiki/index.php/API:Anatomy_of_a_GoGrid_API_Call
• http://wiki.gogrid.com/wiki/index.php/API:Common_API_Call_Patterns
• http://wiki.gogrid.com/wiki/index.php/API:PHP_API_Developer_Home

NOT INCLUDED under the license:

• http://wiki.gogrid.com/wiki/index.php/API_Getting_Started_Guide

FAQs

1. How can I use it?
   Anything that falls under the http://wiki.gogrid.com/wiki/index.php/API including anything within the namespace constrained by a colon is considered free-use under the Creative Commons license. You are free to view and edit, as well as re-work and re-publish changes to the API as you see fit.
2. How can’t I use it?
   You cannot modify and re-publish or resell the GoGrid cloudcenter API without including attribution to GoGrid. We recommend that you do include a document, publically published and accessible, that discusses what changes were made to the GoGrid cloudcenter API.
3. How do I publish changes?
   Any changes to or modifications of or repackaging of the GoGrid cloudcenter API should be documented on a public server and must include a link back to the GoGrid cloudcenter API documentation on the wiki.
4. Do I need to notify you when I make a change?
   We encourage you to notify us when you publish modifications to the API. We will also monitor links or trackbacks to the GoGrid API documentation. Notification, however, is not a requirement. Documentation and attribution is, however, required.
5. How do you notify me when GoGrid makes a change to the spec?
   We recommend that you regularly check the API namespace within the GoGrid wiki for changes or updates to the OpenSpec API.
6. Why is it important to notify GoGrid of changes?
   In our effort to work towards driving standards, interoperability and transparency within the Cloud Computing Marketplace, communication between and by users and developers using the API will aid in a broader acceptance and usage within the community.

If you have additional questions regarding this information, feel free to leave a comment to this article.

It is our vision and goal within GoGrid to foster community building and collaboration within the Cloud Computing market. Our commitment to this vision is evident with this release of the GoGrid cloudcenter API under the Creative Commons Share Alike license.

Understanding IaaS means looking closely at these two approaches.  Clearly the notion of cloudcenters embodied by AWS competitors such as ourselves, FlexiScale, ElasticHosts, AppNexus, and others is important.  My colleague, Michael Sheehan, will go into more depth on how we think this distinction modifies his earlier Cloud Pyramid (right) in a follow-on blog posting to this one.

Infrastructure Cloud Models

Understanding these two approaches is important because it directly affects your selection of a Cloud Infrastructure provider.  These two models highlight a difference in core infrastructure and in target markets. Cloudcenters provide a direct equivalent to traditional datacenters and hence are usually more desirable for IT staff, systems operators, and other datacenter savvy folks.  Infrastructure Web Services on the other hand are more analogous to Service-Oriented-Architectures (SOA), require significant programming skills, and are much more comfortable for software developers.

Infrastructure Web Services

I’m going to assume for this article that you are somewhat familiar with Amazon Web Services (AWS), but I’ll briefly re-cap.  AWS provides a number of different ‘Web Services’ that can be consumed individually or put together to support different kinds of applications, usually a batch processing or web application of some kind.  These services include:

• Object-based file storage via Simple Storage Service (S3)
• Servers on demand via Elastic Compute Cloud (EC2)
• Block storage on demand via Elastic Block Storage (a part of EC2)
• Distributed database functionality via SimpleDB (SDB)
• Content distribution and edge-caching via CloudFront
• Messaging & queuing via Simple Queuing Service (SQS)
• Payment processing via Flexible Payment Services (FPS)
• Billing & re-packaging of the above services via Amazon Dev Pay

This is a robust ecosystem of services from which you can use any or all in order to build your application, getting the traditional benefits of Cloud Computing such as self-service, pay-as-you-go, and massive scalability.

Unfortunately, every service above is based on an Amazon standard, not an industry standard.  S3 is not accessible via CIFS or NFS.  EC2 provides Xen hosting, but image management and storage is completely custom.  SQS does not use any standard queuing or messaging protocols such as JMS or STOMP.  SimpleDB now has an ‘SQL-like’ interface, but is essentially a 100% ground up creation of Amazon.

A major advantage of using the Amazon approach however is that greenfield applications developed from scratch have a very powerful set of vetted, scalable services, that can be used to build that application.  This means avoiding the intrinsic and extrinsic costs associated with deploying a separate queuing or database system.

The alternative, of course, is to use the same tools, paradigms and standards that you deploy in an industry standard Enterprise datacenter today.

What’s a Cloudcenter?

Cloudcenters are that solution.  They provide the same kinds of tools that all datacenter and server operators are already accustomed to, but with all the traditional advantages of cloud (i.e. self-service, pay-as-you-go, and scalability).  Instead of creating completely new paradigms, cloudcenters are a methodology by which you, the customer, can have a virtual datacenter hosted ‘in the sky’.  Each virtual datacenter, a ‘grid’ in GoGrid terminology, is hosted in isolation from other customers, in a cloudcenter as shown in the diagram below:

Your grid is akin to a traditional datacenter whereby you have all of the regular components you expect such as hardware firewalls^[1], hardware load balancers, network storage (NAS or SAN^[2] ), virtualized servers, dedicated networks (VLANs), and the option for physical servers for workloads that should not be virtualized.

Logically, a grid looks like:

As you can see, this looks very much like a traditional datacenter infrastructure.

Traditional Datacenters and The Cloud

Just briefly I want to highlight what is in a ‘traditional’ datacenter.  These are all built in the same way.  The following diagram highlights the typical components in a datacenter and their relative dependencies on each other.  (This diagram isn’t perfect, it’s simply meant as a talking point.)

Cloud Infrastructure providers are in the business of providing you the equivalent functionality in the cloud using their scale for cost-effective service delivery.  They must also package this functionality to provide you a high level of control as it’s no longer your datacenter.  Control comes through a user interface (GUI), programming hooks (API), transparency (SAS70 audits), and performance and reliability guarantees (SLAs).

Cloudcenters focus on making your Cloud Infrastructure look very much like infrastructure you already have or are already familiar with, while Infrastructure Web Services ask you to embrace a new paradigm.

Cloudcenter Advantages

Besides the obvious advantage of ‘looking like’ your current datacenter, cloudcenters allow for strategies like using the Cloud for off-site disaster recovery.  It will be much easier to model a copy of your current datacenter to a cloudcenter than it would be to model a copy onto a Infrastructure Web Service.  There are many other advantages to the cloudcenter approach such as:

• Servers meant to be reliable not ‘unreliable-by-design’ on commodity hardware
• Cloudbridging^[3] will be much easier between dedicated VLANs on each side using IPSEC VPNs
• Cloudcenters will look more and more like each other over time, while there will probably never be another AWS
• Datacenter software tools will ‘just work’ with datacenter & cloudcenter standards
• User Interface for controlling the entire datacenter including firewalls and loadbalancers, not just servers^[4]
• Let your cloudcenter provide core infrastructure services like DNS, DHCP, NTP, and image management

Cloud Choices

Ultimately it’s great that there is so much choice when selecting a Cloud Infrastructure provider.  Both Amazon and GoGrid provide compelling solutions.  We believe that GoGrid, the very first public cloudcenter, is the Cloud of choice for sysadmins, operators, and Enterprise IT staff who need infrastructure that looks just their current datacenter infrastructure.

In the future we’ll blog in much more detail contrasting and comparing these two approaches to building Cloud Infrastructure services.

1. To be released in 1Q09
2. Scheduled for 2009
3. The ability to transparently connect you internal datacenter to your external virtual datacenter or cloudcenter
4. Imagine VMware VirtualCenter++