Thinking Out Cloud

Cloud Computing as Commodity

My partner in crime on the Overcast podcast, James Urquhart, published a nice blog post today titled: Cloud computing and 'commodity'. Read the post and come back. I'll wait.

Done? OK.

James seems to be responding to what is apparently some kind of controversy, which I don't understand because there is truly nothing new under the sun. Read Clayton Christensen's 300-page book Seeing What's Next and come back. I'll wait.

Done? Good.

All products are in a constant commoditization process always, or a "race to the bottom" as James refers to it. Period. Therefore, in order to maintain differentiation smart vendors continuously innovate and add additional features and "crust" capabilities, which over time will themselves be commoditized. Rinse and repeat. Therefore, in economic theory, all industries are destined to become commodity industries (known as the Industry Lifecycle).

Let's see how this plays out in cloud computing (intentionally simplified greatly to make a point):

• Amazon is first mover with server and storage API provisioning on-demand and pay-per-use pricing
• Everyone and their brother offers the same at similar prices
• Some differentiation in API capabilities is created (could be richness, coverage of corner cases, ease-of-use, features such as auto-scaling, etc.)
• A formal API standard emerges and everyone again offers exactly the same
• Rackspace differentiates with better SLAs (Rackspace: The Avis of Cloud Computing?)
• Everyone matches their SLAs
• VMWare and Microsoft start offering higher-level components moving towards a platform-as-a-service
• Salesforce.com differentiates its PaaS by building a large ecosystem around its platform
• Amazon acquires several start-ups and offers the same...

You get the point.

At some point the market reaches an equilibrium. Meaning that there is no longer room to innovate in that particular product category -- because customers are no longer interested in better, faster, more options, etc. We are many-many years away from that happening in cloud computing in general, although not so far away in the sub-category of infrastructure-as-a-service.

To demonstrate that there is nothing new here, take a look at the Java application server market. In the late-nineties, the product category was created by a small company called Weblogic. Two other competitors emerged: NetDynamics and Kiva. Initially, they each had wildly different capabilities and features, but over time they converged to what the market needed. Then all three were acquired at about the same time (Weblogic by BEA, NetDynamics by Sun and Kiva by Netscape). The two latter acquirers screwed things up and BEA emerged victorious, only to face a new competitor in the form of IBM with WebSphere.

At some point the J2EE standard was introduced and both large players -- IBM and BEA -- complied with it, as well as many other smaller ones. Given that they were all working on the same standard, each of the vendors started adding features that were outside the standard. Many of these features were not needed by customers and so did not really create any differentiation. This opened the perfect opportunity for a low-cost commodity player to come in: Enter Apache Tomcat. The rest is history. There is barely any commercial J2EE app server market anymore (the majority of the revenues are related to services and support, not new licenses). It took about 10 years, maybe 12.

The same process occurred with relational databases and the SQL standard (enter MySQL) and many other product categories.

Here's an even more extreme example from the shipping business as I wrote it in the blog post Beware of Premature Elaboration (of Cloud Standards): 

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 inefficient. 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.

What I didn't mention in that blog post is that those differences in containers were not (always) accidental. They were intentional because the design, material, size, shape of the container was considered a competitive advantage.

Interestingly, today shipping companies freely use each other's containers as they move them around. In fact, there is one big pool of boxes and it doesn't matter who's box you use.

Going back to a different kind of "box" -- the virtual server -- one can easily imagine how one cloud provider, if it requires additional capacity, will use another provider's boxes. And it won't matter one bit because the real value will be in the management and monitoring capabilities and other ancillary services, the internal operational efficiencies of the provider, the SLAs, the level of customer service, the brand and the ecosystem around that provider's offerings.

Also see my Purpose-Driven Cloud series for other differentiators. 

If you want to learn more about these basic industry dynamics, read any of Michael Porter's books that discuss his Five Forces model. Go ahead, I'll wait.

Rackspace Kicks-Ass in 2009

Just a day after I post Rackspace: The Avis of Cloud Computing?, the company (NYSE:RAX) announced its 2009 results, and boy did they kill it. Net revenues grew 18.4% year-over-year and EBITDA rose 33.4% from 2008.

