Thinking Out Cloud

What's Really Exciting About Cloud Computing

Last week I attended an event in New York organized by Tibco as part of their launch tour for their new cloud offering, Tibco Silver. It was a really fun panel to do with Mike Culver from Amazon Web Services, Mike DiPetrillo from VMWare, Ed Simmons from Deutsche Bank and Sreedhar Kajeepeta from CSC.

As the panel was about to wrap-up, Farrell McManus, moderator of the panel and the publisher of Waters Magazine, asked the panelists something to the effect of what makes us excited about the future of the cloud. My response was that most of our conversations on cloud computing now focus on how the cloud will enable us to do the same things but cheaper, faster and easier, what's really interesting to me is how the cloud will enable us to do things we couldn't before. And as an example I gave Twilio.

Twilio is a remarkably simple concept, but very difficult to implement in an elegant way, as the Twilio folks have done. It is a cloud platform that enables developers with basic web programming skills to develop complex voice applications.

Under the hood -- but completely transparent to the developer or the end user -- Twilio is hosted on Amazon EC2, uses a multi-tenant architecture and has implemented a fully functional telephony infrastructure based on the open source framework Asterisk.

But again, the developer is shielded from the complexity of the telephony infrastructure, something that used to require specialized engineering skills that involved things like ports, trunking and SIP servers. Instead, all the developer needs to do is call the Twilio service from his or her web app via a simple API that consists of five verbs: Play, Say, Gather, Record and Dial.

The other interesting aspect of Twilio is the pricing model. It is a simple pay-by-the-minute model, and a cheap one at that: 3 cents per minute, inbound or outbound. No upfront or monthly fees, no contracts.

Lastly, Twilio is highly scalable on demand. If a customer is now running some huge marketing campaign -- and some of Twilio's customers have done just that -- the system can scale without warning as needed.

These last two aspects of Twilio -- pay-per-use pricing and on-demand scalability -- are a direct consequence of the fact that the service itself runs on Amazon's cloud platform with a multi-tenant architecture.

The end result of all this is that the barriers to creating highly creative and sophisticated voice applications (or adding a "voice interface" to existing web apps) are extremely low. And it means that we won't just be able to create the same apps we did at a lower cost, but that a whole range of new applications will be developed. You can already see some of that happening on Twilio's blog.

In order to get people's imagination working on the types of apps they can create with Twilio, they have organized several developer contests, and you can check out the creative results on the above linked blog.

Their current contest is one of my favorites. It's aimed at Ruby developers who run an app on Heroku and use Twilio. If you read my post Ruby Developers: The Cloud Generation, you'll realize like me that this is some serious cloud-on-cloud action that really changes the game.

Check out this video Morten Bagai from Heroku that shows how easy it is to get a Ruby app running on Heroku and using Twilio:

How to create a Twilio app on Heroku from Morten Bagai on Vimeo.

Ruby Developers: The Cloud Generation

In Evans Data Corp.'s  first 2009 North American Development Trends Report, Joe McKendrick reports that Ruby usage has increased 40% during the past year. Darryl Taft of eWeek writes about the report:

According to Evans Data's biannual North American Development Survey, 14 percent of North American developers use Ruby some part of the time, up from 10 percent in 2008.

Moreover, the survey showed that 20 percent of developers expect to use Ruby in the coming year.

This trend is somewhat corroborated by the Framework Web Trends report from Built With.

To cloud computing there is a special significance in the increased adoption of Ruby, because Ruby developers are the cloud generation.

Back in early May I attended Oreilly Media's RailsConf 2009, the largest annual event for the Ruby-on-Rails community. It was an enlightening experience for me as for the past 10 years or so I had been deeply involved in the enterprise Java world.

For those of you unfamiliar with the story of Ruby, it is a dynamic programming language that has been around for more than 15 years but became "hot" circa 2006, particularly among the Web 2.0 crowd. It really took off when David Heinemeier Hansson developed the Rails web application framework as part of his work on 37Signal's Basecamp software-as-a-Service in 2005. It became especially famous by the fact that companies such as Twitter were using it and Ruby enjoyed an adoption explosion in 2006-07.

So essentially RoR is a programming language that is only now coming of age. And what struck me at Railsconf was that as a community they are taking cloud computing as a given. This is how you deploy apps. Period.

Before I explain further, an analogy I use for this is the telephone infrastructure in under-developed countries. Many countries in Africa and regions of China, for example, jumped straight to cell phone infrastructure. They simply skipped landlines for the most part.

In a similar fashion, the Ruby community is essentially skipping traditionally on-premise installed software. The dominant model for RoR application deployment is cloud, with platforms such as Slicehost (now part of Rackspace Cloud), Engine Yard and Heroku. Cloud services such as New Relic, FiveRuns and Scout provide the de facto standard monitoring and management frameworks, and cloud-based GitHub is the standard code version and developer collaboration tool for the RoR generation.

Moreover, training courses and educational books, such as Oreilly's Learning Rails , use cloud platform Heroku as their standard learning environment. Meaning that a new generation of developers, for whom Ruby is their first or early programming language, are growing up with cloud platforms as a natural part of life, just as my kids are growing up with Google Docs, Wikipedia and smartphones as a natural part of life. Imagine that.

What's also interesting about Ruby-land is that unlike Java, a programming language that made its big entrance a little over a decade ago, there are no dominant software vendors for Ruby infrastructure/framework/middleware/platform space. Instead -- and this is perhaps another area in which Ruby skipped a generation -- all of the application software components are pure open source plays, including Ruby and Rails themselves (and also including a long list of components such as Sinatra, Rack, Mongrel and Thin). 

And the same goes for the various Virtual Machine implementations of Ruby, such as MRI (the original), JRuby (a JVM-based implementation) and IronRuby (an implementation for the Microsoft .Net Framework).

If you had gone to a Java conference in 1997, the vendors dominating the show would have been WebLogic and NetDynamics (and Sun, of course) -- the three leading app servers. At the 1999 JavaOne show, they would have been the vendors that acquired them - BEA and Sun.

In the 2009 RailsConf, the two dominant vendors were Heroku and Engine Yard. Unlike some perceive these companies, they are not merely Rails hosting services -- they are the application platforms for Ruby, and they are on the cloud.

Heroku has demonstrated a particularly deep understanding of this role. They have "curated" a complete tightly integrated platform out of the various components and deliver an extremely easy to use platform that takes care of all things infrastructure (scalability, reliability, configuration, database connections, etc.) and lets the developers focus on their unique logic -- not the plumbing. They are, in essence, the WebLogic of the cloud generation.

Full disclosure: I am advising Heroku on strategy and marketing.

Innovator's Dilemma and the Cloud

In his seminal book The Innovator's Dilemma Clayton Christensen lays out the dynamics that allow start-ups to succeed. In short (and without doing justice to the depth of Prof. Christensen's ideas), the idea is that technological innovations initially represent too small of a market for large, established companies, which need to continue demonstrating a significant growth in percentages relative to their current revenues.

This, of course, creates an opportunities for new entrants, who often start with zero or very little revenues and therefore the emerging market represents a significant opportunity to demonstrate growth. One of the interesting concepts in Christensen's book -- and his later works that further develop the concept: The Innovator's Solution and Seeing What's Next -- is that in many cases the large incumbent vendors are well aware of what the technological future holds, but are unable to act appropriately because the dynamics of the business.

Cloud computing is now in that classic stage -- and the symptoms are everywhere. There seems to be little doubt in most observers' minds that cloud computing is a revolution and represents the future of IT, but turning this realization into a profitable business -- for both start-ups and established vendors -- is a different proposition altogether.

Low Visibility

One of the problems is that there is so little visibility as to the actual rate of cloud adoption. The hype is undeniable, but how significant are the revenues, and more importantly, how fast are they growing? Amazon, whose cloud services are perhaps the most significant indicators of cloud adoption, is intentionally -- and quite effectively -- hiding the finances behind AWS. The same goes for Google App Engine, Microsoft Azure and other cloud operations within larger vendors. And there's little to be learned from leading start-ups such as RightScale, who are of course privately held and keep their cards close to the vest.

One interesting case is Rackspace, the only company in the space that I know of that actually discloses its revenues from cloud operations separately. For example, in its Q1 2009 financials, Rackspace reported revenues of $134 million from its traditional managed hosting business and about $11 million from its cloud business. This comes out to a 16.5% growth rate from Q1 2008 for the managed hosting business compared to 145% growth for the cloud business (and note that part of the cloud business growth was due to the acquisitions of Slicehost and JungleDisk).

We can see The Innovator's Dilemma in numbers. While cloud is clearly rapidly growing for Rackspace, the absolute numbers are still small, and the company faces a dilemma of what part of the business to invest in.

