Thinking Out Cloud

Podcast on the LAMP Cloud

After another very long break, James Urquhart and I finally recorded another Overcast podcast and it's now live and you can listen to it here.

Here's a mirror post of the Overcast blog:

Listen to the podcast:

Download Show #13 in MP3 format

Show Notes:

 So after another very long break, we're back with show #13. This time our guest is Krishnan Subramanian who writes for CloudAve and can be found on Twitter as @krishnan. 

In this show we discuss the topic of the LAMP Cloud, which Geva started off in a GigaOm post, Who Will Build the LAMP Cloud?, and James responded to with Does cloud computing need LAMP?. In an indirectly related post, Krish wrote about the Relevance of Open Source in a Cloud Based World, so we invited him to join us in a conversation about the LAMP cloud: Does it make sense? Who needs it? And what's the role of open source software in the world of cloud computing?

We also talk about the adoption of Platform-as-a-Service and other topics.

Some of the companies, products and technologies mentioned in this podcast include: Amazon, Zend, Google App Engine, PHPFog, Salesforce.com, Engine Yard, Heroku and Microsoft Azure.

Follow us on Twitter: @jamesurquhart, @gevaperry

Who Will Build the LAMP Cloud? And Who Cares?

On Saturday, GigaOm published a blog post I wrote entitled Who Will Build the LAMP Cloud? Please read the full post, but I basically ask in it the title question and speculate on potential candidates and players including Google, Amazon, Microsoft, Heroku and Zend. 

But apparently there may be a more fundamental question: does anyone want a LAMP cloud? 

My rationale for asking the original question was as follows: There are platform-as-a-service plays for popular application stacks such as Java (VMForce.com and Google App Engine), .Net (Microsoft Azure) and Ruby-on-Rails (Heroku and Engine Yard), so why not the LAMP stack? After all, it is one of the most popular technology stacks on the web today.

But in the very first comment, Kiril Sheynkman questions the need for a LAMP cloud altogether, with the claim that LAMP is losing its relevance and being rapidly replaced by other components. For example, he lists MongoDB, CounchDB and Cassandra as alternatives to MySQL -- the M in LAMP.

James Urquhart picked up on this comment and posted Does cloud computing need LAMP? in which he writes:

I have to say that Kirill's sentiments resonated with me. First of all, the LA of LAMP are two elements that should be completely hidden from PaaS users, so does a developer even care if they are used anymore? (Perhaps for callouts for operating system functions, but in all earnestness, why would a cloud provider allow that?) 

Second, as he notes, the MP of LAMP were about handling the vagaries of operating code and data on systems you had to manage yourself. If there are alternatives that hide some significant percentage of the management concerns, and make it easy to get data into and out of the data store, write code to access and manipulate that data, and control how the application meets its service level agreements, is the "open sourceness" of a programming stack even that important anymore?

I agree with James that in a PaaS offering, the developer shouldn't care about the underlying infrastructure, and therefore, the L(inux) and A(pache) in the stack are less relevant. This brings me to something that may perhaps seem like a nuance, but may be important: perhaps my original question should have been: "Who is building the PHP cloud?" and not LAMP.

In fact, if you keep scrolling down in the comments to my GigaOm post, you'll see an interesting one from a fellow named Brian McConnell. Brian writes that he currently uses Google App Engine with Python. He goes on into some detail about the benefits of GAE, which are essentially the selling points of PaaS over IaaS. But he concludes with the following:

I’ll probably stick with App Engine and Python for a while since things are working well and it ain’t broke, so it don’t need fixing, but if I am required to migrate in the future, or start another project, I’d like to be able to use PHP with the same level of simplicity.

This anecdotal testimony gives some merit to the notion of a PHP-focused platform-as-a-service.

James' last question: "Is the 'open sourceness' of a programming stack even that important anymore?" is a good one, but orthogonal to the discussion about a LAMP/PHP cloud, in my mind.

Integration-as-a-Service: IBM+Cast Iron

In Integration-as-a-Service Heats Up I talked about the cloud integration space and mentioned three companies: SnapLogic, Cast Iron Systems and Boomi. Well, I guess I was right about it heating up because on May 3 IBM announced its plan to acquire Cast Iron. 

It's important to note the difference between the three companies. Among the three, Boomi is the only one that has taken a pure cloud approach and provides its product solely as a web service. Cast Iron had started as an on-premise appliance play (virtual or physical) and recently added Cloud2, which they describe as a "multi-tenant integration-as-a-service cloud offering." SnapLogic is a downloadable product that needs to be installed on-premise or deployed by the customer in a public cloud environment such as Amazon Web Services.

[For more on application delivery models see Software Delivery Models in the Era of Cloud Computing]. 

Besides writing this post to say "I told you so" :-), I wanted to call attention to the debate about the appliance versus the pure cloud service approaches. In a blog post entitled Why Integration Appliances Won't Scale for Cloud Computing, Boomi CEO Bob Moul essentially slams Cast Iron's approach (although he is very gracious about the acquisition). The title of the post pretty much says it all, but you can read the details on their blog.