Especially interesting was the success in the cloud computing side of the house (the rest is traditional managed hosting). Here's an excerpt from MySanAntonio.com (Rackspace is based San Antonio, TX):

Cloud computing now accounts for roughly 9 percent of the company's total revenue, but that's expected to grow to about 14 percent this year, according to Tier 1 Research. By 2012, Tier 1 Research estimates Rackspace's cloud computing business will generate $272 million in revenue.

Also interesting was the following statement from CEO Lanham Napier:

“In 2009, given the extreme uncertainty in the economy, we were focused on cash and margins, and we proved we could flex our model, which helped us separate ourselves from the pack and emerge as a stronger competitor,” Napier said. “In 2010, we will shift our primary focus to growth.”

So as I said in my previous post, I continue to expect them to do well.

Rackspace: The Avis of Cloud Computing?

In 1962, Avis, the second largest car rental company in the United States, adopted a new marketing slogan to compete against market leader Hertz: "We're #2. We try harder!" It was a bold move by new CEO Robert Townsend, and it paid-off. According to the Avis blog, the company had become profitable after thirteen years of losses and by 1966 had grown its market share from 10% to 35%. This marketing campaign has since become the stuff of legends in advertising circles.

Back at Interop/Cloud Connect 2009, I went one evening to dinner with Lew Moorman (@lewmoorman) and John Engates of Rackspace. Naturally, one of the topics that came up was how Rackspace can better compete with market leader Amazon.

Rackspace is in essence the #2 in the cloud computing business (well, at least when it comes to infrastructure-as-a-service). Guy Rosen, who writes the Jack-of-All-Clouds blog, publishes a monthly State of the Cloud blog post in which he tracks the usage of leading cloud providers among the 500,000 leading web sites. It gives a good sense of how these companies are faring.

It's a pretty tight race between Amazon and Rackspace -- with Rackspace having about 87.5% of the number of sites that Amazon does. But back when I met the two Rackspace execs in Las Vegas last year, their cloud business was at an early stage and they had recently made their first acquisitions in the space (Slicehost and JungleDisk). They hadn't even published their open API for what was then called Mosso (later renamed as Rackspace Cloud).

By November 2009 Amazon leaped ahead in Guy's State of the Cloud metrics with 2,249 sites versus Rackspace's 1,665. In other words, Rackspace had only 74% of the number of sites Amazon did.

Maturing the Cloud 

So how did Rackspace close the gap? And why do I think it will continue to do really well?

There are a few reasons. For the most part, the industry is maturing and that it is by no means  a one-company game. So bloggers, analysts and journalists are more frequently mentioning the #2 player in the arena when they want to quickly give an example of a cloud provider.

More importantly, as larger customers are considering moving more (and more important) projects to the cloud, they are conducting serious comparison shopping with less emphasis on "coolness" and ease-of-use and more on reliability.

When they perform this comparison, the SLA comparison table below is what they'll see. This table was prepared by Josh Beil (@joshbeil) and published on Web Host Industry Review. As you can easily see, Rackspace Cloud Servers offers superior uptime guarantees and credits. Josh gives a more detailed analysis for those interested.

	Rackspace – Cloud Servers	Amazon – EC2
Uptime / Availability Guarantee	100%	99.95%
Time span	Current period	“service year” or the preceding 365 days
Time-to-resolution	1 hour	Not specified
Credits	·         5% of the fees for each 30 minutes of network or data center downtime, up to 100% of the fees ·         5% of the fees for each additional hour of downtime past time-to-resolve, up to 100% of the fees	10% of bill per eligible credit period
Notification onus	Customer	Customer
Window	30 days after incident	30 days after incident
	Rackspace – Cloud Files	Amazon – S3
