Thinking Out Cloud

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.

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.

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.

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.

Thoughts on Platform-as-a-Service

The recent news about layoffs at Bungee Labs has triggered a discussion about the viability of the Platform-as-a-Service concept. In this post I attempt to map the PaaS landscape and discuss possible strategies and approaches for the platform vendors. But first, to understand PaaS, we need to look at where it fits in the larger picture. PaaS is one of what I view as the three pillars of cloud computing:

1. Software-as-a-Service: Although the term "software" denotes any piece of software, the term SaaS is usually applied to the idea of delivering a complete software application to its end users over the Web, and typically with a subscription or per-usage pricing model. Examples include Zoho and Salesforce.com.
2. Infrastructure-as-a-Service: IaaS is about providing basic IT resources, such as compute power, memory and storage, over a network (typically the Internet) and usually with a subscription or per-usage pricing model. Examples include Amazon Web Services, GoGrid and Flexiscale.
3. Platform-as-a-Service: The term PaaS is often confused as it is actually used to refer to to two distinct elements:
   
   1. Web-based development tools (aka IDE). This could more accurately be refered to as Tools-as-a-Service (TaaS).
   2. A run-time application platform that enables running applications in the cloud, typically on top of an IaaS and delivered as SaaS.

 The two types of PaaS are sometimes confused because vendors often offer them combined as a single solution. Things are further confused because they often include a third, separate, component: that of a development framework or programming model (what is commonly referred to as the API).

To understand this better, let's compare to the more familiar and established world of Java. Building and running a standard Java app requires three main elements: the API (the Java programming language itself), a run-time platform (the Java Virtual Machine, or JVM -- or more accurately, the Java Run-time Environment, or JRE) and development tools (popular IDEs such as Eclipse and IntelliJ). Note that the three are separate from each other. A developer can choose which IDE and which JVM implementation (from IBM, Oracle, Sun or others). Also taking advantage of the Java Run-Time Environment does not require the Java programming language. One can use other interfaces such as JavaScript, Groovy and JRuby.

 The same principles apply to the Java Enterprise Edition (JEE). A developer can choose from a number of application server implementations (the run-time), IDEs and APIs (e.g., Spring Framework or EJB).

 

Armed with this understanding, let's look at Bungee Labs again. They made some crucial decisions with their product, BungeeConnect, which significantly impact the adoption of the product. the first was that they provide all of the elements: the development tools (a web-based IDE), the run-time platform (they may be leveraging other platforms underneath but it is transparent to the user), the hosting (i.e., IaaS) and the API (they offer a proprietary C-like API).

 
Second, they decided that you cannot separate the four elements from one another. They are tightly-coupled. You cannot use their tools without also adopting their API, run-time platform and hosting service. If you like their tools, and want to use them with other run-time platforms, APIs or cloud providers (hosting), too bad.

Third, they didn't leverage standards. Although their programming language syntax is C-like, so it is at least familiar to many developers, it will not execute on other run-time platforms as-is.

The adoption barriers created by Bungee's self-imposed limitations are becoming evident. A developer or company contemplating the use of BungeeConnect are forced to make a strategic, long-term decision about the future of their business: to be locked-in to Bungee's product in almost all aspects of their own product.

 

I don't mean to pick on Bungee. As a fellow entrepreneur, I sympathize. I can also understand the considerations they had when making these choices. For one, the notion of creating a "total solution" seems appealing at first. And from a practical perspective, it is easier to create a more powerful solution when you restrict and control the environment it operates in. Besides, they were being ambitious, and I respect that.

 

Let's look at some alternative approaches that Bungee could have taken (and still can), as well as what other players have been doing.

Go-To-Market Strategy

Generally speaking, achieving adoption for a new platform is a difficult task. It is true that the advent of cloud computing creates an opportunity for new players, but major challenges remain. There seem to be four main approaches to doing this:

• Brute Force: the very biggest vendors have the marketing muster, credibility and resources to make it happen by "brute force." An example of such an approach would be Google App Engine. Google has taken the exact same approach as Bungee -- they provide all four elements -- but they obviously have the market visibility and budgets to achieve fast adoption.
• Open Source: It means two things: first, pricing adoption barriers are removed (i.e., offer it for free and develop premium products and services later). Second, the product source code is available, allowing end users to customize it and the comfort of having access to source if something happens to the vendor. 10gen is an example of a vendor taking this approach.
• Specialized: Focus the platform on a particular segment of the market, instead of trying to be all things to all people. The key is that you have to build a "total solution" for that particular segment. This is reminiscent of Geoffrey Moore's Crossing the Chasm model. Ning is a good example, as it's a platform focused exclusively on building social networking applications. Other forms of specialized platforms could focus on a particular industry or type of application.
• Ride the Coattails:This strategy involves building a platform that allows developers to leverage an existing install base. The Facebook Platform is a good example. Given that today many applications expose their APIs to the general public, vendors other than the 'owner' of the install base can take this strategy.

Target User

Another dimension PaaS vendors should think about is who is the target user of the platform. The typical choices are programmers versus so-called business users (non-programmers). Bungee, Google App Engine and 10gen are all clearly targeting programmers. Ning, on the other hand, allows people without any code-writing skills to quickly create their own social network. They do, however, offer developers the ability to further customize their application through programming.

Totality of the Solution
As already noted, PaaS-related vendors need to decide which elements of the 'stack' they provide. Specifically, do they provide the run-time platform, the development tools, the hosting service, all of the above? And if so, do they lock users into their components or do they allow use of certain components from other vnedors? Here's a list of vendors and the choices they made:

