Everything Is PaaSible
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.
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
The Future of PaaS
the future is here today!
TODAY, WSO2 Stratos delivers numerous application platform service building blocks, and we believe architects should measure platforms today on the number, richness, and comprehensive value added by platform services. WSO2 Stratos is a complete application platform offering application hosting services, identity and entitlement services, business process services, integration services, rule services, presentation services, data services, content storage services, complex event processing services, mediation services, registry services, and service management services.
Re: The Future of PaaS
the future is here today!
Like, William suggests, various tools are available today, and the success of a PaaS strategy, is being able to pick a minimal set from the choices, to solve the business need, without having to commit to a single vendor solution.
"Applications are about to come to life!"
Agree with the overall gist of the article
However there is quite a gap between how enterprise apps are built today and what they need to be for a scalable, cloud environment.
The importance of language "support" and platform services
Interestingly, what most people don't realize, is that supporting new languages is directly at odds with the platform services value vector. Supporting all the languages under the sun, although a distraction from a time and investment point of view, also dilutes the richness of the platform services that can be offered. One of the things we realized at Apprenda is that deep runtime support *enables* the creation of the richest platform services possible. For example, if a PaaS were to offer something like deep call instrumentation to measure method level performance, that requires a fundamentally deep understanding of the runtime. I could go on and on about rich, runtime specific services outside of the language-agnostic "we provide load balancing for your app", which unfortunately, does not have staying power and is easily reproducible.
It is unlikely that a PaaS vendor can support a dozen languages AND provide platform services that are deep, rich, and difficult to replicate.
Re: The importance of language
That being said, most of the current mainstream "webapp" "runtimes" other than .NET and Java (not the language) seem to run in Apache. Additionally, most (including the JVM) seem don't seem to be limited to Windows or Windows tooling. Setting them up is as easy as expanding a compressed file.
Looking at the situation from a .NET perspective, I can see how you reached your conclusion. But IronFoundry seems to be working on a solution so that you can have one PaaS platform and support the majority. Is that as easy as just supporting only .NET and doing it the Microsoft way? No. But I have worked at many large companies and they need to support both Java and .NET. I work at one that does. If I can have one PaaS that supports both, that would be the best choice for the organization.
No. BTW and FWIW, Azure supports Java. :)