Availability	99.9%	99.9%
Definition	(i) The Rackspace Cloud network is down, or (ii) the Cloud Files service returns a server error response to a valid user request during two or more consecutive 90 second intervals, or (iii) the Content Delivery Network fails to deliver an average download time for a 1-byte reference document of 0.3 seconds or less, as measured by The Rackspace Cloud's third party measuring service.	“Error Rate” means: (i) the total number of internal server errors returned by Amazon S3 as error status “InternalError” or “ServiceUnavailable” divided by (ii) the total number of requests during that five minute period. We will calculate the Error Rate for each Amazon S3 account as a percentage for each five minute period in the monthly billing cycle.
Credits	99.89% - 99.5% 10% 99.49% - 99.0% 25% 98.99% - 98.0% 40% 97.99% - 97.5% 55% 97.49% - 97.0% 70% 96.99% - 96.5% 85% Less than 96.5% 100%	99 % - 99.9% 10% Less than  99% 25%

Add to this the fact that Rackspace has much more robust customer support ("fanatical support" to quote their famous slogan), and a much better sales/legal infrastructure to deal with larger customers, and you cannot avoid the conclusion that they have a great future in store not just for getting a large market share in terms of numbers of customers, but also attracting enterprise customers (i.e., their market share in dollars will be even higher).

Given that Amazon is a consumer company and Rackspace is a B2B company, it's no surprise that they are each taking a different angle and playing on their strength. While Rackspace focuses on SLA and support, Amazon focuses on ease-of-use, low-touch self-service and low prices.

Finally, one more factor will play an important role in the success of each of the cloud providers, and that is the ecosystems that evolves around their products. That means management, automation and monitoring tools (e.g., RightScale, CloudKick, enStratus), Machine Image support (such as the AMIs from Red Hat/Jboss on EC2) and other ancillary products and services that form a "whole product". Amazon has the lead here as of now, but Rackspace seems to be working hard to catch up.

So perhaps, for now, Rackspace can adopt the Avis slogan: We Try Harder.

Cloud as Monetization Strategy for Open Source: SpringSource

I came across an interesting post by Savio Rodrigues from IBM. Savio writes about the recent announcement by SpringSource (now a division of VMWare) that they are proposing to move their dm Server product (the OSGi app server) to the Eclipse Public License (EPL). Until now the dm Server was offered with a dual-license model: free in GPL or with a proprietary license for a fee, also known as the "open core" model.

Rodrigues refers to a blog post by The 451 Group analyst Matthew Aslett in which he says that SpringSource is abandoning the GPL license (and therefore the dual license model), because the EPL is more permissive and therefore encourages adoption. Rodrigues then brings up the possibility that the change in licensing is due to a change in business model -- generating revenues for sale of support subscriptions instead of license sales.

But he pretty much ends up dismissing that as the main motivator and then truly hits the nail on the head: the real plan is to monetize this and other SpringSource products with cloud computing offering (presumably some kind of PaaS) -- as this was the original rationale given for the SpringSource acquisition by VMware.

Rodrigues writes:

When VMware announced the SpringSource acquisition, delivering and monetizing a cloud platform was a key component of their vision.  It doesn’t take a crystal ball to see that VMware is attempting to drive dm Server adoption through the Eclipse Foundation and monetize the adoption when operations team want to deploy dm Server applications on Cloud infrastructure.

The monetization of open source software through cloud is something I've talked and written about before. And we can expect to see a lot more of it. Oh wait, we already are.

Software Delivery Models in the Era of Cloud Computing

  One of the trends I'm seeing lately with start-ups I work with and in general is the idea of multiple models of software delivery. As the name suggests, the delivery model is the way in which software is delivered to the user. Here's a fairly comprehensive list of the range of delivery options:

• Sell CDs for installation on premise (yes, companies still do that - especially gaming)
• Make software available for download for installation on premise
• Make software available on-premise via a physical appliance
• Make software available for on-premise via a virtual appliance
• Make software available for installation as an internal cloud
• Make images available for installation in an external cloud
• Offer software in a dedicated hosting environment (sometimes referred to as Virtual Private Cloud)
• Offer software-as-a-service via a client application
• Offer software-as-a-service via a browser-based GUI
• Offer software-as-a-service via an API

