Netflix Built a PaaS... Why Can’t I?

The main benefit of cloud is the ability to consume some type of resource “as-a-Service.” The resource could be infrastructure (IaaS), platform (PaaS) or software (SaaS). The IaaS and SaaS spaces have been more or less stable for the past five years, largely because there’s broad consensus on what these offerings look like. Ask 10 people what an IaaS solution looks like and you’re likely to only get one or two different answers. Ask 10 people what PaaS solution looks like and you’re likely to get 15 answers.  

The goal of PaaS is to offer a foundation for your application. A PaaS solution is supposed to offer most if not all of the runtime platform (including infrastructure) for your code or deployment artifact. When done properly, PaaS is great – you worry about your code and someone else worries about everything else. A security vulnerability in the operating system your PaaS vendor uses? That’s for your PaaS vendor to deal with. A hurricane has flooded your PaaS vendor’s data center? Again, not your problem. Fundamentally, the use of PaaS reduces the scope of what you have to care about. You just care about your vendor hitting agreed upon service level agreements. The rise of DevOps and microservices is increasingly making pager duty a facet of modern development roles. Reducing the scope of what you have to care about is often the difference between being up all night troubleshooting an issue in production and you getting a full night of sleep.

The challenge with PaaS is that nobody can agree on the scope of what a solution should look like. On one side of the spectrum, often championed by IaaS vendors, PaaS solutions are basically ops-level “wiring” of disparate layers with no vertical integration between any one of the layers. This approach offers great flexibility but it comes at the expense of vertical integration, which is key to automating lifecycle activities like backup, restore, patch, etc. IaaS vendors can’t vertically integrate because they don’t own any of the upper-stack software – they’re infrastructure vendors, not SaaS vendors or ISVs. On the other side of the spectrum, often championed by SaaS vendors and ISVs, PaaS solutions are tightly integrated vertical stacks of hardware and software, where you just bring your code. SaaS vendors and ISVs own the upper-stack code so they can offer you a vertically integrated experience for a particular stack. While this approach offers relatively less flexibility, it does give you a better experience because common lifecycle activities are often handled entirely by the vendor, or are available to you with the push of a button. It’s a tradeoff – do you want flexibility or a better lifecycle experience?

PaaS has not taken off in the way that many have expected because evaluating PaaS solutions forces organizations to make difficult decisions about their development philosophy, technology choices, and the role of operations vs. developers. This often leads to deadlock and continuing with the status quo, which is often just plain IaaS. Any PaaS is better than plain IaaS. For example, here are the activities that are done for you by a good IaaS-based PaaS that you would otherwise have to do by hand if you were only using IaaS:

• Identify what software to install, including OS-level package dependencies
• Prepare the operating system for the installation of software - environment variables, kernel changes, etc
• Download software, verify integrity
• Install software
• Scale up/down/out/in

Automating just these handful of steps offers excellent cost savings while not restraining choice all that much. It’s a great first step.

A good vertically integrated PaaS offered by a SaaS vendor or ISV goes farther and can do things for you like:

• Open ports in the firewall
• Install monitoring and logging infrastructure
• Cluster each tier as appropriate
• Register with the load balancer
• Identify which patches to install
• Download patches, verify integrity
• Back up each tier, all at the same point in time
• Securely write backups to storage
• Install patches
• Re-hydrate backup from storage

Performing these activities requires extensive vertical integration, which only SaaS vendors and ISVs can do. As long as your software stack matches the PaaS vendor’s stack, you’re all set. Vertical integration is key to reducing operational complexity. And wouldn’t you rather be innovating rather than patching?

Developers don’t like technology decisions being made above their heads that they have to live with forever. That’s understandable, given they often have to live with the consequences of others’ (often poor) decisions. Now that cloud buying decisions are often being made by developers, they have choice or a say in which PaaS solutions are chosen. What matters for business is that developers are using some kind of PaaS. Developers don’t have to be using the same PaaS but they should at least be using one.

You can, technically speaking, build out your own PaaS using IaaS + DevOps tooling. To build your own PaaS, you have to define scripts to provision infrastructure, install software in each unit of compute you provision (VM, container, etc), and then integrate each tier to work together. Then you have to write additional scripts to handle lifecycle activities like backup, restore, patch, etc. While it will most likely work, and you may get to thumb your nose at all of the PaaS vendors, you have to weigh the up-front cost savings with the time it takes you to build, test and maintain scripts for: provisioning infrastructure, installing/configuring the software, integrating all of the different tiers to work together, scaling up/down, backup/restore, patch, and so on. Maintaining all of these scripts can end up being more effort than maintaining your application.

Building a custom PaaS is perfectly feasible for the few organizations out whose business is technology. Facebook, Google, Netflix, etc spend lavishly on technology because technology is their business – it’s not just an expense. These companies have just a handful of large customer-facing applications, so it’s feasible to build out a PaaS stack for each application. The vast majority of other businesses in the world are not in the business of technology. They’re in the business of insurance, healthcare, manufacturing, or the hundreds of other disciplines that make up the “physical” economy. They spend a few percent of their gross revenue on technology and the cost is largely classified as an expense – a cost center. Normal companies have dozens if not hundreds or even thousands of small “point” applications that keep their business running smoothly. These are applications that are critical to keeping a business running smoothly but are not applications that any company will use to differentiate themselves. You won’t find a transportation company bragging about their payroll system at a conference. That’s why most of these applications are bought from ISVs. Building out a PaaS system for these smaller point applications rarely ever makes sense when you look at all of the costs involved. Skilled labor isn’t cheap.

PaaS solutions exist on a continuum of the level of vertical integration. PaaS solutions can be bought or built. Unless you’re Netflix or one of a handful of others out there whose business is technology, think about buying your PaaS solutions, preferably with tight vertical integration. Let the PaaS vendor deal with the tedious work required to keep your applications up.

About the Author

Kelly Goetsch is a director of product management at Oracle, with responsibilities over several of Oracle’s PaaS solutions. He is the author of eCommerce in the Cloud (O’Reilly, 2014) and has written extensively on large-scale distributed web architectures. Oracle Cloud is a comprehensive, integrated suite of services that make it easier for developers, IT professionals, business users and analysts to build, extend and integrate cloud applications.