Today, New Relic announced that their RPM product supports GoGrid Cloud Hosting Infrastructure and is available for a limited time with preferential pricing. RPM is an on-demand tool that companies can use to optimize, monitor and troubleshoot their Java, Ruby and JRuby applications within a variety of environments, which now includes the GoGrid cloud.

With New Relic’s RPM running on GoGrid, users can monitor many aspects of a Ruby, Java or JRuby application, detect performance problems and eventually drill down to uncover root causes of any performance issues. RPM also cleanly integrates with other development tools.

There are several RPM Service Plans available for GoGrid customers to choose from including:

• RPM Lite
• RPM Bronze
• RPM Silver
• RPM Gold
• RPM Enterprise

The graphic below clearly depicts the differences between each tier:

Do note that pricing varies based on the billing plan that you choose: Annual, Monthly or On Demand, as well as the number of hosts you choose to monitor. The pricing does NOT include the cost of using the GoGrid Cloud infrastructure. According to New Relic’s FAQs, installing of the RPM agent takes only a few minutes.

The RPM dashboard shows a wide range of data points including a snapshot of the health and availability of a customer’s managed applications including response time, errors and throughput. For a full overview of the RPM feature set, I recommend reading through their Feature Page.

The following Press Release was delivered today regarding the availability of the New Relic RPM application on GoGrid:

New Relic Teams with GoGrid to Deliver Superior-Performing Web Apps in the Cloud, on Dedicated Servers, or in Hybrid Environments

Customers taking advantage of GoGrid’s robust cloud infrastructure can use RPM to monitor, troubleshoot and tune Java and Ruby web applications.

San Francisco, CA (PRWEB) January 12, 2010 — New Relic, Inc., the leading software-as-a-service provider of application performance management solutions, and GoGrid, the Cloud Infrastructure Hosting service from ServePath Dedicated Hosting, today announced that New Relic RPM supports monitoring, troubleshooting and tuning of Java and Ruby web application deployed on GoGrid’s leading platform. Additionally, the companies announced that customers who select New Relic RPM to manage their GoGrid-hosted applications are eligible for preferential pricing.

With more than ten years of experience in enterprise-level data center hosting, GoGrid applies a unique understanding of uptime, security, and service level agreements to its public cloud offering. GoGrid goes beyond existing public cloud offerings by providing Hybrid hosting solutions that privately connect cloud front-ends with dedicated back-end infrastructures, as well as the ability to create and store customer images (MyGSIs). New Relic RPM is a leading on-demand application performance management that operates seamlessly in both cloud and dedicated server environments, making it uniquely suited to monitor, troubleshoot and tune web applications deployed on GoGrid’s cloud or hybrid infrastructures.

“Organizations taking advantage of GoGrid’s multi-tier cloud-computing platform have high expectations for performance and reliability,” said John Keagy, Co-Founder and CEO of GoGrid. “Working with New Relic to add application performance management as a complement to our robust infrastructure provides our customers with the very best combined solution for deploying and managing applications that successfully meet business needs.”

“As more and more companies deploy their applications with GoGrid, it’s especially important that they have a single performance management solution that they can use on-premise, in the cloud, and in hybrid environments,” said Bill Lapcevic, New Relic’s vice president of business development. “New Relic RPM is the only enterprise-class application management tool delivered as a service, and that automatically offers the same monitoring and troubleshooting capabilities for web applications deployed on both virtual and dedicated servers. Its a perfect fit for GoGrid’s customers.”

As part of the partnership between GoGrid and New Relic, GoGrid customers are eligible for a preferred partner discount on RPM pricing and a complementary trial of RPM Gold premium service. To take advantage of preferred pricing, GoGrid customers can visit New Relic’s GoGrid partner page, select a subscription level, then sign up for RPM. Discounts will be applied automatically.

About GoGrid
GoGrid is a leading Cloud Infrastructure Hosting provider that delivers true “Control in the Cloud™”. GoGrid enables sysadmins, developers, IT professionals and SaaS vendors to create, deploy, and control free f5 load balanced cloud servers and complex hosted virtual server networks with full root access and administrative server control which includes personal server images (known as MyGSIs). GoGrid server instances maintain the industry standard specifications with no requirement to learn and adapt to proprietary standards. Bringing up servers and server networks takes minutes via a unique, award winning web control panel or GoGrid’s API. GoGrid delivers portal controlled servers for Windows Server 2008, Windows Server 2003, SQL Server, and ASP.NET, as well as multiple Linux server operating systems like RHEL and CentOS. GoGrid gives users the control of a familiar datacenter environment with the flexibility and immediate scalability of the cloud, a “cloudcenter.” To learn more, visit www.gogrid.com.