Increasingly, software companies are facing a dilemma as to the best delivery model for their business and many are opting for a "multi-delivery" model or multi-modal software delivery. A typical scenario is the vendor will offer the software both for installation on-premise and as an on-demand service. Wordpress and Atlassian were early pioneers of this approach, with the latter offering products such as JIRA, Confluence and Crucible for both download and as a hosted solution. And on the big vendor front, Microsoft is pursuing a Software+Services strategy.

Another common approach is offering the software for installation on-premise and as an Amazon Machine Image (AMI), and often with a corresponding pay-per-use pricing model. GigaSpaces is one company pursuing such a strategy, as are larger vendors such as Red Hat.

Vendor Considerations for a Software Delivery Model

As we continue to figure out the bold new world of marketing cloud computing, the delivery model is a key question. The answer varies by the vendor's analysis of the future of their product category, particular situation of the vendor, the nature of the product and marketplace conditions.

Here's a closer look at these considerations with some accompanying examples.

Marketplace Considerations for Software Delivery Models

The first question to ask is: Do we believe that in our market the cloud delivery model will eventually become mainstream? If so, within what time frame will it hit critical mass? And what are our own adoption and revenue expectations (and constraints) for that time frame?

The definition of critical mass is subjective. Let's look at the problem from the perspective of large incumbent vendors, ISVs with existing on-premise business models and new entrants, i.e., startups.

Large Incumbents

Incumbents, whose current business model is based on generating revenues from an existing on-premise delivery model (whether upfront or subscription pricing), face a classic innovator's dilemma. Although they may believe that eventually the market will move to a cloud model, it may be years before the adoption level will be such that it will significantly impact revenues. However, if the market is going in that direction in what time frame and at what level should the company invest in the new model? If the company underestimates the speed in which the cloud market will develop, it may suffer losing ground to young upstarts (as was the case between Siebel and Salesforce.com in the CRM market).

But incumbents face significant resistance in moving to a new model because of potential conflict with existing revenue sources. There might be pushback from the sales force, whose livelihood depends on commissions from large upfront license sales. There may be issues of revenue recognition, which favors upfront, and even subscription models, over pay-per-use pricing. They may face shareholder and analyst expectations for revenue and profit growth that conflict with the new model.

Given that it is very difficult to predict the odds and the rate of new technology adoption, companies need to assess the risks of making each move.

With incumbents, we have seen different approaches that suit their markets and their situation. Oracle, on one extreme, has famously derided cloud computing and made little investment in that area as compared to other large vendors. This makes perfect sense. First, it is in Oracle's interest to maintain the status quo given its extremely profitable business model in which all the risk lies with its customers. Second, as Oracle sells mainly infrastructure and applications to large enterprises, and makes most of its revenues from recurring support and maintenance fees on existing installations, that cash cow is not going to run out of milk any time soon. Third, if any newcomers grow large enough to take a piece of Oracle's pie, they can always buy them, as they have done repeatedly and aggressively. MySQL anyone?

Microsoft, as already noted, has taken a different tack, much more conciliatory toward the cloud with a hybrid approach. This is because many of their revenues are actually from consumers and small-medium businesses as well as developers, all of whom are moving to the cloud more rapidly in certain areas. This is a threat across many of their cash cows, including Exchange, Office, SharePoint and the many .Net and infrastructure components. The level of aggressiveness in which Microsoft is moving these different products to a cloud delivery model seems to correspond well with how important these products are as current cash generators and how rapidly they think the movement to cloud will be in these various categories. So note the slow movement on Office Live, and the rapid movement on infrastructure with Azure, Exchange Online and SharePoint Online.

On-Premise ISVs

Small and medium ISVs, who already have ongoing business with on-premise software, may face the toughest choices, depending on how much cash they have on-hand and their current rate of growth. If, on the one hand, they have little breathing room and the ability to make significant investments in an on-demand delivery model, and on the other hand, their market is rapidly moving in the direction of such a delivery model, prospects are bleak. So they need to either raise the additional funds to make the necessary investments, or entertain the idea of an acquisition, even if conditions do not seem ideal, as this may be the peak of their value.

Failing to act quickly will result in the decline of growth and loss of business to startups free of the baggage associated with an existing on-premise model.

