Serverless computing offers a new way of designing and deploying applications using cloud services. But what exactly is it and how does it work?
In this article, we'll take a look at what serverless is, how it works, and how it affects the development experience. We will cover some of the advantages it offers and talk about some scenarios where it might not be appropriate. This should provide you with the background you need to do additional research and figure out if a serverless model might be a good choice for your projects.
Serverless describes a model where processing potential is exposed through an API instead of as an actual server. Applications can use computational resources to run code without managing the environment where it will be executed.
In many ways, serverless represents the next logical iteration by cloud providers of abstracting resources for users. Instead of offering virtualized servers to access resources, the provider offers access to the resources themselves using a pay-as-you-go model. Looking at it from a different perspective, serverless is a managed service (similar to managed database instances, for instance) for more generic computational logic.
The majority of the time, when people use the word "serverless", they are referring to serverless computing. Serverless computing is a paradigm where users can create functions, or computational logic, that will be executed by the provider when an API is hit. Because of this, serverless computing providers are often referred to as Functions as a Service (or FaaS) platforms.
When developing with serverless computing, you define the logic you want the provider to run ahead of time. Your application can be designed to utilize as many discrete functions as necessary. The functions are then executed on-demand as the application calls different code through the exposed endpoints. Any output or data generated by your functions is returned to the caller or offloaded to outside storage since the functions themselves do not maintain state.
As a developer, when working with serverless you do not need to worry about maintaining the environments used to execute your code. Additionally, this model provides flexibility in handling different volumes of traffic without having to manage scaling. The costs you pay are associated directly with the amount of computing power you use, so you don't have to estimate and allocate resources ahead of time.
Serverless databases apply the serverless paradigm to database functionality. In practice, this means that the backend server resources, scaling, data management is abstracted from the user. The user can use the database as an API-driven service that eliminates the need to plan capacity to handle different scenarios.
In general, serverless databases are implemented using a tiered architecture. The user is able to interact with an API or proxy gateway that handles the routing to backend resources automatically. Behind the gateway, pools of execution workers handle requests for any queries they receive. The actual data is maintained in a third layer, which any of the execution workers can access and manipulate.
With this model, both the computational and storage resources can be scaled independently in the background according to demand. The user does not control the scaling. Instead, they are charged for the queries they execute and the amount of data they are storing.
Now that we've talked about serverless is and how it generally works from a user's perspective, we can start to identify where serverless solutions are a good fit.
Serverless technologies are not one-size-fits-all solutions. While these new paradigms can simplify parts of the development, deployment, and management life cycles, they work best with certain types of workloads and application designs. Let's take a look at some of characteristics of applications and organizations that might indicate whether serverless might be a good fit.
A serverless environment may be a good fit in a number of scenarios.
If your team does not have extensive system administration experience, serverless offers a way to offload that responsibility. The infrastructure used to run your application code is maintained by the platform provider, allowing you to focus on your business logic. Eliminating infrastructure management from your list of responsibilities can help you get started quicker and maintain velocity as your project matures.
One of the primary motivators of developers moving to serverless platforms is closely tied to the previous point. Serverless architectures make scaling simple by removing it from your area of concerns. While your application may only require a few operations today, it might require more as you gain adoption or if there is a usage spike.
Serverless platforms can adapt to these scenarios automatically. This means that your infrastructure will never be over- or underprovisioned since the resource allocation mirrors your usage patterns automatically. You don't need to figure out your peak or average loads or test and configure scaling policies because your provider has already engineered solutions to do that for you.
As mentioned earlier, serverless platforms are also quite attractive if costs are a big concern. With serverless, you only pay for the operations you perform. You don't pay for idle servers that you need just in case they might be needed. This is helpful throughout the entire development life cycle. Your development and testing systems can use the same platform as your production system which helps you test more accurately without the costs associated with maintaining dedicated contexts.
The serverless model has many advantages, but it's not a good fit for every situation.
If your application is latency or performance sensitive, a serverless architecture might not be able to meet your needs. While serverless platforms can scale with your usage, there is a notable delay before the increased usage is recognized and the system is configured to handle the new demand.
This is frequently called the "cold start" problem and it affects the system any time there is a notable change in usage. This increased start up time rules out serverless for many use cases where consistent response times are required regardless of the previous level of activity.
You may also choose to avoid serverless platforms if you're uncomfortable or unable to work with cloud-based or vendor-specific solutions. If cloud-based infrastructure is not an option for compliance, privacy concerns, or as simple preference, using serverless platforms won't be an option.
Serverless platforms also represent a case of vendor lock-in, as your application becomes tied to the provider's implementation. While decomposing your application logic to a collection of discrete functions might appear to make your workloads portable, details in the way each service works is likely to prevent you from changing providers without a significant investment in migrating.
Lastly, serverless might not provide you with a lot of advantages if your team is already oriented towards managing infrastructure and working with the contexts provided traditional deployments. For instance, if you have a robust DevOps team managing infrastructure and services already, the advantages offered by serverless might not be as attractive.
Additionally, your developers might have expectations related to how they can test and debug application code that might not be possible or as accessible in a serverless environment. It may be impossible to profile functions deployed to serverless platforms in same the ways that developers do using traditional infrastructure.
It's important to consider all of these trade-offs when evaluating serverless for your projects. It's a great solution for some situations, but it's important to figure out if your use case is one of them.
In this article, we focused on explaining what "serverless" actually means and why it can be an attractive option for many projects. We talked about how the Functions as a Service model offloads the application server management to the platform provider and how serverless database offerings are able to decouple database operations from data storage. Afterwards, we took a look at which scenarios are most appropriate for serverless designs and when it might not be the right solution.
There's plenty more to learn when it comes to serverless applications, databases, providers, and designs. The following resources may be helpful as you continue to learn:
- Top 13 serverless computing and database providers
- Introduction to common serverless challenges
- Traditional databases vs serverless databases
- Serverless Glossary
- Martin Fowler's page on Serverless Architectures (by Mike Roberts)
- Cloud Academy's What is Serverless Computing: What are the Benefits / Trade offs
Serverless architecture is a way to build and run applications and services without having to manage infrastructure.
Your application still runs on servers, but all the server management is done by a provider.
A serverless application is an application that is build with a serverless architecture.
Your application does not require you to provision or manage any servers.
Because being serverless inherently cedes control of the infrastructure to the provider, they provide such security services as key management, authentication, and authorization.
Serverless security requires a change in mindset in how you view application security since security is not built around the application itself. Providers handle security around the functions of the application.
A serverless backend is the application of the serverless paradigm to database functionality.
In practice, this means that the backend server resources, scaling, data management is abstracted from the user. The user can use the database as an API-driven service that eliminates the need to plan capacity.
Serverless computing is a paradigm where users can create functions, or computational logic, that will be executed by the provider when an API is hit.
Because of this, serverless computing providers are often referred to as Functions as a Service (FaaS) platforms.