Cloud, English

Cloudless skies ahead with serverless?

Serverless. That certainly sounds like the solution almost every business owner has ever dreamt of. Time to send the entire IT department on a permanent sabbatical. So Long, and Thanks for All the Fish. Most people have an immediate association with the term, I certainly do. Is it correct though? Does serverless indeed provide cloudless blue skies? Have we already experienced the very last white Christmas? Will sunglasses be the new norm for system engineers, developers and devops alike? Let us explore the term serverless a bit together in this blog post.

Is this what cloudless skies will look like with serverless?
View of a serverless datacenter?

I’m sorry to break the news, it certainly is nothing like the word implies it to be. You are most likely not very surprised to find that out, I assume. So let’s talk about what serverless is. On it’s highest level serverless entails a continued abstraction of the Platform as a Service layer, where it combines Function as a Service with event driven workflows. I understand that this is quite the bit of terminology there. Let’s break it down in the paragraphs to come.

Historical overview of the road to serverless.
Historical overview of the road to serverless
Source: Serverless is More: From PaaS to Present Cloud Computing by @Large Research

Platform as a Service

So what is this Platform as a Service? It is the evolved concept of trying to hide infrastructure from the platform consumers. Representing the main platform consumers are the developers. Acting as go between business and infrastructure engineers. Creating a classical IT standoff, developers and infrastructure engineers clash due to conflict of interest.

The business holds the infrastructure team accountable for availability, performance and stability of the infrastructure. Exercising control over the infrastructure is what the infrastructure teams use to achieve those objectives.

The developers on the other hand are being held accountable to produce code which propels the business forward, deliver progress by releasing code. This causes the developers to have a progressive mindset. Which heavily conflicts with the conservative mindset of the infrastructure teams. And yes, this conflict of interest led to the invention of the devops role.

Given their opposing objectives it’s only natural for the platform consumers to have a conflict of interest with the platform maintainers. As such conflict has driven innovation and evolution. Bare metal servers led to virtualization techniques. Which led to the combination of self provisioned network and virtualization services known as Infrastructure as a Service. This led to further abstracting infrastructure into applications which can be consumed without interference from the infrastructure teams. The combined set of techniques is an evolution dubbed Platform as a Service.

Platform as a service lift off towards cloudless skies?
Platform as a Service example

To offer an example we can look at Nutanix Files. Files is a PaaS product which abstracts the traditional fileserver into an application. This application can be consumed by the organization as they normally would. However on the backend no servers are maintained, it’s an application which integrates directly into the storage layer. Because it is an application it is further extended with integrated anti-virus scanning, governance controls, deep analytics and plenty of more features. Thus this solution is offering enhanced value to the business due to it being offered as functionality.

Event driven workflows

Modeling software starts with defining workflows. What are the processes and what workflows go with them. Traditionally workflows are sequential and follow a predictable workflow. The execution path might branch, or loop, or wait for an outside event to occur, but in the end, the sequential workflow will use the activities, conditions, and rules provided to march forward. The workflow is in control of the process.

Now an event-driven workflow relies on external events to drive the workflow to completion. The workflow has to wait for an event to arrive before transitioning to a new state. Think of an even-driven workflow as a linebus service. We know the linebus has to drive from his starting location to his destination. However in no means are we in control how many passengers are waiting at the bus stops. Some stops we can skip, others we need to stop. If there is no-one, we need to wait until our time of departure is reached. If there is a passenger they may need to buy a ticket and so on. The events are triggering the workflow, event driven workflows.

Event driven workflows part of serverless
Example of event driven design

Function as a Service

Function as a Service is a Platform as a Service application which delivers the functionality to the developer to process developer coded functions. Combining these techniques and tying them together with an API gateway leads to the concept named serverless. Issues commonly experienced have to do with the latency. This is caused by the infrastructure spinning up the resources to service the functions.

An open source function as a service product is Fission. Which runs it’s entire serverless framework in native Kubernetes. Combine this with an event driven architecture and you have your serverless environment. Running on containers. Serviced by virtual machines within your virtualization infrastructure. On your bare metal servers.

Future of serverless

Serverless is currently often used in smart device scenarios such as energy meters. Non latency depend event driven workloads such as IoT is where you will find serverless applied mostly today. Expect serverless to gain further traction when quantum computing becomes more commonly available. With quantum computing we’ll be purchasing processing power in resource form, similar to the mainframe days. Then one day the availability of quantum computing will lead to Autonomous Coding Engines which in turn may lead us to a real Hal 9000.

Key take away

The key take away here is that serverless further decouples the code from the server infrastructure from a developer perspective. This allows the developer to focus his efforts on programming business logic instead of infrastructural logic. This does in no way mean that the underlying infrastructure disappeared, it is hidden from the developer. And with that it is hidden from the business. Maybe it doesn’t remove the cloud from the sky, it is still a concept which enables a deeper focus on actual business processes. So that means no cloudless skies are ahead of us with serverless, but it’s a very powerful concept nonetheless.