About New Relic RPM™
New Relic RPM is an on-demand performance management solution for web applications developed in Ruby, Java or JRuby. New Relic RPM is fully implemented in minutes and provides deep, 24×7 visibility and code-level diagnostics for web applications deployed on traditional, dedicated infrastructures, private and public clouds, or any combination thereof. RPM’s real-time metrics enable application owners, developers and operations teams to quickly and cost effectively monitor, troubleshoot, and tune application performance. To learn more about RPM and to subscribe, visit www.newrelic.com/get-RPM.html.

About New Relic®
New Relic, Inc. is the leading software-as-a-service provider of application performance management solutions that enable developers and operations teams to quickly and cost effectively monitor, troubleshoot, and tune application performance in real time. More than 3,200 organizations use New Relic RPM to monitor and optimize more than 35,000 production application instances, including customers 37signals, CSC, Getty Images, GitHub, Hot Topic Stores, Juniper Networks, Intuit, Linked In, Liz Claiborne, OurStage, Shopify, and Simon and Schuster; and partners Amazon AWS, Blue Box Group, Brightbox, Engine Yard, GoGrid, Heroku, Red Hat, RightScale, Stax Networks and VMware. New Relic is a private company headquartered in San Francisco, California, USA. To learn more about New Relic, visit www.newrelic.com/get-RPM.html“>www.newrelic.com.

New Relic is also extending some Preferred Pricing for GoGrid customers. If you have questions about the signup or installation process, I recommend contacting New Relic directly. To sign up, simply choose the RPM level you want on the GoGrid/New Relic page and then fill out the form.

The recent McKinsey report “Clearing the air on cloud computing” has caused quite a bit of stir within the cloud community, and I can see why. While it definitely brings a good deal of analysis to the table, I feel it is somewhat generalized, makes assumptions and does overlook some key points.

First and foremost, this article is NOT going to be an analytical discussion of the cost of running or setting up a datacenter vs. an Amazon EC2 Windows instance. I’m not a financial analyst. Honestly, calculating the Total Cost of Assets (TCA) or Total Cost of Operations (TCO) causes my eyes to roll back into my head leaving me gasping for air. Don’t get me wrong, it seems like some good effort was made analyzing data and formulating conclusions. The problem is, I feel that they were on a jetliner, shooting through the clouds with the shades 1/2 down.

Before I start with my own analysis and commentary, I would like to reference a few responses I have read that somewhat chastise McKinsey.

Three “Rebuttal” Articles to Read

The first comes from CIO IT Drilldown’s Virtualization site. In his article “McKinsey Cloud Computing Report Conclusions Don’t Add Up,” Bernard Golden does the major lifting for me in terms of analysis. I have highlighted some key points from the article that I viewed to be particularly important (my highlighted version of the article is here). I particularly enjoyed Golden’s rebuttal to the analysis of cost calculations, namely use of EC2 Windows instances, headcounts that don’t add up and other “less visible” capital expenses for facilities and other assets. Also as Golden points out, McKinsey proposes that better efficiencies and savings can be realized through virtualization within the organization. To me, the McKinsey recommendation seems a bit counter-intuitive: “Don’t go with a vendor whose expertise IS virtualization, hardware, infrastructure, et al. Instead, DO try to do it yourself, with tremendous CapEx & OpEx expense.” Hmmm, makes sense to me, NOT! Lastly, I particularly liked Golden’s 3 recommendations (quoted from article):

1. Review your portfolio of applications to understand what cloud computing means to you.
2. Create a viable financial model for assessing the true costs of internal hosting.
3. Evaluate the potential for an internal cloud even if the numbers don’t work with an external cloud provider.

Another good article comes from the “Official Google Enterprise Blog”, posted by Rajen Sheth, Sr. Prod. Mgr for Google Apps. Titled “What we talk about when we talk about cloud computing“, this article gives great insight into Google’s vision of the Cloud. Again, I provide a highlighted version of the article which has items that particularly got my interest, specifically:

• Google’s approach at virtualization using “stripped down” servers and tying the drones to a brain
• Reliable software enables the creation of a more robust platform
• “The reality is that most businesses don’t gain a competitive advantage from maintaining their own data centers.” (I couldn’t have said it better myself!)
• Running a self-installed virtualization model still requires licensing, maintenance and implementation costs: human, hardware and on paper
• Cloud offers faster innovation than DIY models

Sheth concludes with a poignant question: “As companies weigh private data centers vs. scalable clouds, they should ask a simple question: can I find the same economics, ease of maintenance, and pace of innovation that is inherent in the cloud?”

