Serverless Architecture: What Is It & How Does It Work?

“Serverless architecture” is a somewhat misleading term in that its software applications rely as much (or more) on servers than ever before. What distinguishes it from other methods is not how it gets rid of servers but rather how it gets rid of their burdens, letting developers focus on implementing their great ideas rather than reinventing the wheel.

When software services are delivered as an application programming interface (API) in the cloud, scaled automatically, and priced based on usage, they are known as “serverless services” because their users don't need to manage the server infrastructure. New Software as a Service (SaaS) applications are being reimagined as Internet-compatible APIs that deliver an ever-expanding variety of different services with usage-based pricing. Payment (Stripe), search (Algolia), communication (Twilio), logistics, order management, 3D printing—you name it—are all becoming APIs available to servers (or microservices), mobile applications, and browser applications.

Serverless architecture applications “glue” existing functionality together by leveraging various components and relying on third-party cloud service providers to shoulder all the server-side burdens. Such providers do the work of provisioning, maintaining, and scaling functionality, while developers can focus on creating new business value.

In the remainder of this article, we’ll offer reasons why serverless architecture is sometimes preferable, discuss the components used to build serverless applications, describe some good use cases, and provide examples for systems built using serverless architecture.

Hosting a software application using the Internet has traditionally required server infrastructure. Whether running directly on the hardware or in virtual machines, such infrastructure involves significant work and costs for equipment, personnel, and all the time involved. Somebody has to be responsible for providing the hardware, installing operating systems, and subsequently managing and maintaining it through various updates and patches.

In contrast, a serverless architecture immediately provides obvious competitive advantages. Leveraging serverless services supplied by others means no more buying hardware that will be obsolete before it's paid off, no more burdens configuring or keeping it working. Consumers pay only for what computing resources they use. These benefits have proven too powerful to ignore, which is why so many contemporary software development projects are trending this way.

What used to be the “service layer” in multi-tiered applications of the past is increasingly outsourced today via third-party serverless services or APIs. Whereas server-side developers previously built all the back-end functionality, exposing it internally (and sometimes externally) via well-defined interfaces, the Internet has made it easier for developers to avoid this work by leveraging cloud services instead.

Organizations that previously relied on proprietary interfaces today have incentives to adopt open standards so that applications can be built upon consistent APIs for common functionality. For example, applications can leverage APIs to send an email, update calendars, store data, process data, share with social networks, and all manner of other functionality. It is increasingly the case that developers can avoid reinventing the wheel and rely on what others have already built.

A commonly discussed component of serverless architecture is “Functions as a Service” (FaaS), which is a bit different than consuming APIs yet shares much of their convenience. Whereas using an API is typically nothing more than a web service call or simple HTTP request, FaaS offerings let the developer string together “small,” highly-focused bits of code to achieve larger goals.

In a sense, today’s FaaS offerings are the modern analog of old-school shell scripts, batch files, and the like. In an old-school server environment, a “cron job” might kick off a shell script that downloads a file via the FTP protocol and runs its contents through a piped series of command-line tools to massage data before sending output to its proper destination. Today, web-based triggers can instead activate AWS Lambda functions or Azure Automation processes written in various languages to perform similar tasks.

Thus, FaaS offerings are usually a bit more complicated to leverage than simple API calls but offer greater customization, letting developers hand-craft the code that executes. Developers can focus on building the various bits/bobs and connecting them without worrying about the servers they run or what might already be performing in the background. You can learn more about popular FaaS services and compare in this article.

Extending the analogy of FaaS to data, another component for serverless architectures is the “Data API.” Most applications need to store and manipulate operational data, which has traditionally meant working with one or more database servers. Today, using services like Fauna, developers can instead choose to handle operational data through cloud-based data APIs, avoiding all the burdens of owning, hosting, and maintaining such servers. It’s up to the providers of serverless Data APIs to handle all the back-end server infrastructure. The application developer simply provides credentials and connection details to access the Data API and is billed only for the storage and processing power. As such, “Data APIs” can offer considerable savings in development time, operations staff, etc.

While there are a variety of different types of applications that work well with serverless architecture, variable-load web applications. It’s one thing to build something for a company intranet with a relatively constant load of dozens, hundreds, or even thousands of users. But it’s an entirely different ball game when you’re on the public Internet and could potentially swing from dozens to millions (or more) simultaneous users in minutes.

With a more traditional architecture, it can be a frustrating, even maddening, exercise in balancing priorities: minimizing costs against maximizing capacity. You need sufficient hardware and software infrastructure to ensure customers aren’t left waiting so long they take their business elsewhere. And even if you find that perfect sweet spot with enough hardware to make everyone happy, you’re effectively hemorrhaging money unnecessarily when your users are offline. Building web applications using serverless architecture solves these problems. Hosting in the cloud and tying various services together lets you build globally distributed, dynamically scalable systems that incur costs only for the computing resources used. It’s a clear win-win use case, doing away with all the burdens of infrastructure and scaling while saving money when users are offline.

