How to decide when to pass on PaaS
A changing cloudscape
Most forms of cloud computing are starting to find a place in mainstream IT delivery. Infrastructure as a service (IaaS), for example, is providing greater flexibility and better economy for those wanting to grab server or storage capacity from the cloud.
It might not be totally replacing other forms of infrastructure hosting but the offerings in this space are mature enough for prime time and provide significant advantages in many scenarios.
The delivery of business applications over the wire (or air) on a subscription basis via the software-as-a-service (SaaS) model is also now well established.
Whether it is in email, office or information management, or more complex solutions such as CRM or ERP, we are again some distance from world domination but mainstream use is clearly growing. We are certainly beyond the early adoption stage among larger enterprises.
Meanwhile, the picture with platform as a service (PaaS) is a lot less clear-cut. It is hard to make generalised statements because of ambiguity about what exactly PaaS is and where it fits.
Before we can have a sensible conversation about the role of PaaS in mainstream IT delivery, we need to quickly review some of its basic principles and variants.
The layer in the middle
A quick way of orienting yourself when considering the different categories of cloud services is to use a simplified, abstract version of the traditional systems stack as a reference.
Few would argue with this high-level model and the notion that PaaS generally sits between IaaS and SaaS in the stack view of the world. When it comes to the specifics, though, there is still a lot of disagreement.
Much of the marketing of PaaS is focused on hosted services and the notion of providing an application platform in the public cloud. Most of the big service providers tend to promote PaaS in this way, including Microsoft, Salesforce.com, Google and Amazon.
The functionality included varies quite bit but the basic proposition is to go beyond simply providing raw server and compute resources (IaaS-style) and deliver middleware and management capability as a service too – potentially everything up to but not including the business application.
Even then, there is some dispute about where IaaS stops and where PaaS begins. If the service provider makes a fully managed virtual server available to you, for example, including inherent resilience, elastic scalability and a console for deploying and migrating workloads, you could argue that this represents a pretty sophisticated platform, which some understandably regard as PaaS.
Others, however, say that such a service still doesn’t provide everything required to support an application and that true PaaS includes essentials such as app server, web server and database management capability at a minimum.
More comprehensive services also provide such things as authentication, access and security frameworks, workflow and business process management engines, application performance management, and even a full-blown set of development tools, APIs and associated libraries.
Indeed there are examples of services out there that tick all of the required boxes necessary to provide a self-contained environment in which applications can exist from cradle to grave.
Meanwhile, there is a camp that says the focus on hosted service is a red herring. The discussion that really matters is about architecture, the aim being to define a platform that can be installed in your own data centre as well as hosted by a third party.
The advantage of this is that the platform becomes delivery-agnostic, allowing you to mix and match on-premise and hosted deployments depending on business requirements.
Regardless of where you put the emphasis, though, the potential for lock-in exists. Application portability is obviously not a new consideration in the IT industry.
Those of us who were around in the 1980s, for example, are well aware of both the concept of application platforms and the work involved in porting an application from one platform to another.
Exploiting an integrated environment based on SQL*Forms, the Oracle relational database management system, and associated reporting tools saved a lot of time, but the resulting application was pretty much tied into that platform. Porting it to the Informix or Ingres equivalent usually meant a significant rewrite.
In the current world of PaaS, you are required to commit to a combination of platform components in a similar way. The difference is that there are arguably a lot more moving parts. Back in the 80s, your platform often ran in a single box, such as a VAX or some Unix-based mini-computer. Platforms in today’s world of distributed computing usually involve a whole landscape of servers and services.
Of course the whole point of PaaS is to shield developers and administrators from what goes on under the covers, but behind the scenes each PaaS implementation is based on a different set of mechanisms for accessing system resources, controlling application execution, reading and writing data and so on.
Industry and de-facto standards can help to isolate applications from some aspects of this but the reality is that each PaaS environment presents a different set of core capabilities, tools, APIs and associated technical constraints, which in turn affects the way you design, code, deploy and manage.
The upshot is that an application built for Salesforce’s Force.com platform is not going to run on Microsoft Azure, the Google App Engine or your custom in-house platform without a lot of work.
The trick for negotiating this potential minefield is to focus less on the technology aspects of PaaS and more on what you are trying to achieve.
The most highly publicised PaaS offerings provide a comprehensive environment for developing and operating web applications in particular. These are great if, for example, you are putting together a customer-facing website for which you cannot predict growth or fluctuation in demand.
Your application can scale up and down easily and (subject to terms) you pay only for the resources consumed. You also benefit from the provider’s communications infrastructure so you don’t have to worry about the mechanics of how users connect with your application.
Not surprisingly, tech start-ups often take advantage of such services but we are coming across more examples of mainstream enterprises and public-sector organisations building on this kind of PaaS too.
A good example is the Microsoft Azure based application that underpins the Love Lewisham programme, in which residents report graffiti, fly-tipping and other local eyesores by uploading pictures from their smartphones.
Entire new applications can be built and deployed
Hosted PaaS also commonly comes in the form of facilities that allow you to extend or customise SaaS applications. The market-leading hosted CRM solutions, for example, provide an environment in which entire new applications can be built and deployed, complete with graphical development tools for defining data structures and policy-driven forms and workflows, all wrapped up in a tight security framework and subject to version control.
In most cases, such facilities are available only to subscribers of the core SaaS services but some providers decouple the PaaS environment so enterprises and software vendors can build standalone solutions using the platform.
Largely speaking, this kind of PaaS is aimed primarily at applications deployed to your workforce rather than the outside world, providing an interesting alternative for weaning people off all that distributed DIY development (think Excel and Access).
This brings us to services that provide PaaS-like facilities, even though we would not normally put them into the PaaS category. Hosted collaboration services based on SharePoint or similar, for example, can be used to develop and deploy lightweight applications very rapidly by using the embedded data management, forms and workflow capability.
To complete the picture, at the other extreme some service providers are putting together hosted platforms that take some of the pain and cost out of developing hardcore high-performance computing and big-data applications.
Sometimes these are rolled into broader PaaS environments, as in Azure embracing Hadoop, for example, and sometimes they are presented as discrete services within a portfolio.
Do grow up
The hosted PaaS opportunity in a mainstream business environment at the moment largely revolves around discrete tactical application development and deployment.
Application portability and interoperability constraints probably mean you should think carefully before betting the farm on any single service or platform architecture until standards and commercial models mature a little more. Even then, the horses-for-courses principle will still apply.
Closing the loop on the argument about whether PaaS is about building a service-oriented architecture or delivering platform capability as hosted cloud services, the key is to think hybrid. Perfect portability can only come about if exactly the same platform is being run both in-house and in the hosted environment.
However some suppliers are getting pretty close by making sure the same (or very similar) APIs and tools can be used in both worlds. Either way, unless you are an independent software vendor interoperability and consistency of management is likely to be more important to you than portability.
Regardless of where you stand on the definitions, principles and practicalities of PaaS, our overriding advice is to think inclusively and in a service-centric manner. What you deliver in terms of functionality, usability and quality of service is always more important than how you deliver it. ®
Dale Vile is CEO of Freeform Dynamics