Lastly, Lew Moorman posted a rebuttal of sorts on the Mosso Blog titled “McKinsey Misses The Bigger Point On Cloud Computing“. As with the previous articles, I have a highlighted version available. Moorman flat out states that McKinsey missed the bigger point and “underestimated the benefits of cloud computing.” Moorman presents 3 different characteristics of the cloud than McKinsey does, and frankly, my own definition is more slanted to his than to McKinsey’s. Both have warrant however. Moorman correctly points out how McKinsey blurs IaaS and PaaS into one. This is something that I will discuss here shortly. I definitely recommend reading the non-”back-of-the-envelope” analysis. I do know who pays $14,000 for a Windows server over 3 years, the Military. All joking aside, there are the OpEx costs of keeping said server up and running, something McKinsey does touch upon, but not thoroughly enough. I will (as I said) leave the TCO/TCA analysis to the experts, though. Lastly, Moorman appropriate says that time (and money) is better spent in leaving the infrastructure to experts, letting companies focus on their core competencies.

While I cannot divulge specifics, it is important to note here that at GoGrid, our own utilization rate far exceeds the “best possible” ones listed by McKinsey.

My Shots from the Peanut Gallery

McKinsey is a well thought-of firm and I have full respect for their research, analysis and findings, but it’s always important to get in other perspectives when confronted with potentially deceiving findings. So let’s dive right in.

“Irrational Exuberance” and Unrealistic Expectations

Granted, McKinsey tips their hat to the cloud having “great potential” but goes on to attempt to stifle what many consider to be one of the most important technology shifts in recent years. True, clouds came out of nowhere, creating what many believe to be a marketing storm. Everyone jumped on the bandwagon, trying to define (and be the source of the ultimate definition) of Cloud Computing. We dashed under the rain of buzzwords last year, trying to make sense of the madness. Page 10 of their study shows a list of 22 cloud computing definitions (mine is listed there). As with anything new, people need to be able to put their heads around it, smell it, taste it, touch it. When you talk about something virtual, this is increasingly difficult to do. Thus, the buzzword and definition madness ensued. (We, at GoGrid, even created a home-grown video to help people understand it and make it tangible. It has over 43,000 views as of this writing.)

My issue with the statement of over exuberance and unreal expectations is, what other way could it have happened? Anything that is hot now moves much more quickly than we had been used to. Take Twitter as a clear cut example. It’s mainstream. There are strategies and business being built around it. The Social Networking movement could be equated to that of the Cloud if you think about it. In my mind, this is no different. Both are exciting and new, full of promise, but wrought with growing pains, naysayers and disbelievers. So, would McKinsey say the same thing about Social Media?

And where on the Gartner “Hype Cycle” are Twitter or Cloud Computing? I dare say that with Twitter, we are on the Slope of Enlightenment. I believe the Trough of Disillusionment was passed a while ago and mainstream adoption is taking place. But the curves are somewhat distorted due to the speed of which Social Media has spread. For the Cloud, I’m not sure. I almost feel the Trough has been leapt to some extent due to the rapidity of the movement as well, and we are on the way to “seeing the light.” But I’m a forward thinker. (These two topics are great subjects for later discussion.)

Their Definition of a Cloud is Blurred

What I find fascinating is that despite the “hundreds” of definitions of Cloud Computing in the blogosphere, McKinsey still couldn’t nail it down, and, in the process took a shortcut in their definition. For starters, there is no mention of “self-service” within McKinsey’s definitions. This is fundamental to the cloud and a key differentiator between traditional infrastructure deployments or virtualization, for that matter. As Randy Bias pointed out to me, “more important than embracing virtualization in the enterprise is building ‘private clouds’ that have self-service models.” This is an important topic to consider. If an enterprise works a virtualization strategy, will it be done in a way where it is entirely self-service in nature? Private clouds (using virtualization) will take time to get to where public clouds already are.

I actually somewhat agree with their three cloud characteristics of: 1) “hardware management is highly abstracted from the buyer,” 2) “buyers incur infrastructure costs as variable OPEX”, and 3) “infrastructure capacity is highly elastic (up or down)”. One should be careful, however with point #3, especially with mixing capacity and elasticity with scalability. I believe it would have been important for McKinsey to discuss elastic capacity component a bit further than “capacity can be scaled up or down dynamically, and immediately, which differentiates from traditional hosting service providers.” This is a somewhat limiting statement, and hosting vendors like ServePath/GoGrid are already proving it wrong (see “Cloud Connect“).

Generally, there are two types of scalabilities: vertical and horizontal. Briefly, vertical scaling represents adding more to the “boxes” you have (e.g., RAM or Storage): build “up” by putting more horsepower into what you already manage. Horizontal scaling means that you add more infrastructure (e.g., servers) side by side, essentially building “out.” This is much the way that Google sets up their shop, by adding more boxes horizontally to increase compute capacity. For a good primer on scalability, I encourage you to read Randy Bias’ Whitepaper “Scaling Your Internet Business.”

Categorization of Clouds is Blurred as well

