PaaS will allow application developers to always use the right tool for the job; including tools that aren’t even conceived as potential application tools.
I'm not much of a cook. Of the many errors I commit in the kitchen, the most common is a failure to use the right tool for the job. Not because I don't have it, or I don't know how to use it, but because I over-optimize for the post-cooking cleanup at the expense of the cooking experience. The saucepan used to boil the potatoes isn't the best tool for a sauté, but it's already out and it will do. The wooden spoon used to stir-fry vegetables doesn't make as good a serving instrument as the metal ladle, but it's already dirty so let's use it. Sometimes this make-do attitude just produces inconvenience, sometimes it leads to disaster ("I don't need to dirty a colander; I can just hold the lid against the pan and slowly pour… Oops! OK kids, we're eating pasta off the sink tonight.")
What is true for cooking is true for software development. Using the right tool for the job means higher productivity and a more robust, efficient implementation. But, just like cooking, there are many tools in the drawer and each one that you take out comes with its own cost.
Enterprise applications are made of more than just code. The selection of the platforms they are built on is as important as their specific code and configuration. That's why "middleware" is a much broader category than just "application servers", and even "middleware" doesn't capture all of various runtimes that support enterprise applications. Just looking at the list of application-related "Magic Quadrants" offered by Gartner gives an idea of the diversity of these product categories and the difficulty of the task, for IT architects, of deciding which to use: Just for the application runtime, there are Magic Quadrants for "Enterprise Application Servers ", "Horizontal Portals", "Mobile Enterprise Application Platforms", "Ajax Technologies and RIA Platforms", "Application Delivery Controllers", "Application Infrastructure for Systematic SOA-Style Application Projects", etc. Add to this data-related platforms (relational databases, distributed databases of various forms, master data management), as well as messaging infrastructure, security, identity management infrastructure, application performance management tools and soon enough one has to decide whether to optimize for employing the right tool for every task or optimize for assembling an easy-to-manage set of tools.
Each new tool, when selected, brings additional features that the application can take advantage of, but also a new set of administrative tasks, another platform the administrators need to be trained on, another set of operating system requirements, additional license and support costs, another support channel, etc. That's when people start wondering whether they really need a portal or can they make do with the more basic UI reuse features of the application server. Integrated product suites from portfolio vendors alleviate many of these issues (tested integrations, centralized management, unified support...) but not all. Enterprise application platforms, like Java EE, provide a large set of features, but in many cases they provide a portable interface to infrastructure tools that are not themselves included in the platform runtime (e.g. a database). It significantly lowers the barrier to using these external tools, but from an operations perspective the cost of yet-another-tool-to-manage remains.
The next leap in making it practical to always use the right tool for the job will come with PaaS.
Today's PaaS offerings are, with few exceptions, focused on the basic building blocks of application platforms: an application runtime ("app server"), a database, and an Identity Management (IDM) store. For now, the flexibility of the various offerings has been most often measured in terms of number of programming languages supported (Java, Ruby, Python, PHP, JavaScript...). But PaaS changes so quickly (compare today's PaaS landscape to what it was a year ago) that the current landscape is almost irrelevant already.
Soon we will realize that supporting yet another language that offers the same interaction style is not a very important measure of diversity. Diversity will instead be measured in the number, richness and comprehensiveness of value added platform services offered. From map-reduce services to business process orchestration.
In the same way that many application runtime tools are under-utilized because of the operational cost of setting them up, configuring them and maintaining them, many application management tools are also under-utilized, for much of the same reasons. So system administrators and developers scroll through various log files in scenarios where transaction tracing tools might provide a much more direct answer. They add crude browser-side instrumentation in places where network-based traffic capture can provide a rich view of the user experience and permit replay of transactions. They manually generate test transactions in places where the right tools can capture actual customer traffic, scramble confidential information and deliver a usable and realistic set of test input and output payload.
All these "right tools" exist today and are sometimes used in traditional data centers, but not as often and as consistently as they should be. Because their acquisition and operation cost aren't perceived (rightly or wrongly) to be worth the value they can deliver. Because trying them out (in a realistic way, applied to your application) is, in itself, a time-consuming effort.
As of today, in most cases, in a PaaS environment one cannot use these advanced tools, because the environment is too restrictive. Today, advanced runtime services and advanced management services are used occasionally in traditional environments (to some extent including IaaS) and never in PaaS environment.
As PaaS matures, this trend will reverse and PaaS environments will be those in which users (almost) HAVE to use the right tool; where they've lost all the excuses (both of the valid and the imagined kind) for not using (or at least trying out) the full richness of runtime and management tools. That’s because the underlying Cloud operating system is built from the ground up to host these various platform services and present them in a unified way not just to the application running on top but also to the administrators in charge of maintaining them.
This change is even more profound than it seems. Getting transaction tracing, user experience monitoring, transaction capture, auto-scaling and all kinds of advanced platform features by default (or by just checking a checkbox) is a big improvement. But the move to PaaS will hand to developers and architects, tools that aren't even on the table today. Here are 3 examples:
Example 1: There is no reserved domain
In traditional settings, the application is confined to what happens on the computers on which it runs. There is a lot more infrastructure than just computers in a datacenter, but all that is the domain of IT administration and out of reach for programmers. The best they can do is document what network topology and load balancing configuration is desired. In PaaS, the entire infrastructure is accessible, and when that happens, you can count on developers using it in ways that will horrify traditional IT administrators. The CDN is not just an after-the-fact deployment optimization; it becomes a core part of the application logic. Even DNS, old, boring, sacrosanct, must-never-go-down DNS, becomes another programmable entity. And it is used in completely new ways as a result, as illustrated by people currently experimenting with giving almost everything a CNAME and gaining complete location transparency.
Example 2: Business is code
The mantra of "aligning IT and business" is frequently heard. Nothing is wrong with it. But PaaS gives you not only the tools to align them but also to merge them in many places. Fine-grained metering and billing, programmatically driven usage of pay-on-demand resources put a significant part of your operating costs under direct and explicit control of your code. If you want to lower your computing costs by 10% next month, you can make a configuration change that will have exactly that effect, in the same way that you can change any other application parameter. Of course, this stricter constraint might affect the performance of your application in some way, there’s no free lunch, but the point is that the monthly cost is not a guessing game; it’s much more precisely controlled... What's true on the cost side may also be true on the revenue side. At the risk of stretching the definition of PaaS, an app store is a PaaS service, in the same way that an application hosting service is. And the line will blur. I would be very surprised if, as I type this, someone at Amazon is not working on better integrating their app store with their AWS platform, so that you deploy your app (its server side logic and its client side piece) to their infrastructure, the client side gets uploaded, via the app store, onto the user's Android/Kindle device, the server side runs on AWS and the AWS bill is paid by the app sales (hopefully with some leftover for you). And the charging model goes from one based on just app purchase to one based on consumption, as measured by the platform which hosts the server side.
Example 3: Everything is a platform
It is my contention that the "Platform" part of PaaS refers to anything that can be programmed. An application server obviously meets this definition, but there are many other things that can be programmed. Not a day goes by that something gets an API that didn't use to have one. This opens the door to PaaS including many different kinds of hardware. It's not just traditional computers. You can get GPUs and supercomputers (both of which Amazon offers today). One day you'll get to use observation or communication satellites by the hours via an API. Or maybe wireless spectrum. You can already access logistical services (a warehouse, transportation) that way. The line will blur. Ultimately, PaaS is not just raising the IaaS abstraction level by pushing the app server into the Cloud offering. It's about making all the useful resources programmatically accessible.
For a long time, the basic building blocks of IT have been simple: computers, storage and networking. It was the age of computer-centric IT. Everything else was the responsibility of the system administrator and out of reach for the programmer. IaaS made these resources available in a more flexible manner, but didn't change the nature of computing. In its first iteration, PaaS doesn't change the nature either, it just looks at the way people typically use these infrastructure pieces (install a database on them, install an application platform on them, etc...) and offloads that responsibility from the application owner. That has the important benefit of lowering the barriers to using the right platform tool for whatever task the application is accomplishing. But that's just the beginning of PaaS. PaaS is about to multiply the variety of IT building blocks, offering to the application owner access to resources that would be very hard, or impossible, for them to compose based on the traditional resources of networks computers and storage.
In the early age of PaaS (e.g. when Google App Engine entered the scene), you wrote applications differently for PaaS because you had to. The idiosyncrasies of PaaS were mostly driven by the need to make its delivery easy and cheap for service providers. We'll grow out of this. But we’ll do more than outgrow it by removing these constraints. We’ll transcend them. The ultimate goal of PaaS is not to get rid of the early PaaS limitation and to allow developers to do things in the way they are used to. It is to make developers write applications differently not because they *have* to but because they *want* to; because the platform services offered by PaaS are better than what developers had at their disposal before it. They’ll come with little incremental operational cost; they’ll provide access to a much wider range of services than those traditionally offered by an application server; they will provide direct control of cost and revenue parameters as part of the application logic.
The transition from machine-centric application design to PaaS is of the same magnitude as the transition from chemistry of simple molecules to one in which amino acids became available as building blocks. Applications are about to come to life.
About the Author
William Vambenepe is an architect at Oracle, working on application management and Cloud Computing. He blogs here and tweets as @vambenepe.