And we can see this dilemma with other large vendors. In a recent interview with TechTarget, Mike Repass, product manager for Google App Engine said:

...rather than one big enterprise poster child, we'd rather have a hundred small web poster children, the kid in Brazil or China that wants to build apps on the web. It's very hard to build the pipeline to extract money from the big guys.

And we all know that in the long run, the real money is the enterprise, not the hundred kids in Brazil and Chine and even Santa Clara County.

But then again, the future of IT is in the cloud. So what's a company to do?

Different Perspectives

Depending on the size and business of the organization we can see different approaches to the dilemma.

Established Vendors

The largest of vendors, such as Amazon, Google and Microsoft, have sufficient resources to invest strongly in cloud computing without compromising in any way their existing high revenue and profitability businesses targeting consumers and enterprises. Oracle is a different animal because of Ellison's declared disdain for cloud computing. But now many believe that Oracle's play in the cloud will be mostly through its recent acquisition of Sun Microsystems, which has been investing heavily in the cloud.

IBM and HP also both seem to be making noises in the cloud, the former more significantly than the latter. But much of their marketing and investment seems to be in a way that somehow tries to mitigate the Innovator's Dilemma, also known as internal and hybrid clouds.

But as we go down the food chain, we see that different vendors are responding differently. Yahoo has been mostly silent about its cloud strategy, despite some rumors and public job postings, which indicate that they are seriously considering it.

Today, I'm speaking at an event by Tibco about their new cloud offering, Tibco Silver. Tibco is introducing many of its existing middleware products as a hosted cloud service (btw, you can follow the event in real time on Twitter with the hashtag #NOWCloud).

But for many of the mid- to small-sized vendors strategies are all over the map and mostly amount to marketing. At most, they may have created AMIs, and some even back that up with pay-per-use pricing (such as RedHat/JBoss). Others such as SpringSource have remained fairly silent about cloud (although I hear insider rumors that there is something in the works).

For many of these vendors the solution seems to amount to trying to take advantage of the cloud buzz through symbolic marketing-oriented efforts, without having to make significant investments in a true cloud offering, and without disrupting existing business models.

Start-Ups

Theoretically, start-ups shouldn't have a dilemma. They should be going all out for the cloud with the hopes of either unseating existing vendors, or gaining enough traction quickly enough so that the large vendors will acquire them down the road. But in practice, things aren't that simple.

Some start-ups are pure-play cloud companies. In other words, the whole point about them is that they provide cloud offerings. For them it's of course a no-brainer. Examples of such companies include Twilio, Heroku and Rightscale.

But I am also talking to software start-ups that are having serious dilemmas about the cloud. Think of an application management software start-up that is ready to realease a next-generation product in the space, or think of Reductive Labs and OpsCode, the commercial efforts behind Puppet and Chef respectively. Clearly most of the business today is in traditional data centers -- but the future is in the cloud.

Transitions Are Hard

Now some have suggested that these companies should start selling to the traditional enterprise with the classic approach, and gradually make the transition to the cloud when the market is bigger. The problem is that such an approach is easier said then done. Several factors make it extremely difficult to make such a successful transition. Even if in some of these cases the actual products would require little investment to transition to a cloud-centric approach, these companies will have to battle market perceptions, company culture, customer concerns and re-forming the company's ecosystem of partners and channels. I will post a more detailed blog on this topic soon.

Bottom Line

