Many ways to define PaaS - platform as a service
- Summary:
- Like so many aspects of cloud computing, how you define PaaS in the enterprise is open to different and potentially misleading interpretations
PaaS sits between the two other 'aaSes' of the cloud computing stack, offering more functionality than bare infrastructure as a service (IaaS), while falling short of the finished, ready-to-run applications provided by software as a service (SaaS).
This broad spectrum contains so many different permutations that one vendor's PaaS can be very different than another's. What you might understand from having studied one particular variety of PaaS may be completely off the mark when you look at another.
Thus Oracle, for example, highlights the ability "to shift workloads between public, private, and hybrid clouds" as an attribute of PaaS in a recent research study on cloud agility. Whereas Salesforce is currently deepening the versatility of an application building platform that will only ever be available as a public cloud service. Meanwhile SAP seems to be moving towards offering several variations simultaneously as part of its Hana Cloud Platform.
A spectrum with two dimensions
All these different varieties currently co-exist, but are they all of equal value, or are some a better bet than others? PaaS is not only a spectrum, it also has two dimensions. One of those dimensions is currently very popular in enterprise IT — but it may be the other that ultimately delivers most value to the enterprise.
First, let's examine the spectrum in closer detail. PaaS, as we mentioned at the outset, sits between IaaS and SaaS. This is a huge landscape.
At one end of the scale, down at the infrastructure level, IaaS soon moves into PaaS territory when a provider starts to add operating systems and management layers. We can call this the 'IaaS-plus' end of the spectrum, where Microsoft Azure and several AWS services play. As we add more services, other providers join the landscape, such as Google AppEngine, Engine Yard, and others.
Conversely, at the opposite end of the spectrum, we have what we might as well call 'SaaS-minus'. Here, SaaS vendors have stripped down their applications to a core set of business functions and then added toolsets that make it possible to build a custom application on top of those core capabilities. This is how the Salesforce platform works and can also be seen in NetSuite's SuiteCloud or Box's platform strategy, among others.
In between these two extremes, the middle ground of PaaS is populated by any number of application-building platforms from a mixture of big names and startups. These include Apprenda, CloudBees, IBM Bluemix, Software AG's LongJump, Oracle Cloud Platform, Pivotal Cloud Foundry, RedHat OpenShift and many more.
Splitting the PaaS spectrum
A dividing line cuts across this center-ground segment of the PaaS spectrum, splitting it into two dimensions. The division is between those that offer customers the option of installing the software on their own servers, versus those that are available solely in the cloud. It all depends whether your focus is the platform itself or the as-a-service model under which it is delivered:
- Platform, as a service — platforms that can be deployed and run either in the public cloud or privately (or as a hybrid of the two), depending on the customer's choice.
- As-a-service platforms — platforms that are operated entirely by the provider in the cloud, with no option for the customer to host privately.
Enterprise IT currently tends to prefer the former of these two models. There are a number of reasons for this. First of all, most enterprises still run many of their IT assets on their own servers and therefore there's very strong demand for platforms that can act as a 'bridge' between public and private domains. As I wrote last year when assessing different approaches to cloud enablement:
Many see this hybrid arrangement as the ideal compromise for those uncomfortable about getting 'locked in' to a single provider. In the best examples, you still get the benefit of multi-tenancy when running in the cloud, because the PaaS is architected to dynamically reallocate resources when not in use (though others are less efficiently architected and would fail the NIST test for dynamic resource pooling at the application layer). At the same time, you always have the option of bringing your instance back onto your own servers if that’s what lights your lantern.
The other reason for its popularity is more insidious. It feels right because the model is so familiar — this kind of PaaS works just like an 'integrated development environment' (IDE) from the client-server days. Enterprise IT has always turned to packaged development platforms to more easily create custom applications that meet pressing business needs. No wonder so many traditional enterprise vendors are eager to deliver a new, cloud-ready version of the same old software. But the downside is exactly the same as I've described happening in the SaaS market:
Whereas vendors that come to SaaS from a client-server background bring with them a legacy architecture and installed base that they have to accommodate as they evolve their offerings into a cloud-native architecture, the pureplay vendors have not had to work within that constraint. That allows them more freedom to experiment at the leading edge of what’s possible ...
In the cloud, computing is evolving beyond the old client-server architectures into something new and ultimately revolutionary in its ability to support more agile, connected business activities and models.
My take
This is all about the dangers of horseless carriage syndrome — the tendency to look at new technology through the lens of what it is about to replace. The IT industry seems compelled to reinterpret cloud computing as a remake of how things have always been done in the past. And yet it never works out that way.
Of all the many different shades and flavors of PaaS, it is surprising just how many offerings are so similar in concept to the old client-server IDEs. They provide self-contained toolsets for application building and a choice of deployment options, both private and public.
In contrast, the pureplay, public cloud-only platforms are less numerous. But take note that they include some of the largest and most successful cloud vendors, such as AWS, Google and Microsoft at the 'IaaS-plus' end of the spectrum, and Salesforce at the 'SaaS-minus' end.
We're now starting to see some very interesting developments in 'SaaS-minus' PaaS, where instead of the traditional route of custom-building specialized applications on an IDE-type PaaS platform, vendors quickly build highly tailored industry cloud or specialized horizontal applications.
Salesforce has just revamped its platform to provide more versatile support for building applications customized to the needs of specific industries and customers.
Perhaps that's because the destiny of platform-as-a-service is not at all to offer a cloud-enabled version of the old client-server IDE but instead to offer one of two cloud-native options:
- Either a fully containerized, flexible platform on which to build brand new, continuous delivery applications;
- Or a highly customizable application platform on which to build industry-specific or domain-specific applications with all the agility and continuous functional update capability of the cloud-native SaaS model.
What's best for your enterprise — IaaS-plus, SaaS-minus or middle-ground PaaS? I hope that laying out some definitions has helped crystallize the decision factors.
Disclosure: Oracle, Salesforce and SAP are diginomica premier partners. Vlocity is funding the author’s travel to Dreamforce as part of a paid consulting engagement.
Image credit: Car transmission production © Marco Herrndorff – Fotolia.com.