Serverless Computing
Focus on the applications business logic rather than the infrastructure
Disclaimer: I work for Serverless, Inc. which is the company behind various different Open Source and commercial offerings such as the Serverless Framework and the Event Gateway.
This is a living document which will be updated to reflect recent changes in the technological space. Feel free to comment below if you think something is missing.
Executive Summary
Serverless computing / serverless architecture is a cloud-computing technology in which cloud providers dynamically provision and mange compute resources based on their usage.
Serverless lets developers focus on the core business logic rather than managing and operating the infrastructure the code runs on. This in turn results in a faster Time-to-Market for the respective product and a lower total cost of ownership.
A serverless architecture follows the event-driven programming paradigm. The main building blocks can be categorized in functions and events.
Infrastructure components such as API Gateways, Databases or storage buckets emit events. Functions subscribe to those event sources and run their code once events are emitted.
Note: Serverless computing doesn’t mean that all DevOps related tasks such as monitoring, performance analysis, etc. can be excluded from day-to-day operations.
Characteristics
The following characteristics are noteworthy when talking about serverless computing.
Zero administration
It’s the cloud providers responsibility to do the heavy lifting behind the scenes in terms of of infrastructure management which means “zero administration” for developers.
Note that “zero administration” should be only considered in the scope of cloud infrastructure management and doesn’t mean that other administrative tasks are handled as well.
Pay-per-execution
The pricing-model of serverless computing is “pay-per-execution” which means that compute resources are only paid when they’re actually used.
A common pricing-pattern is to pay for resources on a per ms basis (e.g. per 100 milliseconds).
Never pay for idle
Since serverless is only billed on a per-usage pattern it also means that idle resources are not billed at all.
This can save big bucks if (web)applications have long idle times due to uneven traffic patterns.
Auto-scale
Applications built in a serverless fashion are auto-scale out of the box since the cloud provider takes care of the provisioning and management of compute resources.
Such auto-scaling capabilities are a blessing if the application goes viral and its traffic surges all of the sudden.
Event-driven
In a serverless world everything which can trigger a function is considered an event and the whole programming paradigm is therefore “event-driven”.
Events can have different shapes based on the resource which is emitting the event.
Business opportunities
How can businesses benefit when embracing this technology and going serverless?
Cost reductions
Getting billed for the execution time on a millisecond basis and never paying when specific functions are not used at all is a compelling reason to take a serious look at serverless architectures as a cost-saving strategy.
Different companies already migrated old, legacy APIs to serverless architectures or successfully gave serverless a spin while working on green-field projects.
Faster Time-to-Market
Having to care less about the infrastructure / provisionig of the application means more time to focus on the actual product and provide real value to end-users in the form of new or updated functionality.
“Always on”
Gone are the days when the pager wakes up an on-call engineer to fix a critical scaling issues.
It’s the cloud providers job to ensure that the functions are available and the whole application scales. No matter if there are 100, 10.000 or 100.000.000 users.
Limitations
The following are some common limitations which should be considered when evaluation serverless computing as a technology choice.
Stateless functions
Since functions are auto-scaled on demand there’s a need to make them share as little state as possible.
This means that state needs to be shared through other, external resources such as databases.
“Nanoservices”
A serverless application is a composition of different functionalities and therefore functions. Those functions are deployed one-by-one which increases the complexity to manage each of them individually as well as all the functions when thinking about them as a whole application.
Getting a solid understanding of the whole flow of information is harder to grasp compared to monolithic applications which are deployed and operated as a whole.
Timeouts
Time-consuming operations are not a good pick to be turned into a serverless function since functions do have a timeout limitation. This limit will ensure that subtle bugs such as an infinite loops won’t break the bank.
There are different patterns (such as the fanout pattern, where one function splits the task and invokes other functions) which can be used as a mitigation strategy.
Memory Size
Memory-intensive tasks are another area where serverless computing won’t shine that much. Memory sizes are usually restriced by the cloud provider.
However this restriction is rarely a show-stopper since most of the memory intensive tasks are better off handled by other infrastructure components / cloud provider services.
Cold starts
While “never pay for idle” introduces great ways to save money when the application is not used it introduces another price which is paid in the form of cold starts.
Cold starts are referred to as the time the cloud provider needs to spin up the functions runtime and load the code so that it can be executed. This usually only affects functions which were not recently used (usually in the last couple of hours).
Cold starts are real, but cloud providers are aware of this problem and are actively working on improvements to keep them as short and unnoticeable as possible.
Vendor lock-in
Building complex applications requires different pieces of infrastructure components and glue-code to knit them together. This ultimately yields to vendor lock-in which means that functions are usually written in a cloud provider specific way.
Serverless toolings mitigate this problem by introducing different abstraction layers on top of the respective cloud provider. This makes it possible to move functions around with as little code updates as possible.
Maturity
White still new, serverless computing was adopted by larger corporations and enterprises really quick.
The first cloud provider who offered hosted serverless capabilites was AWS. Nowadays other vendors such as Google Cloud, IBM Bluemix, Microsoft Azure and even different Open Source implementations accelerated the development of production-grade serverless applications.
Companies such as EA, CocaCola, Nordstrom, Expedia, Reuters and others already built mission critical software in a serverless fashion (source).
Real-world usage
The following is a list of different use cases which show how serverless computing can be used in practice.
Marketing websites
Marketing websites tend to have spiky and unpredictable traffic patterns, especially if e.g. an ad is used to drive users to the website.
Websites and webapps with such traffic greatly benefit from the serverless auto-scaling capabilities.
Data processing
The ability to chain different functions and infrastructure components together lets users create data processing pipelines which can range from simple database migrations to complex video transcodings.
One such example is a video transcoding pipeline where a movie studio uploads a raw video file into a storage bucket which then emits an event and triggers functions to transcode the video into various, different formats.
Chatbots
Conversational interfaces are a nice fit for a serverless architecture. Usage patterns tend to be pretty unpredictable which can result in lots of idle, but also heavy usage time.
Serverless computing got you covered whether your chatbot is quiet or pretty eloquent.
(Mobile) backend APIs
Traditional backend APIs (whether mobile or not) are another common use case for serverless architectures.
The applications business logic is spearated into different functions which reside on the backend while the apps frontend issues API requests against the exposed API.
Notable resources
Martin Fowler Blog Post
This in-depth blog post about serverless architectures covers all the noteworthy parts about serverless computing.
OpenEvents
OpenEvents is an initiative to establish a common description for event data across all the different cloud providers.
The goal is to offer the specification to the Cloud Native Computing Foundation.
The current specification can be found in this Google Document.
Serverless Working Group
The Serverless Working Group is the Cloud Native Computing Foundations working group to explore the intersection of serverless and Cloud-Native technologies.
The working groups whitepaper an be found here.
Related technologies
Here’s a list with technologies which are related to serverless computing.
- BaaS
- FaaS
- Containers
- Container orchestration
- Docker
- Kubernetes
