PaaS is not Middleware over IaaS

By Reza Shafii on Jan 26, 2012

When I use Google docs, I am not aware of what middleware components its implementation is using. Google docs might be built on BigTable or it might not, but as a user of the product, all middleware implementation details of it are irrelevant to me. I also don’t care about the infrastructure side of things such as the operating system being used to execute the computations behind my spreadsheet. These details would also be irrelevant to me as an IT organization that might have chosen to introduce Google docs as its office tools solution. That is, from the point of view of the IT organization, all that matters is that the application’s functionality is reliably delivered to my organization’s end users. This is in fact the core value proposition of a public SaaS to IT: The concern for the ownership and maintenance of the underlying middleware and infrastructure is completely shifted from the IT organization to the SaaS provider. The diagram below illustrates this IT delivery model.
[A note on reading the diagrams in this entry: Consider anything within the aaS gray space as available to the IT shop, but without the burden of maintenance which is shifted to the aaS provider]

With this understanding in mind, it is worth considering what the equivalent scenario is for a Platform as a Service (PaaS) solution. If I introduce a PaaS solution in my enterprise, the benefits from an IT organization should be exactly the same: The concern for the ownership and maintenance of the underlying middleware and infrastructure should be completely shifted from the IT organization to the PaaS provider. The only difference from a SaaS point of view is that I am now also able to create custom applications and deploy them on my PaaS environment. These custom applications would enhance and complement my set of SaaS delivered applications. From a development point of view, the developers of these custom applications should still be able to leverage middleware technologies and concepts (web apps, web services, messaging, and so on) to develop great applications, but they should in turn be freed from the need for concern of the maintenance of these middleware technologies. This to me is the criterion of what constitutes a PaaS and the diagram bellow illustrates where it fits relative to an Infrastructure as a Service (IaaS) and SaaS solution.

Now, as I have been introducing the Java Cloud Service – part of the PaaS services of the Oracle Public Cloud - to our customers, I have found that sometimes, the expectation is of an environment where the administrators would be able to provision machine instances (with specific CPU/memory footprints, file storage properties, and so on) that have a pre-installed set of Fusion Middleware products (WebLogic Server, Oracle Web Services Manager, ADF, etc…). The picture behind this thinking is as follows.

Effectively, this model is to use an Infrastructure as a Service (IaaS) layer to host and manage middleware in a traditional manner. To be sure this model has benefits, in that the concern for the ownership and maintenance of the underlying infrastructure is shifted from the IT organization to the IaaS provider. This means that the IT organization no longer has to worry about machine hardware space or OS patches and updates. However, notice that the concern for the ownership and maintenance of the underlying middleware remains exactly the same as if the middleware was running within on-premise, non-IaaS delivered, infrastructure. The IT organization would still have to purchase the packaged middleware components and have a set of trained administrators to install and maintain it. Therefore, this model is in my view not a PaaS, but can be characterized much more accurately as Middleware over IaaS.
The Middleware over IaaS model today provides more flexibility to application administrators in that they have full control of the middleware runtime environment and its infrastructure knob. However, the beauty of a PaaS model is that it promises to eliminate the need for the control of these parameters altogether. The ultimate PaaS solution would be able to automatically deduce the optimal runtime environment for an application and automatically adjust it as the needs of the application and its usage evolve. To give some concrete examples, with a PaaS solution you would not need to worry about whether the application server’s clustering protocol uses multicast or unicast, or what the exact JMS destinations that must be created for your application are. Instead, the PaaS solution will automatically figure out these details for you and make your application available in a reliable manner based on quality of services policies alone (e.g. this application is more important than the other, or requests for this application should never take longer than 1 second to complete).
Such a solution is of course not going to materialize itself overnight in the PaaS world for the entire spectrum of applications out there. However, my expectation is that as PaaS offerings mature, this vision will become a reality for more and more complex and varied types of applications. This evolution should then allow enterprises to move from a Middleware over IaaS type of cloud solution to a PaaS solution. Now, if you take this predication to its logical conclusion, the diagram below could then represent the IT shop of the enterprise of the future.

As we progressively move towards IT shops that are purely PaaS and SaaS delivered, the world of IT should as a result become incrementally simpler and more cost effective. This is because the burden of the ownership and management of the entire middleware and infrastructure will be shifted to the PaaS/SaaS providers letting IT focus instead on its true core capability, which is of course the timely delivery of business applications. With the Oracle Public Cloud, Oracle is introducing a solution that will allow for a big leap towards this end.