With a broad stroke of the sword (or pen), McKinsey chopped the Cloud in half: “Clouds” and “Cloud Services”. This is the satellite view of things, not even a 10,000 foot view. By focusing the lens a bit more (as well as reading what others had written), one would know that there are 3 distinct “layers” to Cloud Computing, even more if you fine-tune the focus. I’ve articulated this before (and it is even in their presentation under the multiple definitions) in the form of the “Cloud Pyramid.”

You simply cannot lump IaaS and PaaS together. They are different beasts. Sure they share some commonalities in that they fit the broad definition of the cloud. (At GoGrid, we currently define Cloud Computing as: “on-demand self-service Internet infrastructure where you pay-as-you-go and use-only what you need, managed by your browser or application.“).

But the differences between IaaS and PaaS are important and cannot be simply brushed aside. As I wrote previously (“Navigating the Layers of the Cloud Computing Pyramid“) and I simplify here, Platform Clouds (like Google App Engine and Microsoft Azure) have the OS and Frameworks managed by the provider whereas Infrastructure Clouds (like GoGrid and Amazon Web Services) boil things down further to the hardware and networking protocols, for example. Even within IaaS there are clear distinctions (Cloudcenter vs Infrastructure Web Services – read about how we differentiate these terms here and here). So why does McKinsey overlook this? I’m not entirely sure. I won’t attempt to draw any conclusions either.

The fundamental point here is, you cannot simply split the cloud in half (Clouds vs. Cloud Services), at a minimum it must be in thirds (Application, Platform & Infrastructure). Finally, I don’t quite understand why Cloud Services (loosely defined by McKinsey as “SaaS”) shouldn’t have the same characteristics of Cloud Computing in general. True, they don’t incur “infrastructure costs”, but they are subject to recurring costs through licensing, monthly usage or seats. And McKinsey is correct that SaaS can be built on top of other layers of the Cloud (Pyramid). In fact, the same could be said for Platforms being built on top of Infrastructure Clouds. It may not be the most cost-effective method to build a Cloud Platform, but it is definitely viable.

Service Level Agreements are NOT a Hindrance nor a Crutch

As Gartner’s Lydia Leong points out, there is a difference between engineering for reliability and actually attaining it. According to Leong, “most enterprise data centers have mathematical uptimes below 99.99% (i.e., calculated mean time between failure)”. To take this a bit further, SLA’s definitely should be viewed as a requirement for any company doing due diligence when choosing a hosting provider, cloud or not.

The cloud is obviously under an enhanced level of scrutiny due to its newness and promises. When any Cloud hiccups, whether it’s SalesForce, Google App Engine or GoGrid, people hear about it and instantly say “See? The Cloud can’t maintain 5 – nines of uptime!” and suddenly the cloud is evil. But failures happen at all levels of infrastructure and technology and it is not unique to the cloud. Having a provider that offers a solid SLA is critical (e.g., GoGrid offers one of the most robust SLAs in the hosting industry). But, if one were to follow McKinsey’s recommendation and “virtualize everything internally,” how will SLA’s be honored there? There are no clear standards in the hosting industry that dictate how uptime is calculated. It is frequently left up to the vendor to interpret, and subsequently back up through an SLA. This is increasingly obscure when it comes to private datacenters. And what are the consequences of not attaining 5-9′s in a private datacenter? No more “Casual Fridays”?

The cost to attain an incredible uptime record is high. It is inherently tied to a vendor’s reputation and can dramatically affect sales and customer stickiness. But any smart IT person knows that failures happen and an even smarter IT person strategically plans for it through a better architecting of their solution. SLA’s help (if using a hosting vendor), but they will NOT solve architectural mistakes; doing it all in-house under a vaguely defined SLA or uptime standard can be cost and time prohibitive.

Disputed Cost Savings

I personally would love to have $20 million sitting around to set up my own datacenter. I’m sure that there are many SME’s who would love to have that liquidity and cash availability as well. In this day and age, being able to plop down even a fraction of that amount to create or re-architect a datacenter is practically a pipe-dream. Again, if you virtualize your offering, you may only realize partial success. Also, as Leong points out (see yellow highlights), there is much more value to be gained through using the cloud than attempting to DIY (do it yourself), AND, it depends on the size of your organization. Larger corporations have efficiencies of scale (hopefully) as compared to a SMB. Obviously, when re-engineering an IT strategy, one has to pay careful attention to what is gained and lost through keeping the status quo, re-architecting through internal virtualization or moving to the cloud.

There are some definite uses of public clouds for businesses to capitalize on now, namely:

• Small Business – when hiring a full fledged Ops team or hand-building your infrastructure is cost prohibitive (convert CapEx to OpEx)
• Medium Business – when you need to dynamically control costs as well as compute capacity. Elastic clouds can do this for you.
• Large/Huge Business – outsourcing is important to non-critical infrastructure like QA/Dev/Skunk works or as a failover strategy

