The PAAS Model
This is the first in a multi-part overview of serverless and native cloud technologies for beginners. This series looks at the origins of the PAAS model, at what defines serverless, what you can build with it, and what benefits it offers.
I'd like to start this series by going into what makes the modern cloud different from what came before. And to do this, we’re going take a brief side-trip into technology stacks and abstraction.
The example we’ll start with is the SQL interface for relational databases. The database technologies that preceded the modern RDBMS often required you to write low-level code to directly access physical data structures and to traverse indexes when querying for results. Now, with relational databases, you instead have an abstracted logical model with tables, attributes, relationships, and constraints. When you query data with this model, you’re able to stay within these abstractions, using the high-level SQL interface. You leave all the complex mechanics of constructing and executing a query plan and accessing the physical data to the underlying database engine.
Earlier generations of graphical user interfaces were similarly low-level. To get the interface you wanted you had to write a lot of code to calculate the size of elements and position them appropriately on nested hierarchies of components. Creating visually interesting magazine-style layouts with graphical elements, images, and flowing boxes of text was not feasible. Move up to today, and modern HTML and CSS standards make it possible to create complex visual designs and have them respond automatically to different device sizes. Using these standards, like with SQL, you can work with abstractions that are geared to content and layout. You express your intentions in high-level code, working with this model, and leave it to the rendering engine in the browser to figure out the positioning of each element down to the pixel level.
Now, I know these are not novel observations. But there are two points from this discussion will be useful for what follows. The first point is how each layer in a technology stack abstracts its internal workings, surfacing only what’s necessary for the layer above. The second point is that the form that this abstraction takes, or its model, is important. Ideally this model is aligned with what its consumer wants to achieve, whether that be querying data, designing a user interface, or as we’ll get into below, working with resources in the cloud.
The IAAS Model
Let's shift back to the modern cloud and the question of what makes it different from what came before. In the days prior to the cloud, if you wanted to run internet-accessible servers then you had to use an old-school hosting service. Using a service like this, when you wanted to launch a new "managed" server, let’s say, you would submit a request to the provider. On their side, the provider may have had some advanced in-house management tools, but as a user you never had access to these. You only had management access to your server instance via something like telnet once the provider had it up and running.
Then AWS came along. Even in its early stages when EC2 VMs and S3 object storage were the only services available, this was something different. Right from the start, as a user of AWS you had a web console through which you could directly manage your cloud resources. When you needed a new server, instead of having to submit a request and wait to be notified when it was ready, you could get on the console, browse the available virtual machine images, select one and configure networking and storage, and then launch it yourself with the click of a button.
In the data center this self-service model was made possible, first of all, by having pools of surplus resources available at all times. But it was also made possible my means of management software for those resources that surfaced all this functionality within an interactive model for end users. This is what made the modern cloud different from what came before. With this infrastructure-as-a-service (IAAS) model of the modern cloud, you have a control plane that abstracts the underlying infrastructure through which you can directly manage your computing resources.
This model is in essence a build-time equivalent for the cloud to what we saw above with the SQL interface or HTML/CSS standards. In this case, the control plane abstracts the underlying complexity of the infrastructure in the data center, and gives you a simplified model for computing resources to work with, either through a user interface like the web console, or through scripts or declarative templates.
The PAAS Model
The IAAS model is a remarkable achievement that has been incredibly impactful. It continues to revolutionize how infrastructure is deployed and managed throughout the software and IT industries.
However, if your role is to build the custom software that gets deployed on this infrastructure, then the IAAS model doesn't actually change things all that much for you. The IAAS model shifts where the computing infrastructure is located and how it's managed. But it doesn't really change anything about the software you build to run on this infrastructure.
To see real change in how you build software for the cloud, we need to look instead at the platform-as-a-service (PAAS) model. The IAAS model eliminates the need to manage hardware, leaving you responsible for tasks like installing system and application software on virtual machines. The PAAS model eliminates the need to manage even these layers, leaving you responsible only for configuring services or for deploying small units of event-handling code. Hence the “serverless” moniker, because with the PAAS model you literally don’t have to work with servers anymore.
More importantly, with the IAAS model, the abstractions you work with, like routers, subnets, virtual machines, or block storage, are all analogs of infrastructure resources that are well understood by network architects or server administrators. With the PAAS model, you work with abstractions that make sense to the developers and architects who build software. It defines things like functions that act as HTTP request handlers, or integration services that are analogs of middleware services familiar to integration architects, such as messaging, content-based routing, or orchestration.
In a nutshell, when using the serverless and native cloud services that make up the PAAS model, you are building solutions out of familiar software constructs, and then deploying these directly to (or on) the cloud without having to concern yourself about the infrastructure on which they run.
The Benefits for Development Teams
When adopting the PAAS model there is a learning curve compared to the IAAS model since it represents a paradigm shift, but it offers more long-term benefits. Let’s run through these.
First, serverless reduces the tasks involved with delivering solutions. As an example, let's say you want to deliver a backend API for a public-facing internet application? With serverless you no longer have to engineer the network layering and routing, deploy servers or reverse proxies, or set up auto-scaling. You just define the API, its endpoints, its security mechanisms, and its backing functions in declarative templates, and deploy them all in one step. This makes it much faster and easier to develop industrial-strength software.
So, a platform like this helps a development team to work faster. But serverless also eliminates categories of infrastructure work that require specialized skills often handled by separate teams of people. By eliminating a lot of this work, you not only reduce the effort involved in developing a solution; you also reduce the planning and coordination of work across teams.
Lastly, and this is something we'll dig into further in the fourth part of this series, the productivity payoff extends beyond this. A big problem with the software and hardware infrastructure on which conventional services run is that they have cost and capacity constraints. The result is that development and test environments for these services often have to be shared, and this sharing necessarily involves gatekeepers and additional planning and prioritizing complications.
When building equivalent services with serverless, you can take advantage of usage-based pricing and comprehensive build and deployment automation. Toghether, these cut the incremental time and cost for setting up a new environment to almost zero. Moreover, and this is big, you can reduce the need for gatekeepers by employing policy-based guardrails. This lets you systematize the gatekeeping function, defining up front what is or is not allowed in any given cloud account, which can subsequently be enforced automatically. This gives teams the freedom to stand up whatever permitted services and environments they need without management overhead.
What this all Means
I think you can view the IAAS model as the first generation of the modern cloud. It got us part way to where, as software developers, we would want to go. The PAAS model is the second generation that adds a layer on top of the IAAS model and gives us better abstractions for building software. This model, I think, more fully realizes the possibilities inherent to the cloud.
With some acquired skills, a software development team using PAAS services can be more self-sufficient. They can build solutions faster by leveraging serverless and native cloud building blocks. Using native cloud deployment tools they can deploy secure and massively scalable solutions and stand up nearly zero-cost environments, anytime, with a few keystrokes. These are advantages that you can't really ignore.
What's Next
In the next three parts of this series we’ll expand on what we've learned here. We'll look at what are the key attributes that define serverless services. Then we’ll see examples of what you can build with these services. And in the last installment, we’ll go into more detaila about the speed and agility benefits touched on here.