If the necessary investment is made, ISVs need to be fairly aggressive in transitioning their revenue model from on-premise to the cloud.

Startups

Most startups don't face potential conflicts with an existing business model, but they too must take the time horizon of adoption into account. They will require different levels of industry adoption if the plan for success (however that's defined by management and the investors) calls for $6 million in Year 3 revenues as opposed to $20 million in that same year, for example. It also depends on the amount of money the company has raised (i.e., how much breathing room does it have), and the appetite the investors and management have for risk and the potential need for additional investments.

As a case in point, take a look at two companies in the same Application Performance Management (APM) product category: New Relic and AppDynamics. Both companies were founded by ex-Wily Technology executives (acquired by CA), and both seem to have set out to disrupt their own previous creation and update APM for the new, cloudy world.

There are many differences between the two products, but for the purpose of this post, the key is in the delivery model. At least for now, New Relic chose a pure cloud delivery model (SaaS) and AppDynamics opted for an on-premise delivery model (software needs to be downloaded and installed).

Clearly, the management teams of these two companies have very different views on the future of the market, or at the very least, on the rate of adoption of the cloud delivery model. It will be interesting to see how things play out between these two.

Interestingly, New Relic started with the Ruby-on-Rails market, which as I have written before, tends to be an early adopter of cloud computing. New Relic has recently ventured into the Java market. AppDynamics started with targeting the Java and .Net markets, both representing much larger, and consequently, more conservative markets. So far it seems that New Relic's bet is paying off, but admittedly they released their product earlier than AppDynamics.

Operational Considerations for Software Delivery Models

The pure cloud delivery model is very compelling from a software development and operational point-of-view. The company that delivers its software as a service (via a browser or an API) only needs to support a single code base, and can perform a lot of "magic" (such as auto-scaling) thanks to the tight integration between the software and the infrastructure, which it has selected and fully controls.

In contrast, the software company that sells on-premise products usually needs to support a wide range of environments and platforms including hardware, VMs, operating systems, databases, application servers -- and multiple versions of each at any given time. This multi-environment support is not only costly, it is prone to problems. It also slows down innovation, because each release of a new feature or version needs to be developed for and tested on multiple platforms and combinations of platforms.

An on-premise company could limit itself to a narrow range of supported platforms, or even to a single "stack" -- and all software companies do in fact limit themselves in some way. But by doing so they are forgoing a certain portion of the market. They face a difficult trade-off of a small addressable market versus an unwieldy product.

The cloud delivery model, however, is not free of its own unique challenges. The most notable challenge being that the company has to run the service itself. This means dealing with a whole set of considerations -- at the IT operations level -- that on-premise software companies do not have to deal with, such as building a multi-tenant system that can scale, is reliable, secure and continuously runs at acceptable performance to customers with a wide range of requirements. In short, the company that delivers software-as-a-service, needs to deal with the infrastructure -- and that's no trivial task.

Thankfully, cloud computing itself alleviates some of this challenge. The whole point of cloud computing, and specifically infrastructure-as-a-service as envisioned and implemented by Amazon, was to reduce much of the complexity of managing the infrastructure (not to mention eliminating the need to procure and configure it). So it's no surprise that companies such as Heroku and Twilio actually run their own platforms-as-a-service on Amazon's IaaS (but transparent to their own customers). A little "cloud-on-cloud action", if you will.

In essence, they are outsourcing -- or should I say cloudsourcing -- the infrastructure. To be fair, this does not completely eliminate the need to deal with complex operational issues, but it certainly reduces much of the challenge and as mentioned above, even creates opportunities for competitive advantage.

An interesting case study is Engine Yard. The company, which like Heroku, offers a Rails PaaS, initially ran its own dedicated infrastructure, which it (and its investors) heavily invested in. When Engine Yard started its business, Amazon Web Services and cloud computing in general had not quite reached the level of popularity -- and hype -- that they have now. But that quickly changed. In addition, Heroku had launched its own EC2-based service, and presumably Engine Yard needed to respond to market conditions, as well as what one can only assume, the internal operational pressures it was feeling from running its own infrastructure. 

