PaaS is the New Middleware

Share via Twitter Share via Facebook Share via Linkedin Share via Reddit

The original idea behind J2EE was as simple as it was compelling. “Write once, run anywhere” promised customers a layer of abstraction which would provide independence from underlying operating system and hardware layers, and thus, in theory, vendor substitutability. In practice, “write once, run anywhere” was as aspirational as not, with providers of J2EE middleware constantly in search of features that might provide the customer lock-in the market had trained them to crave. Aspirational or no, however, customers bought into the vision, as companies like BEA rode the middleware market to $8.5B valuations.

Oddly enough, however, multiple runtime PaaS platform providers like Red Hat (OpenShift) and VMware (Cloud Foundry) appear to be discinclined to borrow from the middleware playbook. While “write once, run anywhere” mantra may be a tired cliche, the similar functional goals would seem to offer the opportunity to more easily position PaaS platforms within enterprises. Overall, the idea behind PaaS is the same as it once was for J2EE: to containerize applications, thereby making them portable across different environments, regardless of the underlying infrastructure. Neither Cloud Foundry nor OpenShift seems eager for the comparison, however.

OpenShift.com, for example, says that users can “enjoy support for a broad choice of languages, frameworks, middleware, datasources, and developer tools” – the obvious implication being that OpenShift is not, itself, middleware. CloudFoundry.com even more aggressively disavows any relationship between itself and the term. From its FAQ page:

Cloud Foundry allows developers to focus on applications, not machines or middleware. Traditional application deployments require developers to configure and patch systems, maintain middleware and worry about network topologies. Cloud Foundry allows you to focus on your application, not infrastructure, and deploy and scale applications in seconds.

In spite of the functional similarities, then, neither Cloud Foundry nor OpenShift is positioning itself as middleware. To some extent, this may be explained by product portfolios as both Red Hat (JBoss) and VMware (Spring) have existing middleware lines of business, and terming their respective PaaS offerings as middleware would complicate marketing efforts. It is not clear, however, that an attempt to persuade customers to see PaaS as something other than middleware will be successful. Nor that this is the correct approach. Our old colleague Michael Cote’s “burger model” – which characterizes PaaS as middleware – has proven quite popular in various talks and webinars, because it’s easily understood. And technologies that are well understood are easier to sell.

