What is Serverless?
An Overview of Serverless Cloud Computing
Serverless computing is the most advanced and abstract concept in cloud hosting. But what exactly is it? How does it compare with IaaS and PaaS?
And is it really a panacea as some suggest?
Infographic: Journey to the Clouds | Data Driven Investor
Smart business leaders understand the value of utilizing the cloud. As data storage needs grow, as they have been…
Infrastructure and API
The first thing to understand is that serverless computing is a way to write code that executes in a non-developer managed context. The idea here is to offload as much as possible to the platform, leaving only the actual business logic to the coder.
The chief aim of the serverless code is to expose APIs. We are constantly building infrastructure to host API, but we really just want to expose the API and connect it to our business logic.
What’s an API?
Step back for a moment: what is an API?
An API is simply a join-point for code. We think of this as an API “surface”, in the hopes that code that is related will exist inside a contained area, interacting with other similar code areas via their surface.
In code-speak, we call this encapsulation.
API’s exist at every level of code, from classes and functions on up. What we are most concerned about here is network APIs, sometimes blanket referred to as “web services.”
There is a variety of boilerplate infrastructure that goes into exposing APIs. Not only do we need to provision and control things like network capabilities and file systems, but it also needs to be organized in a manageable way.
This point about managing service APIs gives rise to the wealth of frameworks and patterns we see in OSS: designs like the MVC pattern and frameworks like Django or Spring MVC are ways of structuring APIs while keeping dev hands off the boilerplate code as much as possible.
A couple of REST APIs are no big deal. But as applications and their inter-relations grow, the capacity to think about them and manage them effectively is compounded.
Complexity is the monster developers and architects do battle with most profoundly. Encapsulation and APIs are the primary weapons in that battle: the sword in the scabbard.
How does serverless computing fit in?
Serverless in Context
The idea is to allow code chunks to be hosted by a cloud platform. Let me finish this overview by doing a quick bit of web dev history. You’ll see how n-tier, IaaS and PaaS lead to serverless.
Before the cloud revolution, the primary way of organizing applications was n-tier: break up the app into a layer-cake of concerns. This is because the app itself was looked at as primarily a discreet chunk of deployable functionality, and the complexity was managed within the app architecture.
Developer Managed Infrastructure
In traditional web apps, the hardware, OS, software server and business code of the application were all in the hands of the people building the application: see figure 1 above.
The next thing that happened was IaaS: infrastructure as a service. This essentially virtualized the hardware and OS layer to the point where developers could manage these from a console or with code. Figure 2 shows IaaS.
Provider Managed Hosting Layer
Next up came PaaS: Platform as a Service, wherein the developer still deals with the software server that runs the app code, but hands of the deployment and interaction with the infrastructure layer to the platform. Figure 3.
Provider Managed Platform Layer
Finally, we arrive at serverless computing. Essentially, the developer no longer cares or deals with what is hosting the code. You just write the code and deploy.
Figure 4 has serverless.
Provider Managed Code Context (Serverless)
Now, that is high-level. That is the ideal.
If you sit down to create an AWS Lambda, Google Cloud Function or similar, you’ll quickly realize actually implementing a serverless app requires dealing with the API and infrastructure for hosting them.
It feels almost more like dealing with a different stack than dealing with no stack.
Disruption of Architecture
The most interesting point I can make in closing this overview out is this: serverless coding makes an internal impact to application architecture. It is a more fundamental alteration than what went before.
PaaS implies a stateless architecture for apps (because the replication and clustering of app nodes are handled by the platform, each app node must be ignorant of its state), but serverless architecture moves the decomposition of the application into surfaces into the network API level.
What I mean is: the application is distributed out across its service APIs. This is called decomposing the monolith: where the old-style app is known as a monolith for its structure that contains the entire application.
Microservice Risk and Opportunity
It’s called microservice architecture.
What used to be function and method level considerations are now architectural API concerns. Hence, the microservice label.
That is good in terms of allowing devs to think about the hosting of code less, however, it puts enormous pressure on the architecture of apps. The old conceptual framework is lost, and the surfaces of API’s becomes incredibly important and also, incredibly easy to lose control of.
As always, powerful new concepts in software dev are like chainsaws: useful but dangerous.
Careful with that chainsaw!