With new Serverless options available, it’s time to get on the bandwagon!
AWS Lambda has popularized that Serverless and Functions as a Service (FaaS) mean the same. With the rise of new serverless technologies like databases and containers, the term ‘serverless’ has broadened. Let’s boil it down to its true meaning, as it seems that no one can agree on a standard definition. Here’s how we at KintoHub think about serverless, and how you can leverage this hot tech.
Paying for compute resources
For decades we have been defining compute resources in a number of servers, as that was how you would procure the hardware. Cloud vendors have changed that by turning capital expenses (CapEx) into operational expenses (OpEx), through dynamically provisioning resources and charging for them by the hour or even second. Virtual machines (VMs) made that even more flexible by increasing the density of virtual servers you can run on physical hardware.
Yet you always have to pay 24/7, as you need to provision the resources, whether they are in use or not.
And that is what makes serverless different. You are no longer paying for the number of servers that you require, but based on the cost of operation down to the millisecond. If nothing is in operation, and the underlying servers are idle, then you do not pay anything.
Note; I did not say cost of execution. That would imply that the charging mechanism is always based per executed request, like it is with FaaS. The method of charging for serverless can be different depending on the type of technology, as we will see that later when we look into examples.
How you are charged for resources is much more fine-grained with serverless. Especially once your applications get variable traffic spikes, and that brings us to scaling.
Simplifying scalability
The cloud is known for offering the capability to scale up (better hardware) and scale out (more hardware). But scaling on demand is not as easy as it sounds. Most cloud experts will admit that configuring which factors determine how an application should scale requires time, knowledge, and experience.
Serverless has been designed for scale from the get-go.
A serverless platform has units to measure demand, and handles managing the underlying resources to process that demand for you.
The good news is that you don’t need to worry about these details with serverless. You can simply build your application based on these units, and the system will scale accordingly. The serverless platform handles the tricky bit of responding to changing demand.
That is why it is called a serverless platform, since something will need to respond and handle the processing. Moreover, the platform deals with the servers; configuration, provisioning, storage, networking, monitoring, etc. This allows you to focus on the code only, finally! 😌
Because the platform handles the demand response, it is capable to do that with great flexibility. The platform can pause or even hibernate the application when there is no demand. Or allocate automatically scale up and down server capacity unpredictable or burst demand. You no longer need to over-provision capacity.
With Functions as a Service, its unit of demand is obviously the invocation of a function. However, new serverless frameworks are emerging that use different types of units, let’s compare them.
Types of serverless
Before we dig into the various types, there is one concept that all of them have in common; state. Or rather, the lack of it; stateless computing.
Most of us have been taught to program with state; in-memory stores, session data, databases, n-tier, etc. However, state is the arch-enemy of scale, as it blocks the ability to distribute processing without the need to tie it all somehow together. Serverless forces us to relearn how to architect solutions that scale by leveraging stateless design patterns. Note; some platforms do support state, but suffer performance penalties when used with state. Keep that in mind.
Functions as a Service (FaaS)
It is the most familiar type, popularized by AWS Lambda, and replicated by others like Azure Functions and Google Cloud Functions. This type uses the invocation of a function as a unit. The frameworks for FaaS support specific programming languages, and avoid the hassle of managing language runtimes. You simply provide your code in the form of a function or method, and it gets executed within a context.
The context is restricted, and designed around the concept that the execution should be short-lived. This makes the execution of the unit predictable, and that allows the underlying resources to scale when many functions need to be executed.
Serverless Containers
Container orchestrators like Kubernetes have made it easy to manage a compute cluster to spin up containers and control the amount of replicas.
Virtual kubelet made it possible to rapidly expand beyond the default cluster capacity, and leverage serverless scaling for containers.
Frameworks like Knative and KEDA handle the process of scheduling new containers and stopping them depending on the demand. You can set what triggers the scaling, say the length of a queue, or incoming events. Now your application can easily leverage an event-driven architecture to scale on demand.
Serverless Databases
AWS Aurora Serverless and Azure SQL Database Serverless are examples where cloud providers have added serverless capabilities to their database engines.
The unit of demand for this type is the additional capacity charged per second. Moreover, you can completely shut down the database if your application scenario can accept a warm-up delay before the database resumes.
This is great for workloads that require the database to be available intermittently, or when the workload has variable capacity spikes.
Considerations before you go serverless
Now FaaS has been around for a while, there are some learnings that apply to these other types of serverless as well.
I’ve already mentioned that you should keep things stateless. Another consideration is that every serverless platform has some form of delay to execution, or cold start. The way these platforms save you money, is by not running anything when there is no demand. That also means that when demand rises, you need to instantiate more resources. We all know that this isn’t instantaneous, there is some initialization time to be aware of. If you need super low latency startup times, then you might be better off to over-provision with resources that are ready to go.
Another possible challenge is debugging. Whilst the serverless platforms abstract the underlying runtime, it also means you are at the mercy of how much control the platform gives you. This may change the development workflow that you’re used to.
That highlights the importance of logging, as this would be your primary way to show application output for debugging. Related to this is knowing what metrics the platform exposes for monitoring your solution. You want to be aware when a traffic spike happens, as this would directly affect the cost of running your application.
To summarize, consider the following:
- Stateless
- Startup time
- Ability to debug your code
- Logging
- Monitoring
MOAR! serverless 😁
It is great to see that there are more severless solutions available. It allows us developers to focus on our code, and remove the overhead of managing the infrastructure of the application. Serverless applies not only to functions, and now extends to general computing like containers and databases. This allows us to leverage the benefits of serverless across our applications. Go write some code!