Thinking Out Cloud

Application Lifecycle in the Cloud

Cloud computing is having a profound effect on the software application lifecycle.

Almost every phase of creating and rolling out software applications is now addressed by a growing number of cloud services: from prototyping, to development, testing & QA, continuous integration  -- and all the way down to staging, deployment and post-production (monitoring and management). All of this can now be done in the cloud.

The vision is compelling. Imagine a world in which programmers can access their development environment from any computer without having to set up anything, collaborate with teams spread around the world, easily push the code to testing and QA, and then to production, where the apps will be automatically monitored and managed.

Although admittedly realizing this vision in full is several years away, we are already seeing many of the components emerging and gaining traction.

Here are some examples:

Development

Almost every area of the development phase is now supported by cloud services. Software-as-a-Service code repositories, version control and bug tracking services such as GitHub, Beanstalk (Subversion-as-a-service) and others are now commonly used in organizations large and small.

IDEs are another story. Until recently, IDEs were last bastion of local development work, but that seems to be changing (at least there are some early indications of it). A couple of example are the Mozilla Lab's Bespin project and HerokuGarden (which although it is no longer supported by Heroku, has a following and is featured in books such as O'Reilly's Learning Rails).

Another trend in IDEs are hybrids, which introduce the notion of developing on the local machine but deploying to the cloud from within the development environment, such as the g-Eclipse project and Aptana Cloud Connect.

A new tool that was recently released and caught my attention is Mike - a service for adding and managing builds in Java for continuous integration.

Testing and QA

This is a particularly active area in the cloud, and for good reason: testing seems to be one of the earliest applications for cloud computing. Some interesting companies in this space include Sauce Labs' Sauce On-Demand, which provides functional web testing in the cloud and is based on the popular open source framework Selenium, and Skytap which provides a full-featured "QA Lab".

Mercury (now part of HP), the 800 lbs. gorilla in testing also has quite a few SaaS offerings, which are increasingly gaining traction. And IBM has launched a development and testing cloud service, which allows using various Rational products in its cloud on a pay-per-use basis.

As a "bursty" workload, and with the growing trends of continuous integration and agile development, it's not surprising that cloud testing is doing well. Developers can run massive tests on-demand and in parallel, saving significant time and shortening the development cycle.

Deployment

Then, of course, there is deployment to production. This is where PaaS players such as Google AppEngine, Force.com, Stax, Heroku, Engine Yard and others come in. All of them significantly reduce the deployment of the app by pre-building and pre-configuring a stack of application infrastructure (data tier, middleware and so on).

Production

In production, applications need to be monitored and managed. New Relic is an application performance management service running entirely in the cloud, and it can serve both applications that run in a cloud environment such as Engine Yard or AWS, as well as applications deployed in the data center. Originally, the company supported only Rails apps, but has now expanded its product to support Java as well.

RightScale is another cloud-based service that allows for a variety of management and monitoring capabilities (and in fact integrates New Relic into it).

The Future of App Development

Last week I received a call from a friend at one of the largest vendors in the technology industry. He told me they were trying to figure out the "future of application development" and asked to meet the team so they could "pick my brain". Whoa, big topic.

I spoke about a number of areas and the topic of this blog was one of them. Although this is merely a story about "tools", there is a bigger picture here. After all, in the eyes of many, the number one benefit of cloud computing is increased business agility. And a key part of business is application development.

If we take all this to its logical conclusion, we can envision a web-based environment (i.e., cloud) which developers go to and can -- with a click of a button -- streamline the entire development process on-demand, accessing the myriad of tools that today require installation and configuration on local hardware.

If you are a developer and use any of these tools, or would like to mention other tools, or have any other thoughts about the experience of development in the cloud, please leave a comment.

Yahoo and Cloudera Discuss Hadoop Next Week

My friend Dekel Tankel sent me some information about the next Hadoop user group, which takes place at the Yahoo campus in Santa Clara on Wednesday, October 21, 2009. Sounds like an interesting line up and agenda:

6-6:15 - Socializing and Beers

6:15-6:45 - Mumak - Using Simulation for Large-scale Distributed System Verification and Debugging
Hong Tang - Yahoo!

Large-scale distributed systems such as MapReduce are notoriously hard to verify & debug. An effective approach to address many of these challenges is through simulation. In this talk, I am going to present Mumak, a MapReduce simulator, including its design and implementation, early experience how it is useful, and point out some future work.

