The battle of the Cloud Frameworks: Application Servers redux?

The battle of the Cloud Frameworks has started, and it will look a lot like the battle of the Application Servers which played out over the last decade and a half. Cloud Frameworks (which manage IT automation and runtime outsourcing) are to the Programmable Datacenter what Application Servers are to the individual IT server. In the longer term, these battlefronts may merge, but for now we’ve been transported back in time, to the early days of Web programming. The underlying dynamic is the same. It starts with a disruptive IT event (part new technology, part new mindset). 15 years ago the disruptive event was the Web. Today it’s Cloud Computing.

Stage 1

It always starts with very simple use cases. For the Web, in the mid-nineties, the basic use case was “how do I return HTML that is generated by a script as opposed to a static file”. For Cloud Computing today, it is “how do I programmatically create, launch and stop servers as opposed to having to physically install them”.

In that sense, the IaaS APIs of today are the equivalent of the Common Gateway Interface (CGI) circa 1993/1994. Like the EC2 API and its brethren, CGI was not optimized, not polished, but it met the basic use cases and allowed many developers to write their first Web apps (which we just called “CGI scripts” at the time).

Stage 2

But the limitations became soon apparent. In the CGI case, it had to do with performance (the cost of the “one process per request” approach). Plus, the business potential was becoming clearer and attracted a different breed of contenders than just academic and research institutions. So we got NSAPI, ISAPI, FastCGI, Apache Modules, JServ, ZDAC…

We haven’t reached that stage for Cloud yet. That will be when the IaaS APIs start to support events, enumerations, queries, federated identity etc…

Stage 3

Stage 2 looked like the real deal, when we were in it, but little did we know that we were still just nibbling on the hors d’oeuvres. And it was short-lived. People quickly decided that they wanted more than a way to handle HTTP requests. If the Web was going to be central to most programs, then all aspects of programming had to fit well in the context of the Web. We didn’t want Web servers anymore, we wanted application servers (re-purposing a term that had been used for client-server). It needed more features, covering data access, encapsulation, UI frameworks, integration, sessions. It also needed to meet non-functional requirements: availability, scalability (hello clustering), management, identity…

That turned into the battle between the various Java application servers as well as between Java and Microsoft (with .Net coming along), along with other technology stacks. That’s where things got really interesting too, because we explored different ways to attack the problem. People could still program at the HTTP request level. They could use MVC framework, ColdFusion/ASP/JSP/PHP-style markup-driven applications, or portals and other higher-level modular authoring frameworks. They got access to adapters, message buses, process flows and other asynchronous mechanisms. It became clear that there was not just one way to write Web applications. And the discovery is still going on, as illustrated by the later emergence of Ruby on Rails and similar frameworks.

Stage 4

Stage 3 is not over for Web applications, but stage 4 is already there, as illustrated by the fact that some of the gurus of stage 3 have jumped to stage 4. It’s when the Web is everywhere. Clients are everywhere and so are servers for that matter. The distinction blurs. We’re just starting to figure out the applications that will define this stage, and the frameworks that will best support them. The game is far from over.

So what does it mean for Cloud Frameworks?

If, like me, you think that the development of Cloud Frameworks will follow a path similar to that of Application Servers, then the quick retrospective above can be used as a (imperfect) crystal ball. I don’t pretend to be a Middleware historian or that these four stages are the most accurate representation, but I think they are a reasonable perspective. And they hold some lessons for Cloud Frameworks.

It’s early

We are at stage 1. I’ll admit that my decision to separate stages 1 and 2 is debatable and mainly serves to illustrate how early in the process we are with Cloud frameworks. Current IaaS APIs (and the toolkits that support them) are the equivalent of CGI (and the early httpd), something that’s still around (Google App Engine emulates CGI in its Python incarnation) but almost no-one programs to directly anymore. It’s raw, it’s clunky, it’s primitive. But it was a needed starting point that launched the whole field of Web development. Just like IaaS APIs like EC2 have launched the field Cloud Computing.

Cloud Frameworks will need to go through the equivalent of all the other stages. First, the IaaS APIs will get more optimized and capable (stage 2). Then, at stage 3, we will focus on higher-level, more productive abstraction layers (generally referred to as PaaS) at which point we should expect a thousand different approaches to bloom, and several of them to survive. I will not hazard a guess as to what stage 4 will look like (here is my guess for stage 3, in two parts).

No need to rush standards

One benefit of this retrospective is to highlight the tragedy of Cloud standards compared to Web development standards. Wouldn’t we be better off today if the development leads of AWS and a couple of other Cloud providers had been openly cooperating in a Cloud equivalent of the www-talk mailing list of yore? Out of it came a rough agreement on HTML and CGI that allowed developers to write basic Web applications in a reasonably portable way. If the same informal collaboration had taken place for IaaS APIs, we’d have a simple de-facto consensus that would support the low-hanging fruits of basic IaaS. It would allow Cloud developers to support the simplest use cases, and relieve the self-defeating pressure to standardize too early. Standards played a huge role in the development of Application Servers (especially of the Java kind), but that really took place as part of stage 3. In the absence of an equivalent to CGI in the Cloud world, we are at risk of rushing the standardization without the benefit of the experimentation and lessons that come in stage 3.