In January 2009, the company launched Engine Yard Solo, which offers the EY RoR stack running on a single Amazon EC2 instance. Several months later, the company launched Engine Yard Flex, which also runs on AWS, but allows running an application on more than one EC2 instance. Today, after a bit of name-changing and repositioning, the company offers Engine Yard Cloud, which is essentially what was previously named Flex and runs on EC2, and Private Cloud, the old EY dedicated infrastructure, clearly aimed at larger customers with a Fractional Cluster (slice) option that starts at $4,000 per month and Dedicated Cluster option which starts at $20,000 per month.

Business Model Considerations for Delivery Models

In theory, both pure on-premise and pure cloud delivery models should be able to pursue any business model; in practice, they can't. Let's break-down "business model" into some of its components and take a closer look.

Pricing Model

There are three basic pricing models: upfront perpetual license, subscriptions and pay-per-use. The latter -- pay-as-you-go or utility pricing -- is the model that most aligns the interests of the vendor with those of the customer. The upfront license model actually puts the interests of the two parties at odds. It is for that reason that I -- and many others -- believe that the software industry is moving towards pay-per-use across the board.

Although not impossible, a pay-per-use model is very difficult to implement with on-premise software. It would require some kind of metering technology which would have to "call home" with billing information. Not completely unheard of in the software industry, but something that significantly complicates things. 

Software-as-a-Service, on the other hand, can easily implement a pay-per-use model (as well as the other two models). So I believe that over time they will be increasingly exposed to competitive pressures on the pricing model, putting them at a serious disadvantage.

Using New Relic pricing as an example, they provide on-demand pricing based on hourly usage, a monthly or annual subscription based on number of hosts, as well as an all-you-can-eat package (essentially, an upfront license) for their enterprise customers. AppDynamics will be hard-pressed to match this flexibility.

Another great example for the power of pricing with an on-demand service is Heroku. Besides the fact that their pricing page is beautifully designed, it demonstrates the flexibility of platform-as-a-service pricing -- and perhaps more importantly -- how easily one can add and remove premium features and scale the application.

Customer Acquisition

The software industry, including in the enterprise, is rapidly moving away from the top-down sales approach to customer acquisition via a bottom-up adoption model. A successful bottom-up adoption strategy is all about streamlining the on-boarding process and removing any barriers so that individuals can try and buy the software (or service) with very little need for approvals, budgets and resources. Clearly, a software-as-a-service delivery model helps in removing many of these barriers.

If the organization relies on large top-down sales, and is convinced that is the right model for it to thrive, then it actually wants to construct some barriers for bottom-up adoption, in order to force a top-down decision at some point. An on-premise delivery model would be the clear choice in such a case.

Multi-Modal Software Delivery

As mentioned in the beginning, many software companies are choosing -- for a variety of reasons -- not to make the decision of software delivery model a mutually exclusive one, but rather use multiple delivery models. Among the big vendors, Microsoft is the most outspoken on the topic, trying to balance its current cash cows with the increasing competition from Google and other cloud and SaaS providers.

But what's been interesting to me is what startups have been up to. The trend is particularly noticeable among open source companies, which is part of the reason why following a podcast with James Urquhart and I, Matt Asay asked if cloud computing is a natural conclusion of open source.

One of the companies I have been consulting on strategy and marketing for, Sauce Labs, is the classic example of this trend. Sauce Labs was founded to be the commercial company behind the popular open source testing framework Selenium. It pursues both the classic "open core" model of providing commercial support for and premium editions of the open source versions of Selenium via a subscription pricing model, as well as providing a cloud service, what they call Sauce OnDemand, which enables testing with Selenium using a software-as-a-service model.

I believe we will see this trend growing, as it provides open source companies (and software companies in general) a much better fit for the bottom-up adoption model, allows for a much more scalable, higher margin business -- and aligns perfectly with the customer's needs and interests (the onerous of reliable software is on the vendor, not the customer). 

As always, a new approach also brings new challenges, and in a sense, pursuing a multi-modal delivery model suffers from the downsides of both approaches -- have to run service operations AND maintaining multiple versions of on-premise software.

