Serverless architecture is a way of building applications without deploying servers or even spinning up cloud instances. Instead, all you need to do is write code and push it to a serverless platform in the cloud. This doesn’t mean there are no servers involved. And at the bottom of every stack, there is still a physical machine.
The difference with serverless architecture is that you don’t have to think about traditional server management (or virtual machines, containers, or another traditional unit of infrastructure). This may seem concerning to the traditionalist, but it’s not that radical; developers haven’t had to think about logic gates in processors for a long time. Serverless computing represents an evolution moving the abstraction up a layer. Instead of worrying about the underlying infrastructure, developers can focus on solving business problems with code.
When you deploy code with serverless computing, you’re not setting up a server or deploying an instance. When your application takes off, there’s no need to deploy additional servers, virtual machines, or containers - a serverless architecture scales seamlessly with usage.
Naturally with serverless computing, this also means that costs scale with usage, and cloud infrastructure is already usage-based. With traditional server management (Iaas - Infrastructure as a Service) you are buying a server for a high price upfront. There are some immediate drawbacks to this:
You’re paying for the instance as long as you have it up, whether or not it’s doing anything
Scaling is typically manual - you need to keep an eye on usage and scale the instance up or down as needed
If you do need to scale, it’s a stepwise function to the next instance - it may be 30% bigger (and 30% more expensive) when you only need 1% more in the short term
In contrast with serverless, the costs move in lockstep with usage. When nothing is being executed, you don’t pay for anything. As actual usage goes up, the costs go up along with it. Different serverless platforms have different units of cost - they might call them request units, or compute units, or something else - but they’re typically based on compute usage (memory and/or time), number of requests, data transferred, or some other combination.
Serverless is an efficient way of using and paying for services, while focusing on the important parts of development. Instead of spending your time worrying about capacity or planning an instance tier upgrade in advance, you can just write your code and let it run at the necessary scale.
So we have a general definition of serverless: an architecture where you don’t need to think about infrastructure. But what does that mean in practice?
There are several different major categories that fall under the umbrella of serverless. The divisions between them aren’t hard and fast, but it’s useful to look at a few different areas.
FaaS is serverless architecture applied to application logic where each logical function is an individual unit. Your code is deployed to the FaaS. When a function is called, the service instantiates it in a container where it runs as required producing the appropriate output. When there’s no more demand, the container is torn down and the code only runs when needed. Since FaaS is pure compute it’s sometimes referred to as serverless compute or serverless computing, though those terms are also used more broadly.
Because instances aren’t always running, FaaS can have what’s called the cold start problem. If a function hasn’t been called for a while, a response can have an extra wait time while the instance is set up. As long as there’s continued usage, the infrastructure stays up and the latency is shorter. However, if a long enough time goes without the function being used, the instance is removed and the next call will have a cold start.
Functions are also stateless since their infrastructure is ephemeral. If a function needs to retrieve or store state it needs to do so elsewhere, usually in a database.
The most common FaaS is probably AWS Lambda (named after Lambda Functions). The other cloud vendors have FaaS platforms called Google Cloud Functions and Microsoft Azure Functions.
MongoDB Realm’s Functions are also FaaS, within the context of a broader serverless platform.Realm Functions, however, are optimized for low-latency application requests avoiding the cold start problem by running functions in pre-provisioned containers.
Where FaaS lets you run pieces of code serverlessly, a Backend as a Service runs the full backend of an application. BaaS platforms provide simplified architectures for applications, usually web applications or mobile applications. The service hosts your entire backend application removing the need for an application server. Clients connect to the BaaS, and the BaaS connects to a database (or may have one built in). If the application backend needs to scale up or down, the BaaS handles it automatically.
Some Backends as a Service are fully serverless scaling infrastructure and cost precisely with demand. Others don’t have a complete serverless architecture approach. For example, there may still be the concept of instance size or there may be an hourly charge even if there is no usage.
Development approaches differ in different Backends as a Service. Some may use a FaaS approach of multiple code snippets, while others may have the full backend application code uploaded together. Many recommend that you use built-in services where available instead of writing your own, e.g. an authentication service, a notification service, or an image recognition service.
Like a BaaS, MongoDB Realm can be used as the entire backend of an application.
Serverless databases are relatively new. They’re an expansion of the serverless paradigm beyond the application layer where serverless architecture is more common.
To start, a Database as a Service (DBaaS) is analogous to IaaS. The database is fully managed for you but it’s deployed as a specific instance size with a specific price. MongoDB Atlas is a Database as a Service; it has specific instance sizes and you can adjust the storage, memory, and other characteristics.
A serverless architecture for a cloud database means that you don’t choose an instance size at all - instead you simply set up a database. It grows as necessary with data size and with throughput and the cost scales alongside. This is still a relatively unusual structure for databases as of now.
While MongoDB Atlas has some elements of serverless architecture - for example, the ability to auto-scale based on workload - the explicit instance sizes mean that it’s not what would normally be called a serverless database.
Many cloud services could be thought of as having a serverless architecture even if they’re not one or the normal categories of “serverless”. For example, Twilio is a popular text message service and you want an application to send texts, all you need to do is call the API. There’s no need to build your own messaging service – and no need to scale it. Whether your application sends a few texts or a million, Twilio handles it and charges you accordingly.
Cost: because costs scale very closely with usage, you’re only paying for what you use and you’re never charged for infrastructure sitting idle. On the other hand, you should make sure you understand the pricing model - as usage increases you may find your costs escalating quickly.
Elastic scalability for resilience: your backend scales on its own, totally transparently, without any work on your part. If you get unexpected peaks in usage, the system handles them without any intervention on your part providing scale when your users need it most.
Rapid iteration: with no infrastructure to set up and no dependencies on other teams, working with serverless architecture can get you moving quickly. Working with a platform that has built-in services for certain requirements can also save you the time of building your own.
Lower administrative overhead: as with most cloud services, serverless platforms take up much less of your time in managing operational tasks.
Developer productivity: by focusing on the core business logic that sets your application apart, you can spend your time writing the code that matters.
You should consider a serverless architecture in any of these scenarios:
You don’t know what scale of workload to expect
You want to minimize costs as much as possible
You want to avoid infrastructure management as much as possible
Your application logic can be broken apart into discrete functions
You want to host an entire application backend on a managed platform
You need a small piece of custom functionality in a workflow of other services
You want to connect a large number of end devices to a backend - for example, mobile or IoT
In fact, these scenarios apply to most modern applications. So if you start by considering serverless, when does it not make sense? If you’re not already on board with the cloud, or you need to control your own infrastructure for regulatory reasons, serverless obviously isn’t a good choice.
As always, you should investigate a serverless platform carefully to confirm that it meets your requirements for latency (i.e. minimal cold start issues), security, and so on. And generally, most serverless platforms have specific patterns of development built in, so make sure you like this way of working before you commit.
Serverless - especially the FaaS approach - and microservices have some similarities.
Both are basically architectures that break application code into smaller components that communicate with one another, with databases, and with other services. There are a few key differences between serverless architecture and microservices:
You can think of microservices and serverless in terms of an evolution upwards in abstraction. A long time ago, servers were physical hardware managed on-premises, and applications were monolithic code bases.
As the cloud landscape has grown, many organizations stopped managing hardware and started managing instances instead, while monoliths are increasingly being replaced by microservices, moving the development abstraction from “application” to “service”.
Serverless is an evolution in both infrastructure management and software development, removing infrastructure entirely and moving to a development mindset focused on data and functions.
In a serverless architecture, what triggers a function? More often than not, it’s what we would call an event: an atomic occurrence in the application (or in the real world). For example, every time a user signs in to our application, we want to do a handful of things: log the sign-in, retrieve the user’s profile information, check if there are any new offers, etc. We may design/construct this with serverless functions and events:
The login attempt triggers an authentication function.
If successful, it creates as output a login event, which goes into a queue.
That login event is picked up from the queue, triggering the user profile function, the offer function, etc.
An event-driven architecture can be used to coordinate either microservices or serverless functions.
MongoDB Realm is the serverless platform for MongoDB. Realm lets you build applications with a serverless architecture, coupled with MongoDB Atlas, the global cloud database. Realm’s application development services include:
Functions: implement application logic, securely integrate with cloud services, and build APIs
Triggers: execute functions in real time in response to changes in the database or other events
SDKs: gain the full power of the MongoDB Query Language, calling the database directly from your frontend code
Access Rules: declare fine-grained security policies for which users can access which data
Static hosting: host and deploy web assets such as images, audio, HTML, and CSS files
GraphQL: quickly build apps using the groundbreaking API query language
MongoDB Realm is part of MongoDB Cloud, the unified data platform for modern applications. Your new cloud account will get you started with a free tier cluster in MongoDB Atlas and a free tier in MongoDB Realm. You can get started building a serverless application right away.