To me this is part of a bigger debate that is going on, and that is the fate of the notion of internal clouds (infrastructure-as-a-service and platform-as-a-service environments that run in the company's own data center).

Several of the large vendors, such as IBM -- as well as many startups such as Eucalyptus -- are pushing the notion of internal clouds. And they are gaining some traction. From the customer perspective the idea of internal clouds resonates because they want to provide their development teams with the flexibility of public clouds such as AWS, but without the huge headaches of governance, security, migration, lock-in and other problems associated today with external public clouds.

And then of course, there is the idea of a hybrid environment -- where some aspects of IT are run in-house and others in a public cloud or as software-as-a-service, which is where an offering such as Cast Iron's comes in.

But at the end of the day, Boomi's Moul has got it right. It is a model that won't scale. "Pure" cloud will win this war. Internal clouds will be a temporary stop-gap during the next 2-3 years, but will eventually settle as a small niche.

Thoughts on VMForce and PaaS

 Back in January I wrote about how VMWare will monetize on the SpringSource acquisition via the cloud, and specifically a Java Platform-as-a-Service. Yesterday, VMWare and Salesforce.com made a big announcement about VMForce - their joint Java Platform-as-a-Service, which leverages the Force.com platform with VMWare virtualization technology and more importantly, the Spring products from VMWare's SpringSource division.

The announcement has been widely covered so I won't go over the details. I embedded the brief VMForce demo from their site.

But I have been thinking about some of the implications of the VMForce offering and announcement and wanted to share those.

• Platform-as-a-Service is coming of age: It has always been my contention that the end game for cloud computing (and by extension, all of IT) is PaaS and SaaS, and eventually, IaaS will remain a niche business. This move by two major vendors, such as Salesforce (who already had a generic PaaS in Force.com) and VMWare (with both its virtualization technology and SpringSource is a major step towards that end game with the creation of a mainstream, enterprise-grade (?) Java platform.
   
• Developers are the name of the game and will continue to grow in influence. There is an ongoing debate on the roles of operations and development in this brave new world. If PaaS indeed becomes mainstream in the enterprise, there is no doubt that the need for ops personnel in the enterprise is reduced. Some of those jobs will shift to the cloud providers, but some will be entirely and forever lost to automation. On the flip side, the influence of developers (as opposed to both ops and central IT/CIO) is significantly increasing. Platforms such as VMForce further reduce the dependence of dev team on IT  - and they become the de facto purchasing decision makers. Adoption of these technologies, consequently, is happening bottom-up - much as open source software did.
• What about the LAMP PaaS? Google App Engine was already a Java PaaS, but developers who used it told me it was not a business-grade platform. Now VMForce offers the market what is supposedly an enterprise-class Java PaaS. There are already two credible RoR PaaS - Heroku and Engine Yard. The big stack that is glaringly missing is perhaps the most mainstream web framework - the LAMP stack. No player has yet taken this one up and it remains an opportunity.
• What else is coming from VMWare. Expect VMWare to offer as part of vCloud, or whatever their latest cloud offering is for service provider and internal clouds, the same Java PaaS capability. Of course, this will not include the functionality provided in VMForce by Force.com, but it will make its Java PaaS offering available to others.
• Reaffirmation that cloud is the way to monetize open source. As I opened this post, this move once again shows that the way to monetize on widely adopted open source software is via the 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.

Integration-as-a-Service Heats Up

Interesting to see things heat up in the emerging category of integration-as-a-service, also know as cloud integration or SaaS integration.

Praneal Narayan at SnapLogic recently sent me a note about a developer contest they are running (more on that below). SnapLogic is a recent entrant into the field, competing with Boomi and Cast Iron Systems. In October, SnapLogic announced a $2.3 million investment from Andreessen Horowitz and others and that Informatice founder Gaurav Dhillon had joined as CEO.

Clearly in the integration game one of the key success factors is coverage -- or how many end-points can the service talk to out-of-the-box. Alternatively, an integration-as-a-service provider can allow customers and 3rd-party vendors to create their own integration points. And that's what the SnapLogic developer competition is all about.

The company created an app store, they call it SnapStore, which allows third-party developers and companies to sell their own integrations (which they call "Snaps") to various platforms. The developer competition offers each developer who submits a Snap a Kindle, and the winner of the competition a $5,000 grand prize.

SnapLogic is unique in its app store approach and I'm going to follow developments there. What's interesting to me is that typically an app store approach follows the existence of a platform with a large user base as an additional way to monetize the platform and extend the product (see Salesforce AppExchange, iPhone and Facebook).

SnapLogic is turning this approach on its ear. It's creating the SnapStore to extend the product quicker than it could itself and drive users to the system through it.

It will be interesting to follow how that plays out. 

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.

Application Lifecycle in the Cloud: Update

Back in November I posted Application Lifecycle in the Cloud, making the argument that more and more of the phases of the application lifecycle (dev, testing, monitoring, etc.) are moving to the cloud.

Yesterday, Daryl Taft at eWeek published a nice piece about Atlassian, which in many ways validates what I was saying in the blog post. I actually mentioned Atlassian as a "pioneer" in this area, and it looks like the hosted versions of their developer products -- JIRA and Bamboo -- are gaining significant traction.

Here's a quote from the article:

Development teams who were previously paranoid about having their source code hosted are moving increasingly towards SaaS, he said. Even large teams with 100-plus developers are now confident to put their "behind the firewall" tools and most critical intellectual property into SaaS-based applications. Github is a good example of this, allowing developers to host their code online, he said.

Atlassian has noticed this trend with its hosted development product, JIRA Studio.  "When we started, there was no such thing as Github," said Michael Knighten, director of hosted services at Atlassian. "We thought the market would go in that direction, but it was an educated guess, at best. Now the idea of SaaS development collaboration is starting to gain traction."

“One of the interesting trends we have seen is that JIRA Studio is one of our fastest growing products, and we see this as an indication that a lot of development teams are looking to SaaS and hosted solutions,” Gibbs said.

New Overcast Podcast: Focus on PaaS

After a very long break, James Urquhart and I finally got around to recording a new episode of the Overcast podcast. This time it's just the two of us shooting the breeze on some recent cloud computing developments with a focus on PaaS.

You can listen to the podcast here.