Serverless Architecture

Serverless Architecture is a term that has been getting a lot of attention lately. Naturally, technical leaders are looking to come up to speed on the concept and are evaluating how best to make use of it. The first order of business is to understand what Serverless Architecture is. That prepares us to explore the differences between Serverless and other architectural approaches, evaluate its strengths and weaknesses, and learn how to apply it to your applications.

What is Serverless Architecture?

Serverless Architecture is a term that has been used to describe applications that rely heavily on third-party Software as a Service (SaaS) applications for functionality such as authentication or database persistence. The term “serverless” has also been used to describe applications architected to run in event-triggered, ephemeral processes. The major cloud platforms, including Azure and AWS, provide offerings referred to as Functions as a Service (FaaS) which facilitate this design.

One way to conceptualize Functions as a Service is to consider it as another layer of abstraction on top of the physical hardware running our applications. Just as Infrastructure as a Service (IaaS) offerings such as Azure Virtual Machines abstract our applications from the actual hardware running them and Platform as a Service (PaaS) offerings such as Azure App Services abstract our applications from virtual machines—FaaS allows us to run our code without having to think about managing individual services. To accomplish this, when a FaaS function is invoked, the platform manages spinning up an instance of that function, executes the function to fulfill the request, and disposes of the instance once the request is complete.

As an illustration of this architecture, consider the following example:

Assume we’re building an application for an online retailer. Customers have the ability to create and log in to an account, search an online catalog, and order goods. This application also provides order fulfillment services for the retailer itself. With a typical n-tier architecture, all of this functionality could be implemented in one application. With a microservices architecture, the functionality could be split into separate authentication, catalog, order, and fulfillment services, utilizing a messaging transport such as RabbitMQ for event-based communication between services. With a Serverless Architecture, a cloud-based FaaS platform could be used to define functions for fulfilling each individual request of the UI. These functions could be exposed to the UI through the use of a cloud-based API gateway such as Azure API Management and persistence could be provided by a cloud-based database such as Azure Cosmos DB.

What are the benefits of a Serverless Architecture?

One of the great benefits of cloud computing is the ability it provides us to easily scale our applications according to demand. Scaling can be as simple as manually scaling out the number of instances of an Azure App Service or configuring auto-scale. This allows us to control the cost of our infrastructure according to the demand for our applications, something that’s much harder to do with physical hardware. Depending on the architecture of our system, we can apply this granularity of control in different ways. As an example, if our system makes use of a microservices architecture, we can scale out each service independently according to its demand rather than scaling up or out an entire monolithic application.

Even with the ease of scaling which a cloud service such as Azure App Service provides, there’s always one or more instances of a service running at the point of lowest demand, which incurs cost. Serverless architectures that make use of FaaS are quite a bit different. Rather than being charged based on the capacity and number of virtual machine instances, the cost of FaaS function invocations is based on the amount of memory and time used during execution. Once a function instance has completed execution, it’s disposed of, leaving no resources to idle and incur a cost. This design makes the cost of our service directly proportional to its demand. Additionally, the scalability of this design is inherent—as more requests are received, more functions are instantiated and disposed of in order to fulfill those requests.

What are the tradeoffs and challenges of Serverless Architecture?

The benefits of scalability and cost structure which a serverless architecture provides does not come without some tradeoffs and challenges. For one, just as microservice-based architectures increase the complexity of our systems—due to there being more moving pieces—serverless systems provide us with even more to conceptualize.

Vendor lock-in is a common concern for companies looking to make a transition or investment in cloud technologies. In reality, for most cloud service offerings, the effort of shifting vendors is primarily focused on deployment, configuration, and monitoring. With FaaS, however, the switching cost of changing vendors also includes adjusting the use of platform-specific libraries which impacts our code.

Integration testing will be a challenge, especially if your Serverless Architecture relies in part on third-party services as mentioned earlier. It may not be feasible to replicate a full system in a local environment, so local testing will likely have to focus on unit testing.

In terms of the monitoring and observability of FaaS, vendor-specific tooling such as Azure Application Insights initially was our best option. However, support from third-party services such as New Relic and Dynatrace for monitoring Azure Functions seems to be increasing. Keep in mind that your monitoring tool of choice may or may not have support yet for a given FaaS platform.

What is the best use of a Serverless Architecture?

FaaS is a tool among many tools that we have available to us when architecting systems, but it’s not the correct tool for every problem. For example, a ‘lift and shift’ effort to transition a legacy enterprise system to be completely serverless isn’t necessarily the most realistic endeavor as significant changes have to be made to existing code and the challenges that this presents isn’t guaranteed to be outweighed by the benefits. Serverless architecture has a lot of potential to show the benefit of a cost structure that is directly proportional to demand and inherent scaling in applications or use cases that experience sporadic changes in demand. A great example of this is captured in a post by security expert Troy Hunt who operates Have I Been Pwned with a Serverless Architecture that makes use of Cloudflare and Azure Functions.