My stance on this is, the most effective strategy is one that is hybrid in nature. Corporations should look to see what must be moved to the cloud, what must stay in-house and what falls into the grey area. Even within the cloud, there are scenarios that simply are better handled through integrating dedicated or colocated infrastructure (and the benefits therein) with a cloud front-end (see GoGrid’s Cloud Connect). Planning for “up” and “out” scalability using the elasticity of the cloud, coupled with the performance of dedicated hardware is a must when considering strategies.

And what about “innovation” as Golden pointed out? Cloud providers can clearly innovate much more rapidly than an in-house IT team can, especially given the virtualization, budget, time and monetary constraints when doing internally.

Lastly, John Keagy, CEO/Co-Founder of GoGrid, poses this question: “What is the opportunity cost of spending $20MM on a non-core activity like a datacenter?” Realizing this capital investment into a profitable business unit is potentially attainable by few, impossible by most.

The F.U.D. Factor

Honestly, I thought we were past this phase but I guess not. As with anything new, there are those who are quick to point out that the cloud is not the panacea of all things. I agree with that somewhat. However, when McKinsey draws a comparison to the 2000 dot-com bubble, I get a bit aggravated.

McKinsey truly brings out the Fear, Uncertainty and Doubt factor into play with this analogy. The three bullet points (paraphrased to: huge investments made based on hype, inability to generate profits, and NASDAQ losing 80% of value) simply do not come into play here. During the dot-com bubble, money was thrown around loosely and given to anyone who had even a half-baked business plan. Money was not wisely spent and business had little to show during and thereafter. In this day and age, before any funding is given, companies not only must have a fully vetted business, they also have to have an installed user base and definitely signs of profitability. Lets not forget about the “transparency” buzzword du jour. And this time around, the stock market drop has little or nothing to do with the technology sector.

To equate the cloud movement to the dot-com bubble is naive at best. Try to tell Amazon that what they have been doing for a couple of years now is just a fad and will not last. Need I say more?

</end commentary>

Perhaps I had too much coffee while I wrote this. Or maybe woke up on the wrong side of the bed. One part of me is truly happy that McKinsey came out drawing some clear lines in the sand. Their “non-partisan” analysis is definitely required to help put things in perspective for companies evaluating their IT strategies. The other part of me, however, wishes that they hadn’t been so pessimistic and potentially misleading.

If you haven’t read their study, I encourage you to do so. Read and analyze it and give me your interpretation.

By now, many in the Cloud Computing space have heard about (or even read) the University of California Electrical Engineering & Computer Science’s (EECS) study on Cloud Computing titled: “Above the Clouds: A Berkeley View of Cloud Computing.” Published on February 10th, 2009, the EECS’s paper provides a seemingly academic study of the Cloud Computing movement, attempts to explain what Cloud Computing is all about, and identifies potential opportunities as well as challenges present within the market.

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 [↩]

After about a year of Cloud Computing under my belt, analyzing trends in the market, talking with various professionals as well as customers in the space and watching our own Cloud Computing product, GoGrid, take off as a Cloud Computing leader and innovator, I feel that it is time to make some 2009 predictions for Cloud Computing. Who would have guessed that 2008 would have been “The Year of the Cloud“? I think that 2009 will be “The Year of the CLOUDS” (emphasis on multiple).

A Quick Look Back

If you look back to January 2008, the players in Cloud Computing were few are far between. Obviously, Amazon was breaking ground in establishing themselves as the front-runner at that time. But the term was too new and largely undefined. One of my first blog posts discussed some trends of grid computing, virtualization & virtualized hosting, cloud computing and “green hosting.” For the most part, many of those concepts have not changed. Rather, they have evolved, grown and become more established as leading technologies for the future. As of the writing of that article, GoGrid was still in Private Beta, but with well over 2 years of development getting it ready for prime time.

Virtualization was definitely the buzzword of the beginning of 2008, mainly because it was something that people could fairly easily understand. There were several desktop virtualization products available for users to host different OS’s within their own OS. As Jeff Kaplan predicted, On-Demand services started to really take off for several reasons that are applicable even today (if not more so). His number 1 reason: “Services are Recession Proof” (more about that later in my predictions). While Jeff’s ideas were largely focused on SaaS, there is a lot to be said when you apply them to Cloud Computing in general.

Close to when GoGrid was launched at the end of March 2008, coincidentally(?) the search term “Cloud Computing” (according to Google Insight) really started a strong upward trend within World Wide Searches:

As the US (and World Wide) Economy fell off the cliff, so it seems, did the interest in the Cloud (but that could be due to other worldly distractions). What is actually a bit interesting is that just after the Economy went south, there was a big spike in interest in the Cloud…were people thinking it was recession-proof? Perhaps. (“Cloud Computing” is the blue line below and “US Economy” is appropriately red).

Analysis of the previous year is probably better handled through a separate post. On to some of my 2009 predictions.