Ultimately, if it looks like middleware and acts like middleware, it probably is middleware – whatever the vendors may assert. PaaS, in other words, is the new “write once, run anywhere.”


  1. But Stephen, I don’t think it is middleware in the way most people think of middleware. I do think it is is middleware in a “cloud” stack. So if the old stack was: OS -> AppServer -> Application; in a cloud environment it is: IaaS -> PaaS -> SaaS. Yes, PaaS is in the middle but it is not middleware, the hamburger analogy still works since it is an analogy. And that analogy we embrace quite regulary if you look at our slidedecks on slideshare. We show ourselves in the middle between IaaS and SaaS. And we also embrace the write once run anywhere mantra since all of the pieces in OpenShift are stock FOSS pieces. You can take the code you write for PHP or Ruby or Java in OpenShift and deploy to Apache or JBoss running on your laptop.

    I would feel more comfortable saying that PaaS is like middleware of your traditional stack. In OpenShifts case we also bring up DataStores and Cron jobs as part of our PaaS which isn’t exactly middleware.

    Great discussion though

  2. The devil is in the details and what you mean by “run anywhere”.  Java and JEE middleware allowed you to write to one JVM or application container and run it on different platforms – abstracting the differences between those platforms from the application code.   PaaS is only analogous to that if the services provided within the PaaS are standards-based to truly enable application portability.   Try moving a Java application from Google App Engine to an on-premise JEE app server container.  Or try moving an application that makes use of Amazon’s growing number of App or Data services to any other cloud service provider or to on-premise.

  3. With Michael Cote’s Burger Model to NIST’s layer cake diagrams already labelled “PaaS” and re-posted on slidesharing sites and corporate intranets across the globe, the term “PaaS” has taken root and is here to stay.  
    To me, “A PaaS is a PaaS is a PaaS”.  It’s *Platform* as a service not *Middleware*
    as a service. Just because PaaS is the middle layer of the end-to-end software
    stack in the cloud doesn’t necessarily mean it is  “middleware”.  
    As a PaaS vendor {quick note: I work on ActiveState’s Stackato team}, I do cringe a bit to being pigeon-holed as “middleware” as that minimizes the PaaS effect on the entire cloud eco-system. 

     The term “middleware” has roots in the late 1980s and grew out of earlier technology with a narrower focus, connecting database clients and database servers over various network platforms.  It grew into popularity in the mid-90s, established itself a lucrative beachhead in the enterprise software market, and became the bloatware – that, as a developer, I have been trying to escape from “middleware” ever since.

    PaaS simplifies the entire code to cloud process. PaaS breaks down operating system barriers. It’s  the abstraction layer that removes the operating system boundaries from the Cloud, ensures that applications are not highly coupled to a hardware machine or a single server, database or a single cloud hosting provider’s API. PaaS is about giving developers a *Platform* with secure containerization, built-in deployment automation, auto-scaling, “run anywhere” and, yes, it comes with some of that middleware-ish glue in the cloud too.

    So if you must, go ahead call it “middleware “,  or call it aPaaS, iPaaS, dbPaas, CEAP or whatever else you (and marketing) want –  just as long as I can have my PaaS and eat it too.

  4. Stephen, way to call a spade a spade. As CEO of Apprenda (a .NET PaaS software layer for building private/public PaaS’), I agree that PaaS is the latest incarnation of middleware and find it humorous that PaaS vendors are working so hard to distance themselves from the term.

    Middleware, as an architectural and conceptual construct, should be embraced by PaaS vendors who have actually built a *containerizing PaaS* (more on this later). In the field, we frequently refer to Apprenda as “private cloud middleware” or “a modern, distributed cloud application server.” We do this because a) it is technically accurate and b) it is familiar to the market. Not leverage this positioning as an asset is silly.

    I think in part, most PaaS vendors are probably accurate when they don’t describe themselves as middleware. You see, there is a tremendous difference between application servers of yesteryear (e.g. BEA, Websphere, etc.) and PaaS’ of today. Most PaaS offerings, including CloudFoundry, aren’t application containers. They merely sit on the sidelines as a “coach”, directing things like workload placement on OS instances – and that’s it (yes, they do other basics like updating load balancers, etc. That’s still not containerization). In that regard, I guess calling themselves application servers or middleware would be disingenuous because they’re not, so kudos on the honesty. Unfortunately, this simplistic model will knee-cap their capacity to deliver and grow customer value beyond devops type value (which is important and we do it better than anyone, but is not the end state value proposition of the PaaS model).

    We’ve placed a significant amount of emphasis at Apprenda on PaaS being an actually container. This means guest application binary payloads are loaded in Apprenda memory spaces, where Apprenda runtime components interact with guest applications to achieve much greater outcomes than if an application ran off Apprenda (for example, being able to inject row level multi-tenancy into database instances, and reconciling it with runtime queries from things executing in disparate CLR instances). This sort of model is minimally required to truly be a container – the PaaS software layer needs to be an active runtime module in the guest applications memory space – just like traditional app servers.

    Diane, I’m not sure about you, but I’ve written apps without app servers and middleware – it meant I had to deal with OS resource management like ports and building advanced threading models, had to worry about things like managing HTTP conversations myself (or if I was dealing with some protocol-less TCP garbage, roll my own). Either that, or I’d resort to CGI (yuck). App servers and middleware were a blessing, not a curse. They normalized expectations for developers (although not in practice, as Stephen pointed out, but at least conceptually), provided an application container that enhanced my applications in exchange for some architecture conformity, and accelerated development of web applications. 

    I hope that Apprenda can have the same impact on developers and the market that application servers and middleware did (and of course, avoiding the negativity that naturally gets introduced into products when a market matures) 

    1. Call PaaS, “middleware for the cloud” if it helps explain the
      functionality provided – I won’t disagree with the similarities there at
      all. It’s the choice, flexibility and portablity of PaaS is making the
      real impact.
      I would agree that middleware (and app servers) has made it simpler to develop and deliver web applications, but the price you’d paid in overhead & lock-in often made it a mixed blessing.   Deploying web applications with a PaaS, there are still some architecture conformity trade-offs but in exchange you get your choice of languages, frameworks and services working with multiple hypervisor/infrastructure layers on any cloud.  Working with a PaaS allows developers to maintain a consistent environment at each stage of the development path, ensuring seamless deployments and minimal time on configuration regardless of which cloud you want to deploy your applications.

      For the record:  like Apprenda,  ActiveState’s Stackato PaaS architectural model is based on secure application containers which again sets us apart from pure middleware plays (and a number of other PaaS as well).  The other advantages of true containerization is that it allows us to enable the secure interaction with the application within the container via  application support commands such as dbshell, tunnel, cron and run.  For more details – check out http://www.activestate.com/stackato

  5. […] PaaS is the New Middleware (redmonk.com) […]

  6. Stephen, I think you’re spot on in your high level characterization of PaaS (and BaaS as well) as being cloud middleware. PaaS is relatively new to the cloud space, is still evolving as an offering, and has been implemented (i.e., dotCoud, cloud foundry, heroku, amazon beanstalk, google app engine and so on) in myriad of ways. It is this evolution of the offering that I find most similar to J2EE (or middleware). The key value proposition  (‘write once run anywhere’ or more accurately in the early days, ‘single server framework’) behind early application servers like Tenga (WebLogic) or Kiva (NAS) was to allow developers to focus on application development and not have to deal with server issues. In those days moving from one application server to another was a significant migration effort and J2EE as a standard attempted ameliorate this issue. PaaS I believe, as it compares to J2EE, is somewhere early on the evolutionary curve (circa 1996-1997). Fundamentally PaaS’s value proposition, is very similar to that of application servers, and attempts to alleviate cloud concerns such as software stacks, services, deployment, load balancing, auto-scaling, and etc. Although cloud deployment, as compared to enterprise deployment environments, has different requirements and concerns (mostly along IT considerations) the developer’s perspective remains consistent, ‘I just want my application to run on the cloud (or in the data center) like it does on the software stack I installed in my local development environment’. The power behind middleware (or standardized software stacks) is being able to download Tomcat or JBOSS onto my desktop, implement and test locally, and then, with a high level of confidence, deploy it to another environment and it just works, the same expectations apply to PaaS. ‘joefern1’ correctly makes the point that it is very difficult to move applications from one PaaS platform to another, which I find eerily reminiscent of the early application servers, and a standard ultimately was needed to address the problem. I suspect the portability issues across PaaS platforms is mostly related to services and data and IaaS vendors (the first cloud offering to the party) have some of the same concerns and are now considering standards such as OpenStack. As it applies to PaaS  developers are not just concerned with portability but other issues such as interoperability, security, monitoring, data management, services, and etc. Maybe PaaS has reached a point where its time to start considering standards.

  7. […] is discussed the most prominent use-case being brought up is integration. Some people claim that PaaS is the New Middleware … and I fully agree. Whether we talk about building extensions for SaaS applications or […]

  8. […] Or, as Stephen puts it: PaaS is the new middleware. […]

Leave a Reply

Your email address will not be published. Required fields are marked *