What is serverless?
Serverless refers to a cloud computing model whereby application developers don't have to provision servers or manage scaling for their app. Instead, those routine tasks are abstracted away by the cloud provider, allowing developers to push code to production much faster than in traditional models.
In short, serverless lets developers focus on their code, and mostly ignore the infrastructure. Hence "serverless" because the server specifications don’t affect developers. Of course, the servers do still exist—it’s just that they are managed by the cloud provider.
More specifically, a cloud provider (like Amazon or Google) runs physical servers and dynamically allocates their resources on behalf of a user (like yourself), who can deploy code straight into production. This may sound exactly like a public cloud Infrastructure-as-a-Service (IaaS) offering, but the key difference of serverless is that the provider only charges you for the exact compute resources needed to execute your code.
How does serverless computing work?
In a standard IaaS model, users prepurchase units of capacity, meaning you pay for “always-on” server components to run your applications. This is not the case in a serverless model. Instead, an event will trigger application code to run, then the cloud provider dynamically allocates resources for that code, and the user stops paying when the code finishes executing. In addition to the obvious cost and efficiency benefits, serverless also frees developers from routine and menial tasks associated with application scaling and server provisioning.
There are two primary methods of serverless computing. The first is through Backend-as-a-Service (BaaS), where a variety of third-party services and applications comprise your app. The second is through Function-as-a-Service (FaaS), where developers still write custom server-side logic, but it’s run in containers fully managed by a cloud provider. It’s also notable that you can build an entirely serverless application through these methods, or comprise an application of partially serverless and partially traditional microservices components.
Backend-as-a-Service (BaaS), also sometimes known as Mobile Backend-as-a-Service (MBaaS), is a method of serverless computing that relies extensively on third-party applications and services. For instance, a cloud-provider may offer authentication services, extra encryption, cloud-accessible databases, and high-fidelity usage data. These back end services are typically accessed with a call to an application programming interface (API) set up by the cloud provider, allowing simpler integration into your systems than developing these features in-house.
Function-as-a-Service (FaaS) includes a greater degree of control than a BaaS, since server-side logic is still written by developers. However, once it’s written, it’s deployed into containers that are managed by a cloud provider, which is the primary benefit of serverless. Specifically, these containers are:
- Stateless, making data integration simpler.
- Ephemeral, allowing them to be run for a very short time.
- Event-triggered, so they can run automatically when needed.
- Fully managed by a cloud provider, so that you only pay for what is needed, not “always-on” applications and servers.
What are the pros and cons of serverless?
First and foremost, serverless can increase developer productivity and reduce operational costs. By offloading the routine tasks of provisioning and managing servers, developers have more time to focus on their applications. This benefit is extended even further if entire application components are incorporated from a third party through BaaS, rather than being written in-house. Operational costs are reduced in a serverless model because you can pay for cloud-based compute time as it’s needed, as opposed to running and managing your own servers all the time.
Not running your own server or controlling your own server-side logic can have drawbacks, though. Ceding control of these aspects of your IT stack also opens you up to vendor lock-in. Cloud providers may have strict constraints on how their components can be interacted with, in turn affecting how flexible and customized your own systems can be. Deciding to change providers will also likely come with the cost of upgrading your systems to adhere to the new vendor’s specifications.
A container and Kubernetes platform for faster deployment of cloud-native applications.
A selection of runtimes and frameworks well-suited for developing cloud-native apps.