PaaS Adoption Inevitable for Most Applications

Featured article by Derek Yoo, CTO and co-founder at Fuze

I am increasingly convinced that the eventual adoption of Platform as a Service (PaaS) offerings is inevitable for most applications even if the number of applications built on top of PaaS offerings is relatively low today. What do I mean by PaaS? Services that sit above the more traditional Infrastructure as a Service (IaaS) that most people today equate with cloud computing.

IaaS consists of compute, storage, and Network as a Service, and uses OS virtualization to move workloads to the cloud. An example is the AWS EC2 service. In contrast, PaaS consists of higher level software IaaS, an example being AWS Elastic Beanstalk. Elastic Beanstalk provides an orchestration service that dynamically scales your Docker-based application up and down based on load. In a lot of ways, this is a natural evolution of cloud computing platforms which started by delivering service at the bottom of the application stack, and platforms are moving their way up the stack quickly to offer higher and more abstract services that hide an increasing amount of infrastructural complexity.

Why is PaaS inevitable?

The fundamental driver is that it is cheaper in most scenarios to buy software IaaS versus running and managing it yourself. In my experience the long term cost of maintaining and scaling software infrastructure is almost always underestimated. As with many other things that can be bought as a service, it offers a way to focus available energy on the features that provide the most value to customers versus getting distracted by plumbing. Within larger organizations, this shows up in COGS and gross margins. As these companies scale, there is the constant push to improve margins over time. I anticipate most companies adopt PaaS in their applications to improve their margins and their ability to compete over time. As with other innovations that create efficiency, if you don’t adopt them, your competitors will, and will ultimately use that against you.

Interestingly, most startups already understand this. Startup environments are often leading indicators of what will happen in larger, more established enterprises over time. The trends show up first in startups because the capital- and time-constrained nature of those environments make them very quick to adopt the most efficient way of getting to the result. When I ask the startups I meet with where their ops team is, they point me to the lone AWS guy they have, or just simply answer “we use Heroku.” I started my career in IT ops, so this is still a little difficult for me to understand. I immediately want to ask how they monitor, backup, scale, deploy changes safely, etc. The point is that many technology startups offload as much of the IT infrastructure as possible and the developers themselves typically worry about the operational aspects of the topmost application layer of their software.

Is using PaaS offerings actually cheaper than doing the whole thing on-prem or managing software on top of cloud-based IaaS?

To explore this question, let’s take a specific example: a NoSQL data store. The on-prem version will require servers, storage, network, virtualization, OS, software (e.g. Cassandra), and network/systems/database administrators. A software on IaaS scenario eliminates the servers, storage, and network, leaving the software and database administration (e.g. AWS EC2 + EBS + Cassandra + DB administration). And the PaaS scenario eliminates even the software and administration components (e.g. AWS DynamoDB). Take a look at this TCO analysis from Amazon for these three scenarios. Their analysis argues for increasing ROI as you move from on-prem to software on IaaS to eventually PaaS. The on-prem versus IaaS ROI is fairly straightforward and I don’t think a lot of people will argue that point. But the interesting part for me is the difference between the software on IaaS and PaaS scenarios – and the difference is always underestimated, in my opinion. All of the human labor must be heavily factored as an advantage to PaaS adoption: in this case, manpower that goes into backups, clustering/ring setup, monitoring, regional redundancy, performance analysis, configuration and tuning, etc. In this specific Cassandra example, there are numerous things to consider just to properly setup an instance in AWS.

For most uses, the PaaS scenario will be the most cost-efficient option to choose if you were starting the development of a new application that needs to be scalable.

But, there’s another thing worth noting.

There is a point when you reach a scale where it may make economic sense to bring everything back in-house. It’s safe to say that most companies will not hit this scale as part of their normal operations. However, there are some highly visible examples of this. I read an article in WIRED with some interest earlier this year that Dropbox – having run its service on AWS since the beginning – had spent the last couple years migrating off of AWS. Their in-house solution features custom storage hardware and software. It’s a good reminder that PaaS isn’t an end in itself. The underlying drivers are economic forces and the best approach may change depending on scale. Most of us, however, will not be dealing with Dropbox scale storage requirements and can use something like S3 to meet our needs.

The Slow Rise of PaaS

A question worth asking is this: if the economics of a PaaS approach are so favorable, why isn’t adoption happening faster?

I think one reason is that application architectures are hard and slow to change. Many existing apps have monolithic architectures and are running fine in non-PaaS environments. It takes time, significant investment, and effort to evolve application architectures to take advantage of these new PaaS offerings. Microservices-based architectures will enable the adoption of PaaS offerings by allowing developers to change the implementation of a service from non-PaaS to PaaS, while keeping the interfaces to that microservice the same and minimizing impact to other parts of the application.

A second reason for slower PaaS adoption is that, for established organizations, the adoption of PaaS often has significant implications for the existing IT operations staff who are responsible for managing the existing infrastructure. Organizational structures will need to evolve to align with PaaS-enabled application architectures. A lot of the IT operational work currently being performed within the enterprise will in effect be outsourced to the PaaS providers.

Despite these headwinds, the underlying economic efficiencies to be gained by PaaS adoption means that PaaS platforms will undoubtedly continue to gain users and importance. As new apps are launched and older ones re-architected or retired, I expect to see continued PaaS market share growth. As this is happening, an easily missed point is that these PaaS services are highly sticky for the platform providers. With IaaS, you can move workloads around to different providers fairly easily; with PaaS, the services and APIs are all unique and only slowly becoming standardized with the adoption of technologies such as Docker for application packaging. An application using PaaS-specific APIs becomes a lot more difficult to move between different PaaS vendors.

Moral of the story? PaaS adoption is only going to continue to grow: when selecting a PaaS partner, choose wisely and for the long run.

Derek is co-founder of Fuze and responsible for the strategic vision, development, execution, and ongoing operation of Fuze’s innovative cloud communications ecosystem.