Ten Cloud Computing Predictions for 2009

Below is a list of some trends or ideas that I think will surface or grow in 2009. Note, these are not ranked.

1. Clouds Reduce the Effect of the Recession
   The US Government just announced that the US has been in a recession since December 2007. To most people, this is simply stating the obvious. Many in the Cloud Computing field have been touting how moving to the Cloud can lower high Capital Expenditures (CapEx) and shift this to Operating Expenditures (OpEx). Coupling that with a pay-for-what-you-use, use-only-what-you-need model, and Cloud Computing becomes a panacea for extending the runway of your business. Prudent companies are slashing budgets and looking to weather the turbulent market for as long as possible. Those companies that are heavily dependent on advertising will be seeing the effects of cash hording in Q1 and Q2 of 2009. Utility-based spending is a shift in mind-set that could potentially slow the freefall and domino effect we are currently experiencing.
   Recently, I heard about a similar type of idea that could potentially help the sales of hybrid or electric cars. One of the primary barriers that is preventing users from purchasing “green” cars is the high cost associated with a purchase. If the auto industry were to adopt a cell phone business model where you pre-buy your electrical charges and the cost of the car is “subsidized” through the use of recurring and predicable revenue, users might more readily opt for a purchase (at a discounted price). However, several infrastructure changes would be required in order for such a pricing-shift to take place, meaning that charging stations would have to be abundant (and possibly government subsidized as well). In the long term, building the green infrastructure would reduce the US dependence on foreign oil, establish new businesses and competition for charging station infrastructure and move towards bettering the environment. While not exactly the same, similarities can be drawn between this idea and the shift from self-hosted servers to Cloud Infrastructures. CapEx is reduced (e.g., green cars become less expensive to buy/no need to purchase servers that are under-utilized) and costs are moved to OpEx (e.g., charging your car when you need to/paying for only the infrastructure you use).
2. Broader Depth of Clouds
   Cloud Computing providers are leapfrogging each other with new features and offerings. This will continue in 2009. GoGrid was the first to provide a wide assortment of Windows Server Clouds (Windows Server 2003 at launch and later Windows Server 2008). Towards the end of the year, Amazon’s EC2 announced the availability of Windows Server 2003. Microsoft jumped into the ring as a Cloud Platform with Azure. By far, AWS is leading the field by offering a wide array of Cloud services (EC2 – Cloud Infrastructure/ S3, SimpleDB, CloudFront, & SQS – Cloud Extenders). Their footprint continues to deepen as well. But sometimes it’s not bad being #2. GoGrid is a Cloud Infrastructure provider with Cloud Extenders (with GoGrid Cloud Storage) with an emphasis on mirroring standard IT infrastructure services with a focus on ease-of-use through a GUI and programmatic control through an API. Microsoft will be launching their own Cloud Infrastructure in 2009 as well as a variety of Cloud Applications (e.g., Exchange). Google will extend its Cloud Platform with services for storing and serving large files, larger dataset management, pay-for-use enhanced usage and new runtime languages (beyond Python). RackSpace made its move at the end of 2008 with SliceHost and Jungle Disk acquisitions; look to them putting all of the pieces together in 2009. I am seeing the trend towards a broader range of services by several large players. This may confuse the market in the first half of 2009 as IT organizations struggle to figure out the best Cloud solution and how to put it all together as a financially and technologically viable strategy.
3. VC’s, Money & Long Term Viability
   With the credit market increasingly tight, if not non-existent, VC’s, Angel funders and other investors will be faced with some tough decisions. The Dot-Com era allowed for almost anybody to get money for business plans that were essentially vapor-ware. Web 2.0 was slightly better, you had to have a viable business strategy, an established user base, and well on the path to monetization to receive funding. Even with that, there was no guarantee of survival. Many Web 2.0-ers are now shutting shop, despite the fact that they are loved by many. Web 3.0 will present a much steeper hill to climb from a funding perspective. I have spoken to a few investors and VC’s recently (as the Economy imploded) and they still seemed to be somewhat optimistic, but very cautious. But it is their job to keep a positive outlook as they look for the next best thing. With Cloud Computing services gaining even more momentum, this is a good market for funding. But the VC’s and others are really doing their due diligence this time through (are they finally learning from their mistakes over the past 10 years?). Cloud Infrastructure providers will not be the ones receiving the scarce capital, I don’t think. And SaaS providers are a dime a dozen (not in a derogatory way). The SaaS market will continue to grow (not as quickly as previously, I don’t think), in fact, the first Quarter of 2009, we may see a dip as some SaaS organizations actually go under, unfortunately. I think that Cloud Aggregators (those who work to provide integrated Clouds and management services around them) will be ripe for additional funding. For Cloud Platform providers the outlook is a bit trickier as frequently they are dependent on public run-time languages or maintaining proprietary code to keep momentum. I think the smaller providers may see an influx of capital in order to remain competitive, if not survive.