What are your thoughts on delivery models? If you're a vendor, have you had this dilemma and are there other considerations -- for or against -- which I left out? If you're a customer, what would you like to see vendors do?

Any other thoughts or examples? Please leave them in the comments below.

Behind the Smokescreen

As some of you may know, Dreamforce, Salesforce.com's big conference, is going on this week in San Francisco. This morning I received an amusing email from Chris Harrick, VP marketing at SugarCRM. I'm assuming this was sent out to everyone who signed up as press to the event.

Funny stuff.

The full email is below (I added the link to Benioff's book). In any case, I'll see you at Dreamforce!

Hey Geva,

Marc Benioff has a few zingers for SugarCRM in his new book Behind the Cloud:

“We knew that we had truly emerged as the market leader in the eyes of the industry when we arrived at Dreamforce 2006 to find that a handful of employees from a small CRM company had set up a mock protest outside the convention center. I’m not really sure what they were protesting, and it was a small, low-budget, and poorly executed rip-off of the types of tactics we had invented, but that wasn’t the point. The point was that we knew not to get ruffled.”  

                                                                        - Page 65 of “Behind the Cloud”

We are sorry we disappointed Marc during our previous visit to Dreamforce.

He even challenged us to “step up the innovation”:

“We did not want this company to get free PR on our coattails! Ignoring this escapade worked well. A blogger asked a Dreamforce attendee if she had seen what was going on outside when she arrived, and she replied that it must have been some kind of Salesforce.com stunt. (Note: if you are going to compete with someone at his or her own game, always remember to step up the innovatio

            - Page 65 of “Behind the Cloud” by Marc Benioff

If you insist Marc.

In continuing its long love affair with the industry’s most down-to-earth CEO and our commitment to staging “small, low-budget, and poorly executed rip-off [tactics]”, SugarCRM is currently distributing 1,000 copies of “Behind the Smokescreen: The Untold Story of How Salesforce.com Still Manages to Sell 1999 technology 10 years later” at Dreamforce today.

You can get your hard copy on the sidewalks outside Moscone (look for the people dressed as big books;).

Or you can read the eBook here: www.sugarcrm.com/smokescreen

With an endorsement from North Korean leader Kim Jong II (“A great guide for any entrepreneur, CEO, or Head of State looking to promote openness and freedom”), Behind the Smokescreen is a response to the magical Salesforce.com marketing that has transformed the company’s service from .com ASP to On-Demand SaaS to Cloud Computing without being apple to run its service on Amazon EC2 ,Microsoft Azure or other cloud services.

To celebrate the release of the book, SugarCRM is offering a free data migration for Salesforce.com users through the end of the year. Registrants will have a chance to win a free Motorola Droid.

SugarCRM hopes that the publication of this book “step[s] up the innovation”.

Please contact us if you would like more details. (510) 501-7333

Regards,

The Sugar Team

“There is a Japanese belief that business is temporal, whereas relationships are eternal. That’s true, One day you compete. The next day you partner. One day someone is your subordinate; the next day he or she may be your superior. At its finest, business is friendly competition, just like a game of tennis.”

                                                                                                       -  Page 39 of “Behind the Cloud”

And I grabbed this picture from the CRMOutsiders blog:

The Purpose-Driven Cloud: Part 1 - Usability

As I explained in the previous post The Purpose-Driven Cloud: Introduction, this is the first in a series of blog posts on the different cloud platform offerings available today and how they focus on different dimensions to serve different purposes. This post discusses --

The Usability-Driven Cloud

Usability-driven clouds are a concept similar to the idea of programming language generations. Lower-level generations give the developer complete access to the computing infrastructure, but are extremely complex as the developer is required to build every aspect of the application from scratch. Higher-level generations are much easier and intuitive to use by humans, and come built-in with many common tasks and functions. But this usability comes with a price: the developer cannot access the underlying resources, or "plumbing", at a fine-grained level.

In programming languages, 1GL (1st generation language) would be machine language, 2GL is Assembler, 3GL are high-level languages such as C and Java, 4GL are mostly niche programming languages designed for specific business purposes (such as scientific analysis) and 5GL are visual programming tools (think "drag & drop"), which in their original vision were intended to allow non-programmers create software applications. For the most part, 4GL and 5GL never became mainstream (although the corpses of many attempts lay on the wayside of Silicon Valley roads).

We're seeing similar "usability generations" evolve in cloud computing. However, they come in two main flavors: deployment usability and programming usability.

Deployment Usability -- Platforms of higher deployment usability generations focus on easing and abstracting the process of deploying and configuring the application, not necessarily on writing the code for it. In modern development, this is as big an aspect of application development, if not bigger, than actual programming. See James Lindenbaum's Why Instant Deployment Matters for more on this topic on the Heroku blog.

At the moment, all of the IaaS players can be generally categorized as lower generation deployment platforms. This includes Amazon EC2, Rackspace, Terremark, GoGrid, etc.

PaaS offerings such as Heroku are a higher level generation deployment platform and eliminate the vast majority of infrastructure setup and configuration required to get an app running (hence James's use of the term "instant deployment").

I further discuss Heroku's role as an application platform in Ruby Developers: The Cloud Generation.

Programming Usability -- This dimension is similar to classic programming language generations. So while Heroku is high-level in terms of deployment, it is relatively low level (in modern day terminology) in terms of programming. You have to develop your apps in straight Ruby (which in classic terms would be a 3GL). This is the same generation programming language you would use on an AWS or Rackspace (on either of which you can use pretty much any 3GL language - e.g., Java and C++ - but more on that later).

But although 4GL and 5GL languages failed to become mainstream, we are seeing a revival of them in the cloud. A few examples of such platforms, which generally enable non-programmers to develop apps, include Intuit's Quickbase, WorkXpress (who in a conversation with me explicitly called themselves 5GL PaaS) and even Salesforce.com.

Note that I am not referring here to the Salesforce.com CRM SaaS application, which is a packaged app; nor am I referring to the company Salesforce.com Inc.'s PaaS offering Force.com (which is a high-level deployment platform but low-level programming platform). I am referring to the fact that a business user can quite easily create a custom app using Salesforce.com by creating new objects, fields, tabs, workflows, etc. without any programming skills.

Another thing to keep in mind is that high-level programming clouds will invariably be high-level deployment clouds, as they appeal to non-programmers.

Finally, it's important to emphasize that a higher generation platform in either usability dimension -- programming or deployment -- is not necessarily better or worse than a lower generation platform. It depends on what you are trying to achieve and the skills and resources available.

If the purpose is to develop a unique app that requires a high degree of optimization, a lower generation platform is better. If the task at hand involves building an app that uses typical services and functionality, and a general-purpose infrastructure will serve it well, then a high-generation platform is in order. It's a trade-off.

In the next installment in the series I'll be discussing The Framework-Specific Cloud.

Stay tuned.

The Purpose-Driven Cloud: Introduction

Nearly a year ago I posted Thoughts on Platform-as-a-Service, in which I reviewed the state of cloud platforms at the time. A lot has happened since then, and it's time to revisit the latest and greatest in PaaS and specialized cloud platforms.

I've been asked several times by companies I advise or just talk to, as well as by journalists, how should companies select a cloud provider? The answer is, as it almost always is, "it depends." Similarly to what we had already seen in programming languages and traditional application platforms (i.e., installed on-premise), different platforms have been designed to serve different purposes.

I am planning on publishing a series of posts with the general title of "The Purpose-Driven Cloud", which cover the different dimensions that differentiate cloud platforms and make them more suitable for different purposes.

The dimensions I am going to cover are:

• Usability-Driven Clouds [UPDATE: Post is live here]
• Framework-Based Clouds [UPDATE: Post is live here]
• Domain-Specific Clouds [UPDATE: Post is live here]
• Data-Driven Clouds
• Industry-Focused Clouds
• Geographically-Centric Clouds

Simultaneous to this intro, I am publishing the first in the series: The Usability-Driven Cloud.

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 China, 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.

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.