I am not trying to sugar-coat the history of Web standards. The HTML saga is nothing to be inspired by. But there was an original effort to build consensus that wasn’t even attempted with Cloud APIs. I like the staged process of a rough consensus that covers the basic use cases, followed by experimentation and proprietary specifications and later a more formal standardization effort. If we skip the rough consensus stage, as we did with Cloud, we end up rushing to do final step (to the tune of “customers demand Cloud standards”) even though all we need for now is an interoperable way to meet the basic use cases.

Winners and losers

Whoever you think of as the current leaders of the Application Server battle (hint: I work for one), they were not the obvious leaders of stages 1 and 2. So don’t be in too much of a hurry to crown the Cloud Framework kings. Those you think of today may turn out to be the Netscapes of that battle.

New roles

It’s not just new technology. The development of Cloud Frameworks will shape the roles of the people involved. We used to have designers who thought their job was done when they produced a picture or at best a FrameMaker or QuarkXPress document, which is what they were used to. We had “webmasters” who thought they were set for life with their new Apache skills, then quickly had to evolve or make way, a lesson for IaaS gurus of today. Under terms like “DevOps” new roles are created and existing roles are transformed. Nobody yet knows what will stick. But if I was an EC2 guru today I’d make sure to not get stuck providing just that. Don’t wait for other domains of Cloud expertise to be in higher demand than your current IaaS area, as by then you’ll be too late.

It’s the stack

There aren’t many companies out there making a living selling a stand-alone Web server. Even Zeus, who has a nice one, seems to be downplaying it on its site compared to its application delivery products. The combined pressure of commoditization (hello Apache) and of the demand for a full stack has made it pretty hard to sell just a Web server.

Similarly, it’s going to be hard to stay in business selling just portions of a Cloud Framework. For example, just provisioning, just monitoring, just IaaS-level features, etc. That’s well-understood and it’s fueling a lot of the acquisitions (e.g. VMWare’s purchase of SpringSource which in turn recently purchased RabbitMQ) and partnerships (e.g. recently between Eucalyptus and GroundWork though rarely do such “partnerships” rise to the level of integration of a real framework).

It’s not even clear what the right scope for a Cloud Framework is. What makes a full stack and what is beyond it? Is it just software to manage a private Cloud environment and/or deployments into public Clouds? Does the framework also include the actual public Cloud service? Does it include hardware in some sort of “private Cloud in a box”, of the kind that this recent Dell/Ubuntu announcement seems to be inching towards?

Integration

If indeed we can go by the history of Application Server to predict the future of Cloud Frameworks, then we’ll have a few stacks (with different levels of completeness, standardized or proprietary). This is what happened for Web development (the JEE stack, the .Net stack, a more loosely-defined alternative stack which is mostly open-source, niche stacks like the backend offered by Adobe for Flash apps, etc) and at some point the effort moved from focusing on standardizing the different application environment technology alternatives (e.g. J2EE) towards standardizing how the different platforms can interoperate (e.g. WS-*). I expect the same thing for Cloud Frameworks, especially as they grow out of stages 1 and 2 and embrace what we call today PaaS. At which point the two battlefields (Application Servers and Cloud Frameworks) will merge. And when this happens, I just can’t picture how one stack/framework will suffice for all. So we’ll have to define meaningful integration between them and make them work.

If you’re a spectator, grab plenty of popcorn. If you’re a soldier in this battle, get ready for a long campaign.

7 Comments

Filed under Application Mgmt, Automation, Big picture, Cloud Computing, Everything, Mgmt integration, Middleware, Standards, Utility computing