Microservices are another type of application that works particularly well with serverless architecture. Microservices have become increasingly common as software complexity has grown, mainly because more complex software brings larger team sizes, challenging release goals, and larger development scopes and timelines. The challenges of developing software, and teams, increase geometrically and not linearly. Breaking apart monolithic applications into multiple microservices can help flatten those curves. As such, microservices are practically the poster-child for serverless architecture. Their very nature is to deliver business value through several focused, standalone APIs, so the move to serverless architecture simply moves the hosting burdens to someone else. Serverless architecture allows microservices to securely access, manipulate, and combine data from multiple sources in real-time, which again frees developers to focus on their application space and not worry about the back-end infrastructure.

The third type of application that can benefit significantly from serverless architecture is event-driven systems. Generally, event-driven systems consist of agents (sometimes called “emitters”), consumers (“sinks”), and channels, all of which work together to ensure that the appropriate responses are taken when important things happen. For example, an agent could be anything from a person sending a text message to a “dumb” Internet-of-things (IoT) device sending telemetry back to the home office. Crucial to the event-driven system is that the agent/emitter generates the event, routed through the relevant channels to any proper consumer/sink to handle it. This design paradigm is effectively infinitely extensible by adding endless new agents, channels, and consumers and avoids some of that geometric complexity mentioned earlier.

Event-driven systems have sometimes been an uncomfortable fit for more traditional architecture for various reasons, not the least of which is the usual problems of global distribution, scalability, downtime, etc. Missing or simply dropping events can be no big deal in some industries but can be life-threatening in others. As such, serverless architecture can again be a powerful asset for its ability to scale dynamically. And perhaps more than any other approach, functions as a service (FaaS) offerings can make developing event-driven systems far more straightforward than ever before. Their very nature is to run bits of code in various languages in response to triggers, so they’re a natural fit for obvious reasons.

Machine-learning (ML) applications are a relatively new use case for serverless architecture, though the history of ML itself dates back some decades. Key to any ML application are the details of the model(s) involved, collecting, storing, maintaining the data for said models, and the ongoing processes of training the system while further developing and refining the models and their data.

When described in that matter, it should be fairly obvious how serverless architecture can be a boon for ML applications. While a more thorough discussion is beyond the scope of this article, suffice it to say that not only do they enjoy all the benefits of the other types of applications already discussed, but the flexibility offered by database (and other) APIs, along with all the benefits of FaaS, can be of great assistance to ML developers.

Let’s look at an example of serverless architecture named ”MeetKai,” which can be described as a “next-gen Voice Assistant.” MeetKai’s goal is to facilitate multi-lingual searching, which goes beyond the mere text- or phoneme-matching sorts of algorithms that have been around for decades. As such, it requires more than indexing web text, organizing content instead of as a series of interconnected items in a language-independent way. This makes MeetKai is an ideal candidate for serverless architecture. It allows incoming user queries to be handled in a scalable way, routing them to various regional search clusters for global availability and leveraging batch processing clusters for data aggregation and machine-learning to train the system and improve the model over time. Personalizing queries for each user is similarly made easier by tracking previous queries and relevant analytics.

The underlying data layer that powers MeetKai is Fauna. Storing all the details in Fauna effectively ties together the serverless workers and the batch-processing tasks, providing the “single source of truth” for the overall system.

Another example of serverless architecture is Hannon Hill’s “Clive,” a customer-engagement tool for the Cascade CMS web content management system. Clive is built using Amazon’s AWS Lambda FaaS offering and Fauna’s Data API to avoid server infrastructure burdens.

Clive’s operations are separated into two sides, administrative and live. The former is built on top of a hosted Ruby on Rails, which provides an API used by the live side on top of hosted PostgreSQL. The live side essentially routes visitors through an API gateway to lambda functions that leverage the Fauna for storage.

These choices enable Clive to auto-scale both in handling multiple simultaneous requests and database size, avoid wasting development and operations time spent on infrastructure issues, and keep costs to a minimum by paying only for the computing resources used. While all the details are beyond the subject of this article, serverless architecture provided precisely the sort of benefits we’ve discussed all along.

In this article, we’ve discussed how serverless architecture can be a great benefit for various applications. As software architecture evolves toward embracing microservices, cloud APIs, functions as a service (FaaS), and so forth, developers will be increasingly dependent upon cloud data services that are always correct, fast, and work frictionlessly with the rest of your stack.

Fauna ticks all those boxes as a simple, developer-friendly, Data API that offers traditional transactional ACID guarantees and querying power with all the performance and flexibility of document systems. It also integrates neatly with Netlify, Vercel, AWS Lambda, Azure Functions, and other tools to string together your serverless architecture applications. Finally, Fauna is free to sign up, easy to get started, and offers clear and straightforward pricing—paying only for what you use. If you think Fauna could be a good fit for your serverless architecture application, why not give it a try today?