6:45-7:15 - Cloudera Desktop in Detail
Philip Zeyliger, Cloudera

7:15-7:45 - Karmasphere Studio: A graphical IDE for Hadoop

7:45-8:00 Q&A and Open Discussion

RSVP here.

The Purpose-Driven Cloud: Part 2 - Technology Frameworks

This is the second post in the series I described in The Purpose-Driven Cloud. the series is an attempt to categorize the various cloud platforms available today (and that may be available in the future). Each installment examines one of the dimensions that differentiates different cloud platforms. The first in the series discussed the Usability-Driven Cloud. This post is about: --

The Framework-Based Cloud

Framework-based cloud platforms are designed to be used with a specific programming language, product or technology stack. They enable developers who subscribe to that particular programing model to focus on the innovative aspect of their application and let the platform handle the plumbing problems of scalability, reliability and performance (and in some cases, integration).

So, as you would expect, there are clouds focused on different frameworks:

Heroku and Engine Yard provide a platform-as-a-service for Ruby.

Google App Engine supports Python and Java (or more accurately, languages that run on the Java Virtual Machine, which may include JRuby, Jython, etc.).

GigaSpaces has launched a beta cloud service, which leverages its product and the Spring Framework for creating scalable apps in the cloud.

And speaking of Spring, very notable is the recent VMWare acquisition of SpringSource, which in turn acquired Cloud Foundry, with the announced intent to create a Java cloud (or more accurately, enable Java clouds, as VMWare itself does not intend to host the platform, but sell it to third-party providers).

Stax offers another platform-as-a-service specifically focused on Java Enterprise Edition (aka J2EE).

Microsoft Azure, of course, is a .Net cloud platform.

Adobe has released a beta version of a Flash PaaS back in November of last year code-named Cocomo and then renamed it Adobe Flash Collaboration Service.

PHP does not yet have a full-blown cloud service, but not surprisingly, Zend Technologies, the company behind PHP, seems to be thinking about it, and already offering Amazon Machine Images.

Stack-Support, Proprietary Models and Trade-Offs

Modern applications are of course built from many components that form a "stack". One of the key areas of differentiation among platform-as-a-service providers who support the same programming language is going to be the stack they support and the approach they've taken to support them.

There is an inherent trade-off between the level of flexibility the platform provides for developers, and its ability to transparently handle issues such as scale, performance, reliability and integration.

Google App Engine, for example, although it supports Java, requires specific threading and data models. These are non-standard development practices, if not outright proprietary. The implications of this are that existing apps require significant changes to be made in order to run on GAE, and applications written for GAE will require significant changes to be ported to other platforms. A phenomenon also known as vendor lock-in.

Heroku, on the other hand, takes a different approach. They do require applications to be written in a certain way to run on the platform. But what they require are standard best practices. In other words, while porting a pre-existing app to Heroku might require some code and architecture changes, the opposite is not true: an application written to run on Heroku would be able to easily run on other platforms and in other (including non-cloud) environments.

Also, as I pointed out in Ruby Developers: The Cloud Generation, Heroku allows interchanging different components in the stack, such as the choice to use Rails or Sinatra.

Product-Specific Cloud Frameworks

In some cases, the "framework" is a specific (usually commercial) product that is now being offered as a cloud service. A good example of this is Tibco Silver, which leverages ActiveMatrix and other Tibco products.

Final Thoughts

An argument has been made that in the end there will be a handful of mega-clouds  - no more than five. This may or may not be true in the Infrastructure-as-a-Service space, due to the fact that at the end of the day IaaS is a commodity service and economies-of-scale will win the day. But is certainly not true when it comes to PaaS. As long as different development platforms, programming models and frameworks are around (forever?), their will be cloud platforms to support them (even if those platforms are eventually acquired by a few large players).

Read the next installment in this series: Domain-Specific Clouds.

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.

Ruby Developers: The Cloud Generation

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Memory-Based Architectures and the Cloud

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

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

An excerpt from Todd's piece:

       

RAM = High Bandwidth and Low Latency

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

       

RAM is the New Disk

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

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

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

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

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

Read the whole thing.

Cloud Pricing and Application Architecture

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Hyperic and the Cloud Podcast

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

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

Show Notes:

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

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.