Backward-compatible vs. forward-compatible: a tale of two clouds

There is the Cloud that provides value by requiring as few changes as possible. And there is the Cloud that provides value by raising the abstraction and operation level. The backward-compatible Cloud versus the forward-compatible Cloud.

The main selling point of the backward-compatible Cloud is that you can take your existing applications, tools, configurations, customizations, processes etc and transition them more or less as they are. It’s what allowed hypervisors to spread so quickly in the enterprise.

The main selling point of the forward-compatible Cloud is that you are more productive and focused. Fewer configuration items to worry about, fewer stack components to install/monitor/update, you can focus on your application and your business goals. You develop and manage at the level of application concepts, not systems. Bottom line, you write and deploy applications more quickly, cheaply and reliably.

To a large extent this maps to the distinction between IaaS and PaaS, but it’s not that simple. For example, a PaaS that endeavors to be a complete JEE environment is mainly aiming for the backward-compatible value proposition. On the other hand, EC2 spot instances, while part of the IaaS layer, are of the forward-compatible kind: not meant to run your current applications unchanged, but rather to give you ways to create applications that better align with your business goals.

Part of the confusion is that it’s sometimes unclear whether a given environment is aiming for forward-compatibility (and voluntary simplification) or whether its goal is backward-compatibility but it hasn’t yet achieved it. Take EC2 for example. At first it didn’t look much like a traditional datacenter, beyond the ability to create hosts. Then we got fixed IP, EBS, boot from EBS, etc and it got more and more realistic to run applications unchanged. But not quite, as this recent complaint by Hoff illustrates. He wants a lot more control on the network setup so he can deploy existing n-tier applications that have specific network topology/config requirements without re-engineering them.  It’s a perfectly reasonable request, in the context of the backward-compatible Cloud value proposition. But one that will never be granted by a Cloud that aims for forward-compatibility.

Similarly, the forward-compatible Cloud doesn’t always successfully abstract away lower-level concerns. It’s one thing to say you don’t have to worry about backup and security but it means that you now have to make sure that your Cloud provider handles them at an acceptable level. And even on technical grounds, abstractions still leak. Take Google App Engine, for example. In theory you only deal with requests and not even think about the servers that process them (you have no idea how many servers are used). That’s nice, but once a while your Java application gets a DeadlineExceededException. That’s because the GAE platform had to start using a new JVM to serve this request (for example, your traffic is growing or the JVM previously used went down) and it took too long for the application to load in the new JVM, resulting in this loading request being killed. So you, as the developer, have to take special steps to mitigate a problem that originates at a lower level of the stack than you’re supposed to be concerned about.

All in all, the distinction between backward-compatible and forward-compatible Clouds is not a classification (most Cloud environments are a mix). Rather, it’s another mental axis on which to project your Cloud plans. It’s another way to think about the benefits that you expect from your use of the Cloud. Both providers and consumers should understand what they are aiming for on that axis. Hopefully this can help prevent shout matches of the “it’s a bug, no it’s a feature” variety.

[UPDATED 2010/3/4: Apparently, Steve Ballmer thinks along the same lines. Though the way he sees it, Azure is forward-compatible, while Amazon is backward-compatible: “I think Amazon has done a nice job of helping you take the server-based programming model – the programming model of yesterday, that is not scale-agnostic – and then bringing it into the cloud. On the other hand, what we’re trying to do with Azure is let you write a different kind of application.“]

[UPDATED 2010/3/5: I now have the quasi-proof that indeed Steve Ballmer stole the idea from my blog. Look at this entry in my HTTP log. This visitor came the evening before Steve’s “Cloud” talk at the University of Washington. I guess I am not the only one to procrastinate until the 11th hour when I have a deadline. Every piece of information in this log entry points at Steve Ballmer. How can it be anyone other than him?

131.107.0.71 - - [03/Mar/2010:23:51:52 -0800] "GET /archives/1198 HTTP/1.0" 200 4820 "http://www.bing.com/search?q=Brilliant+Cloud+Insight" "Mozilla/1.22 (compatible; MSIE 2.0; Microsoft Bob)"

(in case you are not fluent in the syntax and semantics of HTTP log files, this is a joke)]

9 Comments

Filed under Amazon, Application Mgmt, Cloud Computing, Everything, Google App Engine, IT Systems Mgmt, Utility computing, Virtualization

9 Responses to Backward-compatible vs. forward-compatible: a tale of two clouds

  1. Really enjoyed this post. Exactly what we’re thinking. So is customizable PaaS, forward and backward compatible?

  2. Hi Yoram. I don’t think it’s possible to be both backward and forward compatible. But I am not sure what you mean by “customizable PaaS”, could you please elaborate?

  3. What if you could create additional compute types according to your needs? These compute types could come with specialized operating systems and software services unique to your IT operations (ie backward compatible). For example, you may need a special type of application server and upon request you can have your requirements implemented and integrated into the cloud. This would also allow you to be forward compatible and standardize a development environment.

  4. Yoram,

    OK I get that, in concept at least. To the extent that the legacy apps you are trying to migrate are based on some reusable framework that can be pulled out and delivered as a new type of PaaS container. Though if this framework is just a “black box” from the Cloud provider point of view then you are not going to get all that many benefits in this approach compared to traditional IaaS approach of bundling the framework w/ the app.

    For example, Google did a fair amount of work on their Java and Python runtimes to offer them as PaaS containers that exhibit great operational characteristics. If you asked them to offer the same thing for Cold Fusion or ASP.Net, they’d have to do serious engineering in these runtimes too. Otherwise they won’t be able to provide nearly the same scalability/resilience and low cost of operation for these platforms that they do w/ Python and Java.

    There is no silver bullet, but I can see how what you describe could be a new cost/benefit trade-off point on the axis from backward-compatible to forward-compatible. Though I am still unclear on the specifics and whether it all adds up in practice. Interested in any info/pointer you can share on this.

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

  6. Pingback: William Vambenepe — CMDB in the Cloud: not your father’s CMDB

  7. Pingback: William Vambenepe — The necessity of PaaS: Will Microsoft be the Singapore of Cloud Computing?

  8. Pingback: » Google Compute Engine, the compete engine Cloud Comedy, Cloud Tragedy

  9. Pingback: » Joining Google Cloud Comedy, Cloud Tragedy