PaaS, or Platform-as-a-Service, is something that’s not used as much as initially predicted within enterprises. There are many reasons why. However, the core issues seem to be:
- Strong tools within IaaS providers such as Amazon Web Services (AWS) and Microsoft Azure seem to be driving interest in those platforms. While they may have PaaS as part of their platform, most developers opt for the core IaaS services, such as storage and compute platforms.
- Developers do not like to be placed within a sandbox. Many PaaS providers have restrictions, such as tools, databases, and programming languages, that developers typically don’t like.
- IaaS seems to be a better fit than PaaS for DevOps organizations, considering that they are able to replicate the platforms of IaaS providers, such as the ones that are on premises as well.
While PaaS offerings vary greatly, most provide facilities for application design, deployment, testing, and self-provisioned hosting. More advanced services may exist in the offering as well, such as team collaboration, database integration, middleware services, Web service integration, storage, state management, and version management services. However, these patterns are not at all consistent from PaaS provider to PaaS provider, and this leads to some major confusion in the emerging PaaS space, as well as amongst enterprises that are looking to implement PaaS.
At the heart of the problem is the fact that PaaS is today’s most ill-defined area of cloud computing. The approaches, features, and definitions vary widely, with many PaaS providers offering a specific focus. This may include support for specific programming languages, such as Salesforce.com’s Heroku, support for Ruby, Node.js, Python, or Java, or, perhaps tight integration with major databases, such as Oracle’s Cloud Platform. Others focus on a specific standard, such as Cloud Foundry. Most take their own propriety and closed approach to PaaS, no matter if they say they are following a standard or not.
Also, a dark side of PaaS emerged in 2016. Some consider PaaS too complicated and too limiting for most development efforts, and developers.
Most PaaS offerings put the developer into a sandbox, with only the features and functions that the PaaS provider furnishes to build and deploy applications. While this makes development an easy and controlled process, many developers need to gain access to the resources and tools required to support specific features, such as remote and native APIs, as well as middleware and database services.
This limitation may be a big problem for some developers, and not an issue with others. It does cause some concern. Many enterprises consider PaaS their new platform for application development, testing, deployment, and operations. It needs to do everything, and it might not.
On the positive side, PaaS does provide the ability to automate much of the development and deployment activities, as well as provide the developers with the ability to offer self- and autoprovisioning capabilities. This means that application developers can focus on the applications, and not have to deal with the purchase of hardware, software, and development tools. While this seems like an obvious benefit of cloud computing, self-provisioning is the core reason that developers choose to leverage PaaS.
The Market Speaks
As you can see by Figure 1, the growth of PaaS was predicted to be only a fraction of SaaS, and IaaS growth, just moving from $5 billion to $11 billion from 2013 to 2018, according to TBR. While that’s in proportion to the growth of the market, it’s well below the interest level for most major cloud providers and Global 2000 enterprises. Most analysts were predicting a 1/3 – 1/3 – 1/3 marketing position between PaaS, IaaS, and SaaS. That has yet to come true, and likely won’t come true.
Figure 1: According to TBR, PaaS growth will likely not provide significant traction, when compared to SaaS and IaaS, relative to market size (source: tbri.com).
The core message from this article is the fact that PaaS may have “Jumped the Shark” in terms of its viability in the market. The core competitor to PaaS is IaaS, and that technology seems to be more relevant to enterprises. Considering that most PaaS providers are investment-driven, the plug could be pulled on the smaller players, which means only a few providers, such as Google, Microsoft, and AWS, will continue to provide PaaS. However, their focus is clearly on their IaaS services, and they won’t focus on PaaS services if those services don’t serve their purpose.
Defining the PaaS Opportunity
PaaS providers all approach PaaS differently, but they all provide common sets of services. It’s important to understand these services before comparing PaaS providers for your own specific use cases.
Generally speaking, PaaS providers, while providing platforms for development and deployment of applications, are not to be confused with traditional development environments and toolsets. The focus when deciding to leverage PaaS should be focused on standardizing around a specific platform to promote productivity by using common development and deployment services, and the ability to streamline development, testing, staging, and deployment, in support of DevOps. Therefore, we’re talking about a change in processes (sometimes culture), as well as a change in technology, else the true value of PaaS is likely not to emerge.
I’ve defined PaaS as a set of layered services (see Figure 2), including database and infrastructure services at the lowest layer. Moving up you’ll find development and deployment services, as well as services in support of DevOps, including continuous delivery and integration. Finally, up to runtime services that deal with how applications are externalized to humans through user interfaces, or to other systems through APIs. Of course, security and governance services are systemic to most PaaS offerings, with varying degrees of functionality, depending on the PaaS provider.
The key message here is that enterprises should not avoid investing in PaaS, but they should be careful how they use it. A few years ago, it was common to find enterprises that had made a major bet with PaaS platforms, and have since switched over to IaaS. What scared them off was the idea of moving to a PaaS provider, including changing most of their applications, and then have that provider not invest anymore in the core PaaS services, or, worse, go out of business.
Enterprises consider all their options, in terms of how PaaS compares to IaaS, and what value exists in which platform. When the dust settles, we’ll find that, for all practical purposes, PaaS is leaving the market by 2018. You heard it here first.
Figure 2: While all PaaS providers are a bit different, there are some common patterns that have emerged (Source: Cloud Technology Partners).
Database services typically offer access to databases that are native to the PaaS provider, such as those offered by Microsoft, Google, or AWS. Or, in some cases, they augment a limited number of database options. The PaaS provider may access a database service that actually exists within a third party Data-as-a-Service provider. This allows the smaller players to claim additional database support, and thus keep up with the big guys.
In looking at database services, you should consider the number of databases offered, including traditional, noSQL, OLTP, and analytics focused. Also, how the database are integrated into other levels, including development and deployment services. Those that are tightly integrated are easier to use, as well as easier to change over time as requirements change. However, the tradeoff in leveraging the database services contained in the PaaS is a clear dependency upon that PaaS provider, and thus difficultly in the future if you want to move the data and applications to other systems or PaaS providers.
Infrastructure services are, in essence, everything you want to see in an IaaS provider, but in a PaaS provider. Again, the larger players such as Microsoft, Google, and AWS have their own IaaS services, and those serve as infrastructure services as well for their PaaS offerings. Smaller players, typically have the minimum amount of storage and compute services to support application runtime operations, and some provide deployment services to external IaaS providers, if that’s the desired target. Those with both PaaS and IaaS services seem to rise to the top, and this is a clear trend moving forward.
Development services typically include what you would expect, including support for a bundle of programming languages that are quickly expanding within most PaaS offerings. Also, code management services that are linked to configuration management, and a services catalog. Or, any other services required to build applications. Offerings from some PaaS providers, including Force.com, include deep support for mobile application development, and provide the ability to consider mobile deployment from development to deployment, and to runtime operations.
Deployment services includes testing, configuration management, application staging, and, once again, mobile deployment services. It’s at this layer that the application code goes through basic testing procedures, and is linked with a configuration management system, staged, and placed into production.
While we show the DevOps processes above the deployment layer, this is typically where the action occurs, in terms of continuous delivery and integration. Thus, the services at the deployment layers of PaaS providers are largely automated, perhaps even leveraging well known configuration management tools such as Chef or Puppet.
DevOps services, which are discussed below in detail as a disruptive vector, provide the automated processes to achieve “continuous delivery” and “continuous integration,” creating a dynamic link between those who are building the applications, and those who are deploying and operating the applications. The key feature of this layer is automation of these services, that allows for continual software releases for largely cloud-based applications.
Runtime services are everything you need to operate an application in production, including monitoring, tenant management, session management, provisioning, and scaling. The objective here is to keep the application working, and be able to dynamically adjust to an increasing or changing workload. Moreover, runtime services provide basic manage services, such as monitoring and logging, as well as use-based accounting, so those who need to provide chargeback and show-back are tracking that data as well. Finally, mobile runtime services are offered to manage mobile application operations out of the PaaS.
Death or Not?
So will PaaS die the death of a 1,000 cuts? PaaS technology will not likely have a death event, but will be absorbed into larger IaaS platforms even further than it is already. The likelihood is that Global 2000 enterprises will lose interest in the smaller players, considering them a bit risky and unable to keep up with the features and functions that they need. The larger players will do what larger players do, and the features and functions of their PaaS offering will become “systemic” to the IaaS platform. These include Google, Microsoft, and AWS.
So, this is really about the concept of PaaS. While the government defined PaaS in partnership with other industry players back in 2008, the likelihood is that PaaS will be one of those components of cloud computing that fades into the background. Thus, it’s not dead as per unavailability in the market, but dead in terms of the value that PaaS can bring to those who are building applications within cloud-based platforms.
This article originally appeared on IEEE Cloud Computing and is reposted here with permission.