7 Responses to The battle of the Cloud Frameworks: Application Servers redux?

  1. Good insightful blog (as usual. In fact I referred your blog to a couple of colleagues to learn from, about the WS-* lessons!).

    Yep, App servers and Cloud Frameworks will merge. Grabbing the rifle and preparing for a long battle ;o)

    An interesting item on wmw:
    http://www.redmonk.com/jgovernor/2010/04/21/vmwares-springsource-redis-and-rabbit-acquisitions-a-database-play-is-emerging/

    “Developing cloud based apps will require new data management and storage models. VMware is getting well ahead of the curve”
    “As alternative data stores become natural targets for new application workloads VMware does indeed plan to become a database player, or NoSQL player, or data store, or whatever you want to call it.“

    vmw is morphing into a very different company!

  2. Hey thanks for linking to me Krishna, it brought me to this interesting post. :-)

    Hey William – enjoyed this post a lot. Some good food for thought. I would say VMware’s acquisition of SpringSource is an artifact of the app server wars – indeed it might be seen as heralding the last chapter – rather than the ongoing cloud framework build-out.

    The winners in any technology wave are the best packagers- whether that’s Sun packaging Unix workstations, Dell packaging Windows and Intel, Compaq in the PC Wave, Apple with the iPhone, IBM with System/360 and so on. The race is on, as you say, to package Cloud frameworks. Someone is going to win very big indeed.

    May the best packager win.

  3. William,

    Great post. As a veteran of the app server wars, I find the parallels interesting.

    First, I hope I understand what you mean by ‘Cloud Framework’. If so I think you would include current players such as 3tera/CA, Elastra, Rightscale, Eucalyptus, and not Cloud Operators such as Amazon and Rackspace?

    My comment is about the benefits of “winning” the Cloud Framework war, in that I don’t see the same amount of upside as there was for the app server war. I worked for BEA, which ended up with revenues north of $1.5B selling license+services for app server and derivative products. Over $500M of that was license, and a big chunk of services was mandatory maintenance tied to that license. Its tempting to look for the same revenues to come from Cloud Framework.

    But its getting awfully hard to sell licenses for framework software these days – e.g. no one pays license to run the likes of Spring, GWT, RoR, Django, Wicket, Seam, etc. Of course there is always money from optional support, but when it isn’t mandatory it doesn’t flow nearly as much.

    While most of the current crop of Cloud Framework vendors have a license model, its hard for me to see that continue. Perhaps the open source devops stuff (Puppet, Chef) will take over Cloud Framework, or it will be Eucalyptus, or perhaps something else entirely.

    The point is, winning Cloud Framework will certainly bring in millions, but I doubt it will bring in the billions* like winning app server (viva WebLogic). I think that is a key differences in these wars.

    * with a notable exception of the PaaS offered by Salesforce.com. While I think force.com will do well, I don’t see it winning the Cloud Framework war.

    Peter

  4. Stu

    I wrote a couple unpublished papers back in the mid-late 90’s, one was called “The Rise of the Application Server” back in late 1997, I believe.

    Looking back, I agree with your history, with one interesting discontinuity between the progression of app servers and cloud servers.

    Stage 2 app servers included NetDynamics, Kiva (both of these became iPlanet in some form), Netscape LiveWire (server-side Javascript baby!), ATG Dynamo, BEA’s M3 (the CORBA-based Tuxedo), and Microsoft Transaction Server with IIS. It was like the wild west.

    The unthinkable happened in between stage 2 and 3. Let’s call it stage 2.5. An application server standard emerged with the Java platform. The combination of JSP, Servlets, and JDBC were enough for most people, but the options of EJB and JTA for transactions in early 1998, and the packaging format that J2EE brought in late 1999, meant it was basically the main game in town. For almost four solid years, 1998 through 2002, it grew at an unprecedented rate in the enterprise, and basically trampled MTS/COM+ and other proprietary app servers, until Microsoft finally fought back with .NET’s announcement in Summer 2001 & release in early 2002. I watched Wall Street shift from VB6, C++ and some dabbling with MTS/COM+ into full fledged Java engines during this time… .NET (and its push to Web Services) came in the nick of time to change the game. In the meantime, BEA had become a billion dollar company, and IBM WebSphere had a massive contribution to IBM’s middleware sales.

    The moral of the story, however, is this: if my memory serves, the reason the enterprise Java APIs and J2EE were so successful was for one reason: the customers *demanded* an app server standard, and knew exactly what features it wanted: database access, web page creation, transactions, messaging, and a packaging standard. The bits of J2EE that failed were the stuff no one asked for (e.g. EJB Entity Beans in 1.x).

    The problem with cloud seems to be that the enterprise customers have been very lax on demanding standards so far, or even understanding the benefit. The web’s benefit was clear: more distributed, easier to maintain, thin, non-Microsoft-dependent information sharing and UIs. Java’s benefit was clear: more productive server-side development. Cloud’s benefit is a confused mix of “The New Outsourcing”, “The New Agile Operations”, “The New Virtualization”, and “The New Massively Parallel Processing (MPP)”. Those are very different problem spaces, with (arguably) separate standards needed.

  5. Good post. I think, prior to cloud, app servers, web servers the TCP/IP, DECNET, SNA shake out happened (after all, without the network a cloud, by design, couldn’t be cloud). Obviously, it seems the UI device (VT100 and 327X) shake out happened too. And then along came this thing called a PC. I tend to look at all of this as a massive buildout of a stack spanning over 30 years (obviously, prior to that all I had was academic understanding of Turing Machines). I think, by design a cloud is a massive Turing Machine where clouds can make more clouds. Essentially, a Universal TM. A framework is the means such organic processes will evolve the cloud.

    Anyhow, we do have external environment factors (the cloud providers) that will seek to mutate the DNA of the cloud for monetary reasons. Thus, we will have many many yet another framework for the cloud. Ultimately, I think the evolution process will make things survive or die. Those stuck with a dead framework could die with it.

  6. Pingback: William Vambenepe — PaaS portability challenges and the VMforce example

  7. Interesting article! I am curious to see where cloud computing will be a few years from now. It’s quite amazing when you look back only a year or two as compared to now, how many more people have become aware of the cloud. Thanks for sharing this!