4. Partnerships Galore & Weeding Out of Providers
   Strategic alliances and partnerships are critical to any business success. Not only do you increase exposure to other audiences but also provide more innovative and robust services in the process. GoGrid recently announced partnerships with RightScale, Appistry and GigaSpaces to name a few, with several others coming in 2009 (GoGrid Partners). We will see several new alliances within the Cloud Computing space but this is where my crystal ball is a bit hazy. Cloud Aggregators will be the big movers here and they really have to be. Aggregators need to ensure their own fiscal viability by broadening and diversifying their offerings. If a provider is too attached to EC2, for example, and if Amazon decides to develop functionality that mirrors that of the Aggregator and offer it for free or at a fraction of the cost, the Aggregator will struggle to remain competitive. Aggregators will be core to driving standards and interoperability (#7 below) as they will have much deeper insight into the workings of each of their partners. If they can’t remain ahead of the curve, a big fail whale is on the horizon. Tied to #3 above ($$$), those providers who can’t remain solvent or make smart decision or even monetize in a clean, clear way will go under. Obviously I don’t wish this on any provider, but it is inevitable. I won’t make any predictions but several Cloud providers are for sale or seeking funding to keep their lifeline healthy.
5. Hybrid Solutions
   Not every corporation or business is looking to the Cloud as the next sliced bread. While the Cloud can be the catalyst for a potentially more sound IT and financial strategy, it will not solve every IT challenge. There are some IT infrastructures that must remain in a private datacenter or running on dedicated, bare-metal servers. Database intensive environments may not be conducive to exclusively residing within the Cloud. This year, GoGrid launched the 1.0 version of  Cloud Connect as a way to allow for these types of hybrid (dedicated servers connected to Cloud servers) solutions. Others are calling Hybrid Infrastructure “Cloudbursting.” I expect that some of the strategic partnerships coming in 2009 will include other hybrid solutions of this nature. In fact, they may give way to full mirrored failover or redundancy solutions where traditional infrastructures are mirrored within the Cloud, sharing common datastreams to ensure near-real-time availability of data and services.
6. Web 3.0
   Web 3.0 is upon us. I have long thought that it will be all about Integration and Standards (#7 below). I have written about “mashups” and integrations as being a large component of Web 2.0. Web 3.0 will make these integrations much more seamless and go well beyond that of simple visible shared data applications. What we saw with mashups was essentially proof-of-viability and with some experimentation thrown in. Like a strategic partnership, successful integrations are critical to the furthering the power of the Cloud. In 2009, we will see integrations taking place at a much lower level of IT. Data integrations will remain as they are fairly established. Infrastructure integration and companies offering this as a solution, either as consultation or aggregation of technologies, will drive the innovation of Web 3.0. These integrations will help create new and unique SaaS and even PaaS offerings to the market. The hurdle here will be in the explanation and usability of said solutions.
7. Standards and Interoperability
   While Cloud Computing seemed like the New World in 2007 and the Wild West in 2008, it has now been colonized and settlements established. 2009 will be that of Civil Engineering. The development of standards and interoperability between the varying levels of Clouds is inevitable. It is also tied directly to the needed adoption by the Enterprise. Without clearly defined standards, best practices and even open interoperability, further adoption of the Cloud will slowed dramatically. Just as Phone Number Portability was an important factor in reforming the telcos during the 1990′s and early 2000′s, I believe that Cloud portability (enabled only through guaranteed standards and interoperability) will be a movement in mid to late 2009. Everyone has “agreed to agree,” and now are making inroads towards standards, a reality. It will be important that the big players in the space (e.g., Amazon, Microsoft, Google) become involved. IBM has tossed their hat into the Cloud ring by announcing a Cloud Computing Certification called “Resilient Cloud Validation” (but only if they collaborate with IBM). Without these big players’ participation, there will be 2 types of clouds (standard and non-standard) and/or companies that provide filters or converters to allow for Cloud Portability.
8. Staggered Growth within the Cloud
   I will go out on a limb here as say that there will be tremendous growth within the Cloud. But that is an easy prediction to make. The Cloud encompasses so much that it would be difficult to really see a stagnation or shrinkage. SaaS will expand (perhaps not as rapidly as previously) and offerings by other layers within the Cloud Pyramid will deepen and broaden. Because of the complexity of building up Cloud Infrastructures (from a provider perspective), the Infrastructure layer will take a less steep growth curve as compared to Platform Clouds and Application Clouds will beat the previous two layers out as well. Cloud Aggregators will come and go, and Cloud Extenders will evolve and become more intertwined with other Cloud layers. 2009 will also see the increased visibility of Private Clouds, especially within the Enterprise, until standards and security concerns are met within Public clouds.
9. Technology Advances at the Cloud Molecular Level
   There is probably a new layer to the Cloud Pyramid that needs to be added, one that resides at the “molecular” level. Chip makers such as Intel, are making plans on enabling Cloud-optimized CPU and other types of chips to allow for a more unique control of built-in switches. They are extremely interested in many of the open and proprietary virtualization technologies out there (Xen, VMware, Virtual Iron, etc.) and are strategizing on how to make their chipsets more compatible and efficient for use in the Cloud. Obviously, their vision is to have all Cloud infrastructures running with “Intel Inside” stamped on them. Many Cloud Computing providers, including GoGrid, already hook into chip-level switches and controls to make better use of the processors. Dell, HP and IBM will most certainly release servers specifically designed and configured for running optimized Clouds. Since all Clouds are powered by physical hardware and as advances are made further propelling Moore’s Law into the stratosphere, Clouds will become more powerful and able to take the place of traditional servers even more readily.
10. Larger Adoption
    If one factors in many if not all of the items mentioned previously, the obvious conclusion is that Cloud adoption will be significant in 2009. The Enterprise will move beyond simply testing the waters and just using the Cloud for project work. Private Clouds will help with their acceptance and the undeniable call for cost-savings through reduced CapEx will be too loud to be ignored. My gut also tells me that Government will play a much larger role as well. In 2008 I spoke with a person from the French government whose mission it was to bring the Cloud to their government infrastructure. This is only the tip of the iceberg. With the 2008 US Election, Barack Obama proved how critical an online presence is to furthering the concept of “change.” The Obama-Biden Technology Agenda points to the obvious importance of Technology, especially with the appointment of a Chief Technology Officer for the US Government.  And, as always, Web 3.0 and Startups will remain on the bleeding edge of hosting technology yet conserving cash for a sunnier day (ok, it can be a bit “cloudy”).

It’s always fun trying to gaze into a crystal ball and predict the future. When peering into it for perspective and predictions on Cloud Computing, a “cloudy” crystal ball is a bit of an oxymoron. Cloud Computing is no longer a just a “newfangled” movement but rather an established IT and business strategy that will be critical to all companies regardless of business models. What are your predictions? Leave a comment!

GoGrid user Mitch Denny created an outstanding use of the GoGrid API using Windows PowerShell. For the uninitiated, Windows PowerShell is a command line shell and scripting language designed to help IT professionals achieve greater control and productivity through the use of of an admin-focused scripting language, complete with 130 standard command line tools, consistent syntax and utilities (paraphrased from the PowerShell product page). PowerShell runs on Windows XP, Vista, Server 2003 and Server 2008 and is a great way for sysadmins to control existing IT infrastructure through scripting.

The GoGrid API has been available for some time now and I have been waiting for a stellar use of it to showcase. (I’m still waiting for a very resourceful developer to use it either to create an iPhone web application or stand-alone application…hint, hint.) Mitch, who is an avid .NET developer from Australia and Senior Consultant at Readify, created a PowerShell Snap-in for GoGrid which uses the GoGrid API. His project, documented here, is open-source, hosted at CodePlex, and seems like will continue to evolve. Currently a Beta2 release, the “PowerShell Snap-in for GoGrid” was designed to “demonstrate how useful it can be for infrastructure-level SaaS providers to expose an API for their customers to use.” Mitch has some good visions on how and why API’s should be available, including:

• Configure applications for performance testing.
• Run load agents for performance testing.
• Test disaster recovery scenarios.
• Provision hardware for project work (i.e. development teams).
• Support instructor led training with virtualised labs.
• Host demonstration environments for presentations.
• Controlling scale of your underling SaaS infrastructure.

Mitch’s code seems to work quite well. Following his instructions, I actually used it to provision a new load balancer within my GoGrid instance. It simply worked and took just a few minutes to set up. It’s actually fun executing the commands within PowerShell and watching devices magically appear within the GoGrid GUI.

What you need to get started:

1. A GoGrid account – sign up now!. You will need access to the GoGrid portal in order to create an API Key.
2. Windows PowerShell – download it from the Microsoft website here. Be sure to select the proper version for your OS. Have it fully installed before you start.
3. The PowerShell Snap-In for GoGrid – this is the CodePlex project page, current version is “GoGrid 1.0 (BETA2)”. As of this writing, some of the Wiki pages describing some of the actions have not been fully built out but I expect that to change over time. The Snap-In is available for download in the upper right of the project page.

I definitely recommend watching Mitch’s screencast before or while you are doing this yourself. The screencast clearly outlines what you need to do and has good on-screen documentation of the commands you should issue. It demonstrates creating a load balancer and two servers which is an excellent starting point. The screencast can also be viewed below:

Have you used GoGrid or the GoGrid API in a different way? If so, be sure to contact me so that I can showcase your work! Great job Mitch!