Product	Run-Time	Tools	IaaS	API	Primary Target Users	App Focus
BungeeConnect	Yes	Proprietary web-based IDE	Yes	Yes. Proprietary	Developers	Free form
AppJet	Yes	Proprietary web-based IDE	Yes	Semi-proprietary, JavaScript-based	Developers	Free form
Jboss Cloud	Yes	Stanadard, installed IDEs	No (suports EC2)	Standard (J2EE)	Developers	Free form
GigaSpaces Cloud	Yes	Standard, installed IDEs + Cloud Tools for deployment	No (supports multiple clouds, including EC2)	Standard (Java/Spring, .Net, C++, JavaScript, Groovy, JRuby, JMS, JDBC, Jcache)	Developers	Free form
Aptana Cloud	Yes, for PHP and AJAX1	Aptana's open source installed IDE (based on Eclipse)	Restricted to Aptana hosting2	Flexible IDE for a variety of APIs, including JavaScript/AJAX, PHP, Ruby, Java	Developers	Free form
Force.com	Yes	Yes	Restricted to Salesforce.com hosting	Proprietary		Database-centric
DabbleDB	Yes	Proprietary web-based tools	Restricted to DabbleDb hosting	JavaScript based on JSON schema	Business (developer customization options)	Database-centric
Zoho Creator	Yes	Proprietary web-based tools	Restricted to Zoho hosting	Proprietary	Business (developer customization options)	Database-centric
LongJump	Yes	Proprietary web-based tools	Restricted to LongJump hosting	Java, REST, SOAP	Business	Database-centric, Workflow-centric
Google App Engine	Yes	Standard, installed IDEs + SDK	Restricted to Google App Engine hosting	Python (with limitations) and additional task-specific APIs	Developers	Free form
Coghead	Yes	Proprietary, web-based tools	Restricted to Coghead hosting	Proprietary	Business	Database-centric, workflow-centric
WyaWorks	Yes	Proprietary web-based tools, and accessible via installed IDEs	Provide hosting and allow deployment on any infrastructure	JavaScript, JSP, Java	Business and Developers	Free form
Intuit Quickbase	Yes	Proprietary, web-based	Restricted to Quickbase hosting	Proprietary3 Http API, XML/XSL and a Formula Language	Business	Database-centric
10gen	Yes	Yes, but you can develop code with standard IDE	No, supports multiple clouds	Standard (JavaScript, Python, Ruby)	Developers	Free form
Rollbase	Yes	Proprietary, web based tools	restricted to Rollbase hosting	Proprietary	Business (developers cutomization options)	Database-centric
Morph Labs	Yes	Not provided by Morph	Restricted to Morph Labs hosting	Standard (Java, Ruby)	Developers	Database-centric

Notes to Table:

1. According to a comment posted by Kevin Hakman of Aptana, a Ruby-on-Rails run-time will be available soon.
2. Aptana Actually uses Joyent as the host today (although this fact is transparent to the user). The company plans to add the ability to choose other hosting providers and does not see hosting as part of its business model (see comment by Kevin Hakman below).
3. The QuickBase API is proprietary, but like others on the list, it it can be wrapped by other, standard APIs. The QuickBase user comunity has already done so for Perl, Ruby, PHP and others.

Community and Eco-System

Another important aspect for any platform, PaaS included, is the notion of an eco-system and a community that is built around it. How well the platform vendor encourages, enables, nurtures and promotes this community is of critical importance. There are a number of ways to do this:

• Classic community tools: forums, ability to share and blog, wiki documentation editable by users, etc.
  
• Allow Extension of the Platform: This can be achieved by exposing APIs and/or open sourcing the code and providing the process and tools for submitting extensions, plug-ins and add-ons, bug fixes, etc. 10gen, for example, has open sourced its platform. Many of the other players in the table above are exposing APIs and providing other ways to modify and customize the platform. At GigaSpaces, as another example, we open sourced our API -- OpenSpaces -- and created the openspaces.org community site, which lets developers share their creations.
  
• Create a marketplace around the platform: Often the PaaS vendor already garners interest and attention and can make that marketing prowess available to its own users. Many of the PaaS providers listed here allow their users to list their creations in some sort of a catalog or marketplace. Other users can sometimes clone the creation and extend it, leveraging work that has already be done. In many cases the platform vendor allows its users a way to monetize their efforts. Salesforce.com's App Exchange is a good example of this. By making its platform open and extensible, Amazon enabled a whole cottage industry to develop around its Amazon Web Services platform, with companies such as RightScale.
  
• Access to end-user data: One of the most effective (and tricky) ways to foster an eco-system around the platform is to allow building applications that can access end-user data in other applications. Now when I say "access", I mean that they have the technical ability to do so. The end user, of course, needs to approve such access. For example, when you build an application on Force.com, it can access the contact, account and deal information in the users Salesforce.com application.

If anyone thinks I misrepresented any of the solutions in the table above, or if you have any other thoughts, please comment.

25 Most Influential People in Web Hosting

This is pretty cool. Although it was published in May, I just found out that Jimmy Atkinson listed me in his 25 Most Influential People in the Web Hosting Industry over at the Web Hosting Database (WHDb) site. The list is made of three categories founders/CEOs, CTOs/Engineering and Marketing people. I'm in the latter category.

If you're wondering what I have to do with "web hosting", the connection of course is cloud computing, which is converging hosting with infrastructure software and other aspects of the industry (but more on that in an upcomg post about Platform-as-a-Service).

In any case, thanks for including me, Jimmy. It's a very distinguished list.

GigaSpaces Updates on Twitter

Those of you with Twitter accounts can now follow GigaSpaces-related updates on the GigaSpaces Twitter stream that was set up by Jim Liddle.

You can also follow me at: http://twitter.com/gevaperry