At the end of the day, both large and small companies will have to make a gut feeling call. The considerations include what they believe the adoption lifecycle timeline of cloud is for their particular business and how much they have to lose (some companies' existing business is failing, so there's little risk in making s strategic transition -- but that's a very hard psychological pill to swallow). They also include company culture and ecosystem, and of course the level of ivestment required in the product. In some cases, the solution may be aquiring, merging or being acquired.

I'll discuss some of the topics raised in this blog in more detail in future posts.

Podcast: Cloud Computing and Open Source

On Friday, James Urquhart and I recorded another episode of our podcast, Overcast, with Matt Asay on the topic of the relationship between cloud computing and open source. To me it was  fascinating topic to discuss.

Matt is VP Business Development at open source CMS company Alfresco and authors the blog The Open Road on CNET.

It was a fascinating conversation. As cloud computing emerges there are many lessons to be learned from the open source movement. I also completely agree with Matt that perhaps finally cloud computing offers a way for many open source companies to monetize their technology.

You can listen to it here.

Marketing Cloud Computing: Uncharted Territories

One of the aspects of cloud computing that receives too little attention is the massive change it brings to how software and IT infrastructure are marketed, sold, purchased and serviced. Through my work at GigaSpaces, and now advising start-ups and large companies with various cloud offerings, I have come to realize how much marketing cloud computing is still uncharted territory  -- and especially when it comes to the enterprise.

Many of the value propositions cloud brings to the table have been commonplace in the consumer Internet for more than a decade: self-service, ease-of-use, pay-by-the-drink pricing and so on. The same is true from the vendor's point-of-view: a low-touch, low-value, high-volume and short sales cycle. It's no surprise then that consumer-oriented companies, such as Amazon and Google, are the ones leading the charge in what is essentially a B2B market.

As I mention in a recent podcast with Matt Asay and James Urquhart, pioneers such as Amazon and Salesforce.com  -- and not to mention many of the cloud start-ups out there -- are learning what open source software companies have learned before them: software and IT infrastructure sales have changed forever. New products are adopted through daily decisions by the rank-and-file programmers, business users and system administrators; not through strategic decisions by the CIO or a central architecture committee. It also means that gone are the big upfront paydays, which placed the burden of the product actually delivering on its promise on the customer and not the vendor. In return, however, products that delight the customer will become fat cash cows.

I remember a few years ago reading about Salesforce.com's first enterprise sale: 500 seats to a small wealth management department in a large Wall Street bank. Yes, that same product of which the skeptics said enterprises would never trust to keep their sensitive sales information "on the Internet". I knew then that in the long run -- it's game over.

To be sure, there are many challenges to be overcome. What is the optimal pricing model and how to alleviate customer fears about how much they will end up paying? How to best utilize social media and automated marketing while addressing the processes and decision-making structures of larger companies? How to create an ecosystem of ancillary services and add-ons around the cloud product? How to provide cost-effective support without compromising quality? How to structure and compensate the sales and marketing organizations? These are all tricky questions, but some of us are working hard on figuring them out.

I hope to write some more posts on this topic because there are many lessons learned. Check out Hubs, Spokes and Islands in the Cloud for a start.

Hubs, Spokes and Islands in the Cloud

Many of the cloud start-ups I've been working and talking to during the past few months are facing some of the same go-to-market challenges. Larger companies are also facing these issues (see podcast with Intuit, for example). My intent is to write a series of posts discussing these issues and some of the considerations around them.

This first post in the series has to do with the cloud offering's role in its ecosystem. Before I jump into it, I acknowledge the fact that there is a very large body of work about this topic. Please see my footnote on this.

We can think about as the hub-spoke-island dilemma: cloud providers (IaaS, PaaS, SaaS) and cloud services need to make a strategic decision about their role within the ecosystem.

Some are the sun of their solar system (hub) and others play the role of the planets (spoke). But things can get a bit more complex than that and the decision on what role to play is not trivial.

The Hub

What characterizes a hub is that an entire ecosystem of products and services evolves around it. In addition, the hub typically "owns" the customer relationship. Some examples of cloud-related hubs are:

Amazon EC2 - A plethora of ancillary services and tools have been created to support Amazon's compute infrastructure-as-a-service. Examples of these satellite services include RightScale's EC2 management and deployment offerings and Hyperic's EC2 monitoring support. In addition, many vendors -- including IBM and Red Hat -- have made their software products available within the Amazon ecosystem, including pay-per-use hourly pricing (billed by Amazon) and packaged Amazon Machine Images (AMIs).

Another example is Salesforce.com/Force.com, with its AppExchange. AppExchange allows third-party providers to offer various applications that extend and enhance Salesforce.com's core CRM capabilities -- and many have.

Spokes

Spoke services are ones that complement and enhance a hub, but are not viewed as the central service in the eyes of the customer. In fact, spoke cloud services often have no value unless they are working in the context of a hub service.

There are many examples of spokes.The popular VerticalResponse email campaign service is a classic example. It has zero value without access to a customer database, and so it is most often used as an extension to a CRM application such as Salesforce.com. I have already mentioned RightScale and Hyperic, both of which make classic spokes. And there are many others, just check out Salesforce's AppExchange or Intuit's Marketplace.

Should Everyone Strive to be a Hub?

The answer is simply no. While the hub has the great advantage of owning the core relationship with the customer, one can only be a hub after having that customer base. And to attract many satellite services, it has to be large customer base, something that takes both time and money. Many spoke services don't have a large enough addressable market, or the wherewithal to make that investment worthwhile. Attaching yourself to an existing large customer base can be a very lucrative strategy.

Take for example TopTier, the company that made Shai Agassi rich and famous when it was acquired by SAP for $400 million in 2001. Agassi chose a "ride the elephant" strategy, developing a portal product for existing SAP application users. In a sense, become the spoke for a single large hub is a risky strategy. In fact, many companies have tried and failed in this strategy when they built apps for Microsoft Windows' hub or for other platforms. The risk is of course that the hub vendor itself will get into the business that the smaller company is in (instead of opting to acquire it as in the case of TopTier).

In the cloud, we saw this risk materialize for RightScale last year when Amazon announced it is releasing (or planning to release) several services that RightScale had provided as a value-add to Amazon, such as a web management console and auto-scaling.

Spoke to Many Hubs

Continuing with the RightScale story, the company realized they cannot be entirely dependent on Amazon as their sole hub, so they quickly introduced support for additional cloud providers, such as GoGrid and Flexiscale. In fact, many of the other spokes I have given here as an example, are in fact spokes to many hubs, like electrons shared by atoms in a covalent bond.

The "spoke to several hubs" approach has the advantage of both access to a much larger install base as well as significant reduction of the dependency on a single hub. It is almost an eventuality that any company with a spoke strategy will end up with.

Snowflake Patterns: Hub-Spoke-Hub-Spoke

Being a hub *and* a spoke is not mutually exclusive. CohesiveFT's Elastic Server is a good example for this. Elastic Server is a spoke to many cloud and virtualization platforms such as Amazon EC2, VMware and Parallels. But in turn it is also a hub for the many stack components that it supports - including many free open source and commercial software.

Don't Confuse Spokes with Customers

Not every service that is built on Amazon EC2, for example, is a spoke to it. Many services are simply customers of EC2 and so shouldn't be confused with being spokes, because as far as the customer is concerned it is not part of the hub's ecosystem.

A good example of this is Heroku, a Ruby platform-as-a-service. It is a cloud that allows Ruby developers to instantly deploy their applications. Users can easily fire up additional instances of the application to scale it. Heroku is built entirely on EC2 but that fact is transparent to the user. Heroku is taking advantage of the EC2 platform but does not play a role in its ecosystem. It does not benefit from EC2's install base, nor does it add value to direct EC2 users.

The Island of Doom

Perhaps the worse scenario is to be a completely independent island in the ecosystem. Neither a hub to many spokes, nor a spoke to one or many hubs. Very few companies other than Micorosoft, Google and a handful other mega-vendors can afford to quickly build both the product depth and breadth as well as the customer base to survive and thrive in this environment -- and even those large vendors are increasingly relying on the ecosystem.

The classic Silicon Valley island story is of course the early years of the Macintosh versus DOS/Windows. Apple famously insisted on tightly-coupling its hardware, OS and applications and all but shut out others from being able to develop to the platform. Microsoft, on the other hand (and this may sound strange to the younger folks reading this), took a more liberal approach and allowed others to develop apps to its DOS and later Windows operating systems. This allowed its operating system to have a much wider offering in terms of apps. Of course, eventually Microsoft crushed many of its own ecosystem partners by offering a competing application. Wordperfect anyone?

Building a Successful Hub

The key to becoming a successful hub -- besides having a great product/service and effective marketing -- is rapidly create an ecosystem around the service in question. This helps even small companies quickly offer a "whole product" because partners (spokes) develop complementary services the company cannot build itself fast enough.

Obviously, a hub with a large and growing customer base will attract many partners, but that's not enough. There are many ways to encourage additional spokes to support the hub, including:

• Open Platform/Open Source
• Open/Public APIs
• Offering a Software Development Kit (SDK) and other supporting tools that make developing for the platform easier
• Supporting standards which enable quickly integrating existing supporting products (such as Eucalyptus is doing with the Amazon API)
• Incentives and profit-sharing
• Helping partners monetize their solutions by providing marketing services and billing support
• Allowing easy self-service and support to partners

Note: as mentioned above, the topic discussed in this blog has been a core issue in the technology industry in general and specifically the software industry for decades. Much has been written and discussed about it, often with the terminology of platform versus application. Over the years experts have called it Value Networks (Clayton Christensen ), Value Constellation (Norman & Ramirez), Value Chain (Michael Porter">Michael Porter) and Whole Product (Geoffrey Moore ). This blog was a humble attempt to put this topic in the context of recent developments in cloud computing.

Enterprise Cloud Summit

I'll be speaking on a panel at the upcoming Enterprise Cloud Summit in Las Vegas (@Interop), May 18-19. The topic of the panel is "Where Can Things Go Wrong?" and should be anice conversation with the moderator Greg Ness and these panelists:

Peter Coffee, Director, Platform Research, salesforce.com
Randy Rowland, General Manager, Managed Hosting & Cloud Computing Services, Terremark Worldwide, Inc.
Geva Perry, Founder, Thinking Out Cloud
Bill McGee, Vice President, Products and Technology, Third Brigade

The rest of the agenda also looks very interesting. Check it out here. And there's also a CloudCamp event on Monday evening.

If you haven't signed up already, you can register here and get a 40% discount.

Hope to see you there.

Podcast on Open Cloud Manifesto

James Urquhart and I recorded a new Overcast episode in which we discuss the recent events surrounding the release of the Open Cloud Manifesto, or as James called it, Manifestogate.

Listen to it here.

The Open Cloud Manifesto: Much Ado About Nothing

If you're following cloud computing, you couldn't have missed the discussion about the "Open Cloud Manifesto" initiated by Reuven Cohen and reportedly supported by IBM, Sun and several other large and smaller vendors. The noise became a fevered pitch when Steven Martin of Microsoft wrote a scathing blog post about the Manifesto, essentially claiming that it was made to support the interests of certain large vendors (I imagine he means IBM) and that Microsoft wasn't given the opportunity to participate in the document's wording, but instead was asked to sign it as-is.

If you missed it all, here is some of the reporting and commentary on the topic that summarizes the issue:

• Reuven Cohen: Introducing the Open Cloud Manifesto
• Steven Martin: Moving Toward an Open Process on Cloud Computing Interoperability
• Krishnan Subramanian: Open Cloud Manifesto - The Fight Begins
• Reuven Cohen: Thank You Microsoft
• John Willis: Microsoft Was Out of Line
• Larry Dignan: Amazon Web Services: No Open Cloud Manifesto for us
• Larry Dignan: The Open Cloud Manifesto: Publish It Already

As the last link from Larry Dignan tells you, the actual document has been a big secret, and reporters and industry analysts who have received it are apparently under embargo to not publish it until Monday, March 30.

I received the document from four different sources and am under no obligation to keep it secret, so I am happy to publish it here for the first time. Please comment with your thoughts. As you can see, there's much ado about nothing. I am not quite sure why the people behind it want to keep it such a big secret. There's nothing controversial about it, in my opinion.

Download the Open Cloud Manifesto as PDF.

UPDATE: This post and the document have received a lot of attention. I previously hosted the document on the Scribd service. It has been viewed more than 2,500 5,500 times on Scribd, last I checked. I have decided, however, to remove the document from Scribd and only post the PDF as a link from this blog. Before any conspiracy theories emerge, I have only done this because of my dissatisfaction with the Scribd service -- I have not been asked to do so by anyone.[At this moment, I can't actually remove the document because Scribd is down. See what I'm saying?]

The Open Cloud Manifesto A call to action for the worldwide cloud community Draft 1.0.9 Introduction The buzz around cloud computing has reached a fever pitch. Some believe it is a disruptive trend representing the next stage in the evolution of the internet. Others believe it is hype, as it uses long established computing technologies. As with any new trend in the IT world, organizations must figure out the benefits and risks of cloud computing and the best way to use this technology. One thing is clear: The industry needs an objective, straightforward conversation about how this new computing paradigm will impact organizations, how it can be used with existing technologies, and the potential pitfalls of proprietary technologies that can lead to lock-in and limited choice. This document is intended to initiate a conversation that will bring together the emerging cloud computing community (both cloud users and cloud providers) around a core set of principles. We believe that these core principles are rooted in the belief that cloud computing should be as open as all other IT technologies. This document does not intend to define a final taxonomy of cloud computing or to charter a new standards effort. Nor does it try to be an exhaustive thesis on cloud architecture and design. Rather, this document speaks to CIOs, governments, IT users and business leaders who intend to use cloud computing and to establish a set of core principles for cloud providers. Cloud computing is still in its early stages, with much to learn and more experimentation to come. However, the time is right for the members of the emerging cloud computing community to come together around the notion of an open cloud. What is Cloud Computing and Why is it Important? In order to understand the core principles of an open cloud, we need to first level set on some basic definitions and concepts of cloud computing itself. First, what is the cloud? The architecture and terminology of cloud computing is as clearly and precisely defined as, well, a cloud. Since cloud computing is really a culmination of many technologies such as grid computing, utility computing, SOA, Web 2.0, and other technologies, a precise definition is often debated. While definitions, taxonomies and architectures are interesting, it is more important to understand the value propositions for cloud computing. We need to understand how suppliers of cloud technology will come together to deliver on the promise of cloud computing. The key characteristics of the cloud are the ability to scale and provision computing power dynamically in a cost efficient way and the ability of the consumer (end user, organization or IT staff) to make the most of that power without having to manage the underlying complexity of the technology. The cloud architecture itself can be private (hosted within an organization’s firewall) or public (hosted on the Internet). These characteristics lead to a set of core value propositions: Scalability on Demand All organizations have to deal with changes in their environments. The ability of 2 cloud computing solutions to scale up and down is a major benefit. If an organization has periods of time in which their computing resource needs are much higher or lower than normal, cloud technologies (both private and public) can deal with those changes. The organization pays for the IT resources it actually uses; it does not have to maintain multiple sets of artificially high levels of resources to handle peak demands. Streamlining the Data Center An organization of any size will have a substantial investment in its data center. That includes buying and maintaining the hardware and software, providing the facilities in which the hardware is housed and hiring the personnel who keep the data center running. An organization can streamline its data center by taking advantage of cloud technologies internally or by offloading workload into the public. Improving Business Processes The cloud provides an infrastructure for improving business processes. An organization and its suppliers and partners can share data and applications in the cloud, allowing everyone involved to focus on the business process instead of the infrastructure that hosts it. Minimizing Startup Costs For companies that are just starting out, organizations in emerging markets, or even “Skunk Works” groups in larger organizations, cloud computing greatly reduces startup costs. The new organization starts with an infrastructure already in place, so the time and other resources that would be spent on building a data center are borne by the cloud provider, whether the cloud is private or public. Challenges and Barriers to Adoption Although the cloud presents tremendous opportunity and value for organizations, the usual IT requirements (security, integration, and so forth) still apply. In addition, some new issues come about because of the multi-tenant nature (information from multiple companies may reside on the same physical hardware) of cloud computing, the merger of applications and data, and the fact that a company’s workloads might reside outside of their physical on-premise datacenter. This section examines five main challenges that cloud computing must address in order to deliver on its promise. Security Many organizations are uncomfortable with storing their data and applications on systems they do not control. Migrating workloads to a shared infrastructure increases the potential for unauthorized exposure. Consistency around authentication, identity management, compliance, and access technologies will become increasingly important. To reassure their customers, cloud providers must offer a high degree of transparency into their operations. 3 Data and Application Interoperability It is important that both data and applications systems expose standard interfaces. Organizations will want the flexibility to create new solutions enabled by data and applications that interoperate with each other regardless of where they reside (public clouds, private clouds that reside within an organization’s firewall, traditional IT environments or some combination). Cloud providers need to support interoperability standards so that organizations can combine any cloud provider’s capabilities into their solutions. Data and Application Portability Without standards, the ability to bring systems back in-house or choose another cloud provider will be limited by proprietary interfaces. Once an organization builds or ports a system to use a cloud provider’s offerings, bringing that system back in-house will be difficult and expensive. Governance and Management As IT departments introduce cloud solutions in context of their traditional datacenter, new challenges arise. Standardized mechanisms for dealing with lifecycle management, licensing, and chargeback for shared cloud infrastructure are just some of the management and governance issues cloud providers must work together to resolve. Metering and Monitoring Business leaders will want to use multiple cloud providers in their IT solutions and will need to monitor system performance across these solutions. Providers must supply consistent formats to monitor cloud applications and service performance and make them compatible with existing monitoring systems. It is clear that the opportunity for those who effectively utilize cloud computing in their organizations is great. However, these opportunities are not without risks and barriers. It is our belief that the value of cloud computing can be fully realized only when cloud providers ensure that the cloud is open. The Goals of an Open Cloud Customers expect that the cloud services they use will be as open as the rest of their IT choices. As mentioned earlier, there are significant barriers to the adoption of cloud computing. As cloud providers ask their potential customers to accept a loss of control over their resources, hiding vendor lock-in behind the benefits of cloud computing will lead to long-term damage to the cloud computing industry. As an open cloud becomes a reality, business leaders will benefit in several ways. Choice As an organization chooses a provider or architecture or usage model, an open cloud will make it easy for them to use a different provider or architecture as the business 4 environment changes. If the organization needs to change providers because of new partnerships, acquisition, customer requests or government regulations, they can do so easily. If the organization deploys a private cloud, they can choose between providers as they extend their capacity and/or functional capabilities. Resources that would have been spent on a difficult migration can instead be spent on innovation. Flexibility No matter which cloud provider and architecture an organization uses, an open cloud makes it easy for them to work with other groups, even if those other groups choose different providers and architectures. An open cloud will make it easy for organizations to interoperate between different cloud providers. Speed and Agility One of the value propositions of cloud computing is the ability to scale hardware and software as needed. Using open interfaces allows organizations to build new solutions that integrate public clouds, private clouds and current IT systems. As the conditions of the organization change, an open cloud lets the organization respond with speed and agility. Skills A side effect of an open cloud is the availability of skilled professionals. If there are many proprietary programming models, a given IT professional is unlikely to know more than a few of them. In an open cloud, there is a small set of new technologies to learn (especially when existing technologies are utilized), greatly enhancing the chances that the organization can find someone with the necessary skills. Principles of an Open Cloud Of course, many clouds will continue to be different in a number of important ways, providing unique value for organizations. It is not our intention to form standards for every capability in the cloud and create a single homogeneous cloud environment. Rather, as cloud computing matures, there are several key principles that must be followed to ensure the cloud is open and delivers the choice, flexibility and agility organizations demand: 1. Cloud providers must work together to ensure that the challenges to cloud adoption (security, integration, portability, interoperability, governance/management, metering/monitoring) are addressed through open collaboration and the appropriate use of standards. 2. Cloud providers must not use their market position to lock customers into their particular platforms and limiting their choice of providers. 3. Cloud providers must use and adopt existing standards wherever appropriate. The IT industry has invested heavily in existing standards and standards organizations; there is no need to duplicate or reinvent them. 4. When new standards (or adjustments to existing standards) are needed, we must be judicious and pragmatic to avoid creating too many standards. We must ensure 5 that standards promote innovation and do not inhibit it. 5. Any community effort around the open cloud should be driven by customer needs, not merely the technical needs of cloud providers, and should be tested or verified against real customer requirements. 6. Cloud computing standards organizations, advocacy groups, and communities should work together and stay coordinated, making sure that efforts do not conflict or overlap. Conclusion This document is meant to begin the conversation, not define it. Many details (taxonomies, definitions and scenarios, for example) will be filled in as the cloud computing community comes together. We have outlined the challenges facing organizations that want to use the cloud. These issues lead to a call to action for the IT industry around a vision of an open cloud. We as industry participants must work together to ensure that the cloud remains as open as all other IT technologies. Some might argue that it is too early to discuss topics such as standards, interoperability, integration and portability. Although this is a time of great innovation for the cloud computing community, that innovation should be guided by the principles of openness outlined in this document. We argue that it is exactly the right time to begin the work to build the open cloud. Companies that support the open cloud manifesto are listed at www.opencloudmanifesto.org. 6 

The Legendary Enterprise Sale: Goodbye and Thanks for All the Bluebirds

Selling to the enterprise is a mythical goal in the software industry. The million dollar deal is the stuff of legends, and throughout the '90s and early 2000s, the dream of every sales person. With 4% to 8% commissions (depending on stage of company and sales person stature), who can blame them.

But those days are over. Even before the current recession, the tides were turning. Unless you are Oracle, IBM, HP or a handful of other mega-vendors, you're not going to see 7-figure deals, well, except for the occasional bluebird.

We're now witnessing an increasing trend of bottom-up sales. A casual decision made by developers on a day-to-day basis, not a grand strategy laid out by the CIO. Try-and-buy is the norm, and so are subscription payments and other models that take off the financial burden from the customer and places it on the vendor. Long gone are the days that a large vendor can offload $50 million of upfront software licenses on its customer, add another $150 million in  professional services for customization and integration, and 3 years later (with ongoing maintenance and support fees, mind you), leaving the customer with what is essentially shelfware (at which point, to avoid embarrasment, the customer declares victory on the project). 

Charlie Federman, a VC I deeply respect from the days he was on the board of directors of GigaSpaces wrote an interesting post, entitled Firing Prospects, with some anecdotal evidence on the phenomenon:

I met today separately with two successful CEO's who, unprompted told me they were deemphasizing their marketing/sales efforts to Enterprise accounts; one company is in the application arena, and the other is in the infrastructure space.

Each told a similar story:

They don't have the 'patience or resources to go through the hoops' required in committee sales. Translation, is that they don't want to fund the direct salesforce/field engineers for the traditional 6 month sales cycle, where they have to commit the equivalent of hundreds of thousands of dollars upfront before a decision is made. Moreover, if the decision is positive, it's normal to wait a few more quarters for implementation to move forward.

Each stressed the opportunity cost is simply too high when many alternative channels are present that are open to a 'fast test/fast purchase' decision cycle. Today, their biggest issue is prioritizing their time/resources in an environment where they receive near-instant market feedback from traffic, trial and conversion statistics. Direct Enterprise sales (as opposed to Business Development) is being extracted from their company DNA.

The history of the trend away from the enterprise sale is easily traceable. It starts with free-trial CDs; it really picks up steam with downloadable enterprise software (salute to the WebLogic folks). It becomes downright mainstream with open source: Linux/RedHat, Jboss, MySQL and the rest. And now, we come to cloud computing: the final nail in the enterprise sale coffin.

Cloud computing, whether infrastructure-as-a-service, platform-as-a-service or software-as-a-service empowers developers, system admins and others in the rank & file to move quickly with their projects, select the easiest tools, and pay very little for them as they progress through the application lifecycle of development, testing, QA, staging, production and post production (on going maintenance, upgrades and end-of-life). Because it does not involve large capital expenditures, and initially requires very little expenditure of any kind, budgetary approvals can usually be made at much lower levels.

It's an unstoppable trend and many of the software start-ups I am working with are realizing they have an urgenmt taskl to move to a SaaS model (if they're not already there).

Of course, the new model represents some new challenges for both the vendors and the customers, but the benefits are so compelling, it's inevitable.

Memory-Based Architectures and the Cloud

Todd Hoff at HighScalability.com published another excellent article entitled Are Cloud-Based Memory Architectures the Next Big Thing? Chock full of analysis, data, links, examples and references. IMHO, it's a must-read piece for developers and architects.

As I noted in the comments to Todd's post, in addition to the many benefits of memory-based architectures which Todd lists, there is also the cost benefits in the cloud, which I discussed in Cloud Pricing and Application Architecture.

An excerpt from Todd's piece:

       

RAM = High Bandwidth and Low Latency

Why are Memory Based Architectures so attractive? Compared to disk RAM is a high bandwidth and low latency storage medium. Depending on who you ask the bandwidth of RAM is 5 GB/s. The bandwidth of disk is about 100 MB/s. RAM bandwidth is many hundreds of times faster. RAM wins. Modern hard drives have latencies under 13 milliseconds. When many applications are queued for disk reads latencies can easily be in the many second range. Memory latency is in the 5 nanosecond range. Memory latency is 2,000 times faster. RAM wins again.

       

RAM is the New Disk

The superiority of RAM is at the heart of the RAM is the New Disk paradigm. As an architecture it combines the holy quadrinity of computing:

Performance is better because data is accessed from memory instead of through a database to a disk.

Scalability is linear because as more servers are added data is transparently load balanced across the servers so there is an automated in-memory sharding.

Availability is higher because multiple copies of data are kept in memory and the entire system reroutes on failure.

Application development is faster because there’s only one layer of software to deal with, the cache, and its API is simple. All the complexity is hidden from the programmer which means all a developer has to do is get and put data.

Read the whole thing.

Cloud Computing Security Podcast

Security is consistently brought up as one of the main barriers to the adoption of cloud computing and one of the big challenges it presents. Issues such as security in virtualized environments, multi-tenant architectures and the cloud in general are often discussed with very little real-world understanding of the problems and the potential solutions.

So it's nice to discuss it with someone who actually knows what he's talking about, as James Urquhart and I do with Chris Hoff, the well-respected security expert and blogger, in Show #8 of our cloud computing podcast, Overcast.

Listen to it here.

Amazon Reserved Instances: Do They Make Business Sense?

Amazon just announced that they are giving an option to pay upfront for Reserved Instances on EC2. See Amazon CTO Werner Vogel's blog for more details.

I set out to understand the economics of Reserved Instances. For that purpose, I created a calculator that allows you to plug in the number of hours you expect to use the AMI during the year, and will then tell you how much money you will save or lose by using Reserved Instances versus pure On-Demand Instances. I share this calculator below as a embedded Zoho spreadsheet (if you cannot see it well, click on the full screen link on the top-right).

The way to use it is very simple. For each instance size, just plug in the number of hours you expect to use the instance during the year in the light blue cells. You will then get the results for both 1 year and 3 year contracts in the corresponding gray cells. If it's a positive number, that's how much you save by paying the upfront Reserved Instance fee. If it's a negative number, it's how much you'll lose.

The default number I put in the hours column, 8760, is 24x365. So if, for example, you run a Large AMI for the entire year non-stop, you will save $1,153 by using reserved instances.

If you are curious to know the break-even point, it is 4,643 hours annually for the 1-Year fee and 2,381 hours *annually* for the 3-Year fee. In other words, if you expect to run an instance for more than 4,643 hours during the coming 12 months (works out to an average of 12 hours a day), you're better off with Reserved, otherwise, stick to On-Demand.

Without further ado:

Feel free to download the spreadsheet, and if you find any errors in it, please let me know.

There are two more important considerations you should take into account in any ROI calculation for this:

• If there is any uncertainty with regards to the expected number of hours, you should take into account the probability that you will overshoot or undershoot the number of hours and create an Expected Value based on that. There are no refunds on the upfront fees!
• Consider the time-value-of-money of your upfront fees. In other words, what value could you get for that money by investing it in other areas of the business (or in U.S. T-Bonds for that matter). You should determine your "discount rate" and calculate a Net Present Value.

I admit I 'm somewhat obsessed with cloud pricing lately, but that's for two good reasons. First, as one of the main value propositions of cloud computing is cost savings, I think it is important that as an industry we examine what the vendors are doing and making sure we're getting it right. Second, for my own selfish reasons. I am working on several projects now where I either need to figure out the economics of using cloud for an end customer (i.e., a company that wants to run its apps in a cloud environment and needs to figure out ROI), as well as for Platform-as-a-Service vendors who are leveraging EC2 under the hood.

Call for Companies: Under the Radar, Cloud Computing

I spoke to the folks organizing the Under the Radar event (April 24, Mountain View, CA), which is focused on cloud computing. They already have a very impressive line-up of companies presenting, but they are looking for more.

Here's the info the organizers sent me:

we’re looking for startups who are still “under the radar” and looking to get in front of CIOs, CTOs, VPs Technology at companies like AT&T, Getty Images, Google, Microsoft, Cisco, etc, as well as VCs, industry press etc.
 
This is the link to apply: http://www.undertheradarblog.com/nominate-to-present/
We’re looking for startups in: Platforms | Virtualization | Saas | Collaboration | Business Apps | and more... Deadline is March 20.

About the event:  http://undertheradarblog.com

For anyone looking to understand the cloud space and see who’s innovating AND who’s buying -  this is a one-day deep dive into what’s happening.

The current line-up of companies is quite impressive with some of the hot up & comers out there, including Heroku, New Relic, Twilio, Sauce Labs, cTera, Zuora and others. The judges also like an impressive bunch with folks from big companies such as my buddy James Urquhart from Cisco, Joe Weinman from AT&T and Matthew Glotzbach from Google, as well as prominent journalists and venture capitalists.

For those who just want to attend, I understand they are still selling tickets at the early bird price. You can find them here: http://www.acteva.com/booking.cfm?bevaid=165707

Looking forward to the event and seeing you all there.

Cloud Pricing and Application Architecture

I have been giving a lot of thought lately to cloud pricing. As an adviser to companies from both sides of the issue -- cloud (IaaS and PaaS) providers and cloud users (and potential users) -- I've had an interesting perspective on the issue, which I will discuss in this and several future posts.

Here, I want to focus on how cloud pricing models (might) affect application architecture design decisions.

Even in traditional data centers and hosting services, software architects and developers give some consideration to the cost of the required hardware and software licenses to run their application. But more often than not, this is an afterthought.

Last May, Michael Janke published a post on his blog which tells the story of how he calculated that a certain query for a widget installed in a web app -- an extremely popular widget -- cost the company $250,000, mainly in servers for the database and RDBMS licenses.

From my experience, companies rarely get down to the level of calculating the costs of specific features, such as a particular query.

So while this kind of metric-based and rational approach is always advisable, things get even more interesting in the cloud.

1. It's a pay-per-use model. Any optimization of resource utilization, big or small, will yield cost-savings proportional to the resource savings.
2. It is typically component based pricing. In AWS, for example, there are separate charges for CPU/hours, incoming and outgoing data charges for the servers, separate charges for the use of the local disk on the server (EBS), charges for storage (storage volume and bandwidth), charges for the message queue service, etc.
3. You get a real-time bill broken down by exact usage of components (at least on AWS).

In other words, whether you were planning on it or not, your real-time bill from your cloud provider will scream at you if a certain aspect of your application is particularly expensive, and it will do so at a very granular level, such as database reads and writes. And any improvements you make will have a direct result. If you reduce database reads and writes by 10% those charges will go down by 10%.

This is, of course, very different than the current prevailing model of pricing by discrete "server units" in a traditional data center or a dedicated hosting environment. Meaning, if you reduce database operations by 10%, you still own or rent that server. The changes will have no effect on cost. Sure, if you have a very large application that runs on 100 or 1,000 servers, tan such an optimization can yield some savings and very large-scale apps generally do receive a much more thorough cost analysis, but again, typically as an afterthought and not at such a granular level.

Another interesting aspect is that cloud providers may be offering a different costs structure than that of simply buying traditional servers. For example, they may be charging a proportionally higher rate for local disk I/O operations (Amazon charges $0.10 per million I/O requests to EBS). Something that would barely go into consideration when buying or renting discrete servers (whether physical or virtual).

Which brings us to the topic of this post. Cloud pricing models will affect architectural choices (or at least they should). Todd Hoff discussed this issue in a HighScalability.com post entitled Cloud Programming Directly Feeds Cost Allocation Back Into Software Design:

Now software design decisions are part of the operations budget. Every algorithm decision you make will have dollar cost associated with it and it may become more important to craft algorithms that minimize operations cost across a large number of resources (CPU, disk, bandwidth, etc) than it is to trade off our old friends space and time.

Different cloud architecture will force very different design decisions. Under Amazon CPU is cheap whereas under [Google App Engine], CPU is a scarce commodity. Applications between the two niches will not be easily ported.

Todd recently updated this post with an example from a Google App Engine application in which:

With one paging algorithm and one use of AJAX the yearly cost of the site was $1000. By changing those algorithms the site went under quota and became free again. This will make life a lot more interesting for developers.

So what architectural changes can you make to reduce costs on the cloud? Here's one example:

A while back I wrote a post about GigaSpaces and the Economics of Cloud Computing. GigaSpaces has been -- for those of you new to my blog -- my employer for the past 5 years. I gave five reasons for why GigaSpaces will save costs on the cloud, but what I discuss above adds a sixth one. Because GigaSpaces uses an in-memory data grid as the "system-of-record" for your application, it significantly reduces database operations (in some cases a 10-to-1 reduction). In AWS, this could reduce significant EBS and other charges. It also happens to be good architectural practice. For more on that see David Van Couvering's Why Not Put the Whole Friggin' Thing in Memory?

Taking this approach as an example, it could have saved a significant portion of Michael Janke's $250,000 query off the cloud, and perhaps an even bigger porportion on the cloud.

If anyone has other ideas on how architectural decisions could affect costs on the cloud, please share them in the comments.

P.S. This post is another example of Why (and What) Every Business Exec Should Know About Cloud Computing.

Cloud Computing Jobs: A Leading Indicator

Just did a trend search on job site Indeed.com for "cloud computing". Whoa.

Job postings are often a leading indicator for expected business activity, and this graph speaks for itself. Cloud computing is clearly more than hype when so many companies are hiring for cloud-related positions.  It's also interesting to note some of the companies that show up when you run the search. You get a little bit of insight into the plans of companies such as Dell, Yahoo, Intuit and VMWare.

You can also subscribe to the cloud computing job search RSS feed.

Hyperic and the Cloud Podcast

James Urquhart and I recorded show #7 of Overcast, our podcast series on cloud computing. It's up and available here for your listening pleasure.

In this episode we have a discussion with Javier Soltero, CEO of Hyperic. Reposting the show notes:

Show Notes:

• Javier gives us a general background on Hyperic and specifically its activities in the cloud, which include CloudStatus.com and the Hyperic HQ Amazon Machine Image (AMI).
• Javier reveals some of Hyperic's developments in the works, including a technology that allows easily instrumenting Java, Hadoop and Memcached applications and exposing the data  to CollectD. 
• We discuss at length Javier's recent blog post The Cloud Dilemma for Developers, in which Javier writes about the fact that in a cloud environment developers are required to address operational issues, such as monitoring and management. 
• Javier explains how application monitoring and management requirements are different in cloud computing, and why he believes traditional tools won't cut it in the cloud  
• and lots more...  
• Companies and products mentioned in this podcast include Mosso, GoGrid, Google App Engine, Heroku, Amazon Web Services, Salesforce.com, GigaSpaces, Cisco and Windows Azure.

What are Amazon EC2 Compute Units?

I've been working on a couple of projects lately in which the goal is to assess, among other things, the financial viability and justification for running applications in an infrastructure-as-a-service environment such as Amazon Web Services (and particularly EC2 and S3), GoGrid or Joyent.

While I developed the general model for this ROI calculation, one of the most difficult aspects has been coming up with the equivalent of traditional server capacity in EC2. For example, one of the existing applications is currently running about 10 servers in a U.S. location and 3 servers in a European location. The servers run the app's database servers, application servers, web servers and other components, and range from Single CPU servers to Single-CPU/Dual-Core to Two-CPU/Dual-Core to 4-CPU/Dual-Core to 2-CPU/Quad-Core.

Now, how do you figure out the equivalent type of Amazon Machine Instances on EC2?

Amazon provides the following AMI information:

Instance	EC2 Compute Units	Memory (GB)	Instance Storage (GB)	Platform	I/O Performance	Hourly Price
Small	1 (1 Virtual Core x 1 Compute Unit)	1.7	160	32-bit	Moderate	$0.10
Large	4 (2 Virtual Core x 2 Compute Unit)	7.5	850	64-bit	High	$0.40
X-Large	8 (4 Virtual Core x 2 Compute Unit)	15	1690	64-bit	High	$0.80
High-CPU Medium	5 (2 Virtual Core x 2.5 Compute Unit)	1.7	350	32-bit	Moderate	$0.20
High-CPU XL	20 (8 Virtual Core x 2.5 Compute Unit)	7	1690	64-bit	High	$0.80

The columns Memory, Instance Storage, Platform and Price are all quite clear in this chart. I/O Performance leaves room for further explanation, but I'll put that aside. But what is an "EC2 Compute Unit"?

Amazon explains as follows:

The amount of CPU that is allocated to a particular instance is expressed in terms of these EC2 Compute Units. We use several benchmarks and tests to manage the consistency and predictability of the performance of an EC2 Compute Unit. One EC2 Compute Unit provides the equivalent CPU capacity of a 1.0-1.2 GHz 2007 Opteron or 2007 Xeon processor.

It so happens that in 2007 AMD and Intel released both dual-core and quad-core models of the Opteron and Xeon chips, respectively. So it's already not clear what an EC2 Compute Unit compares to. But I'll assume they are referring to the dual-core (given the date this information was published and the fact that quad-cores seem too powerful).

Another thing to note is that the clock speed is quite low, but again, let's put that aside because for most common applications that's probably not the bottleneck.

In any case, I understand from this explanation then, that a High-CPU Extra-Large Instance provides the equivalent of 20 Opteron or Xeon dual-core chips. Impressive for $0.80/hour, but somehow I have a suspicion that's not the case.  Perhaps they mean it is actually equivalent to the same number of cores in those machines? And not the sockets (what most people would refer to as CPUs)?

Also, the Amazon site does not explain what "virtual cores" are in the EC2 environment. And why in the High-CPU instances each virtual core has 2.5 EC2 Compute Units. 2.5? Really?

To figure out the exact capacity you will get from AMIs, Amazon recommends performing benchmarks. They say:

One of the advantages of EC2 is that you pay by the instance hour, which makes it convenient and inexpensive to test the performance of your application on different instance families and types. One good way to determine the most appropriate instance family and instance type is to launch test instances and benchmark your application.

It's great that you are paying for the instances on an hourly basis, but for a small organization, whose existing application is currently not designed to work in an EC2-like environment, conducting such benchmark is quite a large and expensive task, especially if the whole point is to assess if EC2 is an economically feasible solution in the first place.

A bit of a chicken & egg situation.

I'm wondering if anyone out there has conducted benchmarks that compare compute capacity of AMIs versus "terrestrial" servers (i.e., physical servers). If you know of such benchmarks, please link to them in the comments below. I realize that the case maybe different for different kinds of apps (cpu-intensive, data-intensive, i/o bound, etc.), but still, such information might be helpful.

UPDATE:

There is an interesting comment to this post from Wes Felter with specifics on the EC2 Compute Units.

In addition, I posted this on the Cloud Computing group on Google Groups, and got some interesting responses. (If you're interested in the topic, follow the thread). 

My former colleague from GigaSpaces, Jim Liddle, writes:

Geva,

Have a look at this post from another blog I contribute to :
http://www.cloudiquity.com/2009/01/amazon-ec2-instances-and-cpuinfo/.

Here we post the results from /proc/cpuinfo for each of the EC2
instance types.

Also look at: http://www.cloudiquity.com/2009/01/amazon-ec2-network-and-s3-performa...
where we have a look at E2 network and S3 performance.

Hope this helps

Jim

Jim Liddle
http://www.gigaspaces.com/cloud

And JL Valente writes:

Geva
Please check project zeppelin on sourceforge. It supports exactly what you are looking for in terms of benchmarking thru DMTF lmbench. It was designed for the same reason that there is no other way to verify availability to promise and that a user really gets what it pays for.

My other former colleague from GigaSpaces, Dekel Tankel, reminded me that we actually conducted a benchmark of EC2 at GigaSpaces and he wrote me the following:

Small AMI = Single Core, 1.2 GHz
High CPU Ex. Large = 60-75% of Quad-Core 2.3 Ghz

The rest is somewhere in the area of Dual-Core 2.3 Ghz

Need to remember that due to the hypervisor limitations, workloads with high I/O characteristics will practically perform worse than the above

These numbers don't fit well with the information that Wes posted below, but obviously there may be different results for different apps, depending on how I/O, memory or CPU bound they are.

In any case I see a problem here, as according to the information provided by Amazon the High-CPU-XL instance should provided 20 times the compute capacity of a Small instance. Even according to Wes, who seems to be the kindest to Amazon in his numbers, it is only about 16 times the compute capacity. I realize this is not a very sophisticated measurement but it's an indication.

Why (and What) Every Business Exec Needs to Know About Cloud Computing

A couple of weeks ago Harvard Business School professor Andrew McAfee posted the following question on Twitter:

@amcafee Is cloud computing something that every exec (even NON-IT ones) needs to know about? Should I cover it in my MBA course this semester?

My answer to Professor McAfee is that it is, because cloud computing is as much a business phenomenon as it is a technological one. Most industries will be affected by cloud computing as it catches on and is embraced by the mainstream.

I classify the importance of cloud computing to business in two broad categories: operational and strategic. But before I jump into details, a quick general note. Increasingly, industries are driven by IT. From manufacturing to travel & shipping to telecommunications to financial services, growing aspects of the business run on computers and software. So much so, that some industries, such as capital markets trading, are primarily technology businesses. With that in mind, if we accept that cloud computing is a "once in a decade" kind of innovation, then surely it will have a significant impact on a multitude of businesses. An obvious previous example of this is the Internet.

But still, the question remains if cloud computing should be primarily the concern of the IT execs. After all, much of it is about deep technical issues (or so it is perceived) and many of the business execs lack the knowledge of those details to make a contribution to the decision-making -- or so some have suggested.

The Operational Importance of Cloud Computing

The operational importance of cloud computing is for the most part a tactical benefit, but it can evolve into a strategic one. Cloud computing -- and I include in this IaaS, PaaS and SaaS -- acts as an efficiency driver. It reduces costs and increases agility through the combined benefits of outsourcing and on-demand pay-per-use as opposed to over-utilization and a large upfront investment. It also gives a scalability guarantee: quick access to additional resources in case additional capacity is needed to handle success.

The implications of some of the decisions about cloud computing are so substantial to the business that every executive in the business needs to understand the key high-level considerations and the possible consequences. This is especially true because in some cases the IT execs may have various vested interests in the decision and are not basing it purely on what's best for the firm. For example, because cloud computing is an act of outsourcing, this may affect IT jobs in the company. An opposite example might be that the IT execs want to adopt cloud computing because it removes "headaches" from them.

In a presentation I have been giving to executives at different companies I discuss at length the various issues that business execs need to understand as they discuss cloud strategy with their IT counterparts. They include assessing whether the proposed cloud-sourced functions are core to the business or not, whether they create a competitive advantage, vendor lock-in and strategies to minimize it, and how the company can get the most bang for the buck (ROI analysis). I also discuss what elements of a company's business should be "cloudsourced". Does it make sense to build an internal cloud or a hybrid?

The Strategic Importance of Cloud Computing

But perhaps far more interesting is how cloud computing can be a transformational technology that drives innovation and creates a breakthrough strategy. 

Consider the case of Amazon and their rationale for coming out with Amazon Web Services. As CEO Jeff Bezos explains in an interview with Om Malik, Amazon needed to develop the various services in AWS for their own internal purposes -- specifically, to create more efficiency in the interactions between network engineering and application development groups. They quickly realized, however, that they have come up with a true innovation that would benefit external users as well.

Amazon, by the way, has a history of looking at their business in this fashion -- trying to identify where their core strengths are in a way that may not be obvious to external observers. Years ago, they were one of the first companies on the Internet to open up their platform for other retailers. Amazon understood that one of its distinct competencies is running an extremely efficient infrastructure for online retailing -- payment processing, warehousing, supply chain management, personalization and recommendation engines and so on. 

Like Amazon, many companies have developed distinct competencies that go deeper than the products and services they sell. For example, I talked to a Wall Street investment bank that developed what they believe is a very powerful platform for Value-at-Risk (VaR) analysis and other intense calculations. It provides a full infrastructure which allows plugging in various models and algorithms. The bank is already providing the platform as a service to hedge funds and insurance companies, but this service is almost an afterthought and is extremely ineffcient. The bank is now seriously onsidering opening it up as a full-fledged Platform-as-a-Service to which companies can sign up online and use a self-service approach to run their models on it.

I've presented these concepts at large companies in a range of insudtries, and invariably a flow of ideas comes streaming on what aspects of the company's internal operations can they open up as a service.

Another classic example is Salesforce.com, which opened up the underlying platform on which they built their salesforce automation (SFA) and CRM application for anyone to build applications with. Salesforce.com goes even further. It allows these third-party applications to access customer data already entered into the SFA application (with the customer's permission of course).

Another interesting example is Intuit, which announced last year that it is opening its Quickbase PaaS for 3rd parties to develop applications on. But here's the twist: there will be easy integration to customers' existing Quickbooks data (and presumably to data on TurboTax and Quicken). Intuit realized that it has distinct competencies in 1) building an extremely secure, reliable and scalable application platform, and 2) possessing vast amounts of financial data of American businesses, households and taxpayers. And it wants to leverage these assets -- perhaps opening up a whole new high growth business.

Similarly, many businesses should take a long, hard look at their distinctive competencies (note that this is different than "core competency", but I will dive into that another time). This might be on all levels of cloud computing, for example:

Infrastructure-as-a-Service: A healthcare company might provide infrastructure that is HIPPA-compliant for use by other businesses in the industry.

Platform-as-a-Service: A logistics and supply chain management company such as FedEx might open up its platform for companies to build customized versions of applications that target specific industry or niche needs.

Software-as-a-Service: Many companies that today provide different services via software that is used in-house only, can expose that software to the end consumer. We've seen many examples of this on the Web for years. A classic one would be the travel industry, which opened web versions of reservation and booking software that was once exclusively accessible to the travel companies themselves or travel agencies.

I've been working with a number of companies on ways to uncover and develop such ideas by looking at the principles underlying cloud computing and combining them with innovation models such as those found in Blue Ocean Strategy and Seeing What's Next.

For example, I ask the question "Are there areas in your business that were traditionally considered too complex for end customers to access in a self-service model?" There always are and it often turns out that with today's technology developments many of the assumptions no longer hold true.

But more importantly, it often turns out that cloud computing enables targeting new kinds of customers and opening new markets, or what Clayton Christensen calls in Seeing What's Next nonconsumers, overshot customers and undershot customers.

In conclusion, cloud computing is a game-changer, both technologically and business-wise and wise business execs should understand the forces that will impact their industry. So Professor McAfee, please teach your students about Cloud Computing.

Open APIs and Cloud Computing Standards

My previous post, Beware Premature Elaboration, discussed some of the issues around cloud computing standards. If you want to hear more about the topic, and especially GoGrid, one of the most innovative cloud providers in the market, check out the Overcast Show #6. My co-host, James Urquhart, and I interview Randy Bias and Michael Sheehan of GoGrid.

We discuss many topics (see Show Notes below), but I think the most interesting is the fact that GoGrid recently open sourced their API specification. As I said before, this is the right way to go. We have a number of open source APIs, including GoGrid, EUCALYPTUS, Enomaly and others, and now the market will start determining the winner.

The GoGrid case is particularly interesting because of two main reasons. The first is that it is a proven API that is up and running in production and reflects a lot of experience from the trenches. The second is they are making a proactive attempt to reach out to other cloud providers and other members in the ecosystem to support their API, as Randy discusses in the podcast.

Listen to the podcast here.

Here are the full Show Notes:

Show Notes:

After a long hiatus we are back with the Overcast podcast. In Show #6 we have a discussion with Randy Bias and Michael Sheehan of GoGrid. Some of the topics we cover include:

• The distinction that Randy and Michael have made in their blog posts between a Cloudcenter and Infrastructure Web Services, and the different approach GoGris is taking to cloud computing compared to Amazon Web Services
• The role of Platform-as-a-Service players, such as Google App Engine, and a glimpse into some of GoGrid's thoughts on opening up their infrastructure for other to offer a PaaS on top of it 
• Cloud computing standards -- do we need them now and it what is the correct approach for achieving them? 
• GoGrid's recent open sourcing of their APIand their efforts to work with other cloud providers and related vendors and projects (such as Flexiscale, RightScale andEucalyptus) to rally around the GoGrid API
• The role of projects such as Puppet andChef in cloud computing, and GoGrid's plans for these technologies 
• GoGrid's Cloud Connect offering - a hybrid model for dedicated and cloud-style hosting  
• GoGrid's storage offering 
• and more... 

Beware Premature Elaboration (of Cloud Standards)

There is an ongoing discussion about the need for creating standards in the cloud computing space, including the establishment of the Cloud Computing Interoperability Forum (CCIF) of which I'm a member. 

Motivation for Creating Cloud Computing Standards

The drivers for establishing industry standards for cloud computing are quite straightforward and similar to the same drivers in other areas of IT and other industries. From a user/customer perspective standards (at least theoretically) eliminate vendor lock-in. If all cloud providers use the same provisioning API, for example, customers don't need to bet and commit themselves to a particular provider. They will be able to switch with little time, cost or effort and use any other provider's provisioning API.

From a vendor point-of-view there is also motivation for standardization. Given the customer lock-in concern, the approach many companies will take is stay on the sidelines or only dip their toes in the cloud computing waters, and not dive all-in. In other words, lack of standards is an adoption barrier.

Furthermore, the absence of interoperability across the entire cloud computing ecosystem -- not just cloud providers, but also tools that add value to them such as management and monitoring -- reduces the overall value of cloud computing.

Consider the case of the shipping container as described in the excellent book The Box: How the Shipping Container Made the World Smaller and the World Economy Bigger. Before standardized shipping containers, sending a shipment from, say, Kansas City to Tokyo was extremely expensive and ineffcient. There was no way to send the shipment in one container as a whole. Trains used containers of certain shapes and sizes, trucks used different ones and ships used different ones. In fact American ships and trains used different containers from European and Asian ones. Sometimes, even within the U.S. or Europe, different kinds of containers were used. That also meant they were extremely difficult to stack and secure, and the goods being transported had to be moved multiple times to different containers. The effect on international (or even cross-region) shipments was chilling. Furthermore, many companies in the shipping business had to maintain infrastructure and equipment to serve multiple proprietary container specs.

By standardizing on uniform container specifications, the industry removed the barriers to long-distance shipping and greatly increased the demand for it, while reducing their own costs. A boon to everyone involved.

Similarly, we can assume that if there were standards across the board for cloud computing, the uncertainty and fear of vendor lock-in would be greatly reduced and the ecosystem as a whole will become more beneficial to customers, freeing presumably pent-up demand. In Gang up now before the *aas cloud gets you, Simon Wardley makes a powerful argument for consumers to push cloud vendors towards interoperability and portability, and what he calls "open source standards" (his presentation in the link above is a must watch). 

The Case Against Standards

As almost everything else in life, standards too have a downside. Standards stifle innovation - by definition. It's true that good standards should only dictate what the product/technology needs to do, and not how. In other words, and specifically in the software world, a standard should only dictate the API sematics, and not the underlying implementation.

The problem is that in an emerging, dynamic area, such as cloud computing, the "what" is still a work in progress. We are only at the very early stages of understanding what the use cases are for cloud computing, what exact functionalty is needed by various constituencies, and what are the missing pieces. Trying to codify this highly fluid situation in a set of standards is a huge mistake.

Standards are only appropriate when an industry (or class of technology) has reached a medium level of maturity (and then standards will carry it to a high level of maturity). This is why, despite the resistance in the "cloudosphere", Gartner is probably right with their prediction that cloud computing will only reach "mainsream critical mass and commoditzation" between 2012 and 2015.

The Optimal Way to Standardize

There is another reason to avoid forcing a formal standardization process in cloud computing. It's simply not the ideal way to create a standard. There are two kinds of standards: de jure and de facto. Both phrases are from the Latin, the former meaning "by law" and the latter "by fact" --or in other words, there are official standards and standards that were not defined formally, yet have become standards in daily practice.

Formal standards are the ultimate form of "design by committee." They require compromises and involve politics and ulterior motives. They also tend to be too slow and bureaucratic. They are not the optimal way to come up with the best solution the market needs for a particular problems. The marketplace is the best tool for that (and when I say "marketplace" I also include free open source). As a particular class of technology matures, it is actually good to have a number of competing approaches and let the users vote with their feet for the one that best suits their needs.

A good example of this is what happened in Java. Although I'm sure some will argue with this analysis, essentially the Java Community Process (JCP), the official standards body of the Java platform and language was slow to adopt new programming practices and adapt to developer needs, so alternative, unofficial frameworks evolved. One of them, the Spring Framework, came out as an open source framework in 2004, and was so rapidly adopted by the community that by 2008 it was alreaddy considered by many to be a de facto standard.

Another problematic standard was WS*. Where the standards body attempted to keep up with the rapid developments in web services technology -- an impossible tasks, and ended up with numerous half-baked standards, many of which enjoyed little if any adoption in the marketplace.

The evolutionary approach to standards is even more evident in the Ruby on Rails community, which has no standards body or dominant vendor. Multiple Ruby implementations (e.g., MRI, Rubinius, JRuby), multiple frameworks (e.g., Rails, Merb, Sinatra), and multiple app servers (e.g., Mongrel, Thin, ebb) are all competing to become the de facto standard, and we will soon see which ones emerge victorious (and if it makes sense to have multiple approaches for different needs). Already there is some convergence with the merger of Rails and Merb.

In summary, the correct approach to developing standards is to first let the marketplace converge on de facto standards. A formal standards body can step in at a later stage to tie up loose ends and manage a more stable process.

The State of Standards in the Cloud

It's immportant to first make the destinction between cloud-specific standards and standards that are related but are moving on their own trajectory regardless of the developments in cloud computing. These include programming languages, operating systems, many security issues, web services and databases, to name but a few.

We then need to ask ourselves, what then, are issues unique to cloud computing that need to be addressed. The blogosphere has been abuzz lately with the discussion about exactly that. In order to understand what standards are required, we first need to understand what are the techologies that are involved in cloud computing and how they relate to each other. In other words, a taxonomy and ontology for cloud computing. In the Wisdom of Clouds, James Urquhart discusses The need for a standard cloud taxonomy. And inspired by John WIllis's Unified Ontology of Cloud Computing, Chris Hoff developed an excellent diagram of a Cloud Computing Taxonomy & Ontology. These are examples of the correct first step to standards at this point time, which is merely trying to put everyone on the same page in terms of terminology.

Reuven Cohen, who initiated the Cloud Computing Interoperability Forum writes about the need for a Semantic Cloud Abstraction , which he calls the Unified Cloud Interface, a sort of meta-API. As already mentioned, the correct approach for standards is to define the 'what' and not the 'how', so the abstraction approach is correct and I applaud Ruv for it. But as also stated, it is way too early in the game to get into this level of detail.  Patrick Kerpan of CohesiveFT expresses a similar sentiment in his blog post Cloud Interop Caution.

Sales people are taught not to fall into the trap of "premature elaboration" when it comes to product feature pitches. "First, ask questions and listen" is the good sales person's rule. I think the same applies when it comes to standards.