Serverless Architecture in short
lower operations costs and vendor lock-in

Introduction

Serverless architecture or serverless computing is an emerging software architecture style to build distributed systems (often web- or internet of things applications). The current de- facto standards for building such system are service oriented architectures (SOA) or microservices as a more modern interpretation of SOA.

In a microservice architecture applications/services are developed and deployed. Each service groups related functions. In a serverless architecture functions are developed and deployed to a “platform” separately. The platform then takes care of executing those functions on specific events. For example, there might be a function to compute a response when a HTTP request arrives, or there might be a function that is executed when something is written to a database.

At the first glance this reminds on traditional stored procedures. In contrast to stored procedures, functions in a serverless architecture are not limited to only database events and each function can be implemented in a different programming language. Furthermore, it is not ensured that the same function is always executed on the same server.

Let’s have a look at the purposes and trade- offs of serverless architectures.

Purpose 1: Lower Operations Costs

The services in a microservice architecture are always running. In fact, often there is more than one instance running of each service in order to achieve height availability. In a serverless architecture nothing runs when no event occurs. The platform which hosts the functions takes care to execute them only when necessary. And regarding to the pay-as-you-go principle you don’t have to pay if nothing is executed.

Scaling and autoscaling is no problem in a serverless architecture. When workload increases the affected functions just gets executed more often (in parallel of course).

Elasticity configuration is also much more effective in a serverless architecture. Instead of saying:

“I’m willing to pay for 3 GB memory, and then stop the autoscaling”

you now can say

“I’m willing to pay for 30000 events of type X and 5000 events of type Y, then stop scaling”

It’s obvious that serverless computing is very effective regarding the resource usage when operating such a solution.

Purpose 2: Reduce Time to Market

Another motivation to build serverless architectures is a faster development and deployment cycle. This is achieved because of the following reasons:

  • The serverless architecture style motivates to use existing or third party services (e.g. Auth0 for authentication) to reduce the custom code [see, 01].
  • Each function should cover a clear defined responsibility. This leads to very small code base for each function. Because the responsibilities are well defined, each function can be developed and deployed independently.
  • Because functions are small and have a clear responsibility the likelihood for reusing existing functions increases.
  • The platforms to operate serverless architectures takes care of all the operating stuff. The developers just have to upload the code and get direct feedback how the code behave in production.

Risk 1: Vendor Lock-In

At the moment, platforms to host serverless architectures are mainly provided by big players. AWS Lambda to name the top dog. To run a system on AWS lambda you must use very AWS specific services (Amazon API Gateway, DynamoDB, S3, etc.). Once you developed a complex system on top of these services you are cursed to stick with AWS, no matter how often they decide to increase their prices.

Running your own platform to operate a serverless architecture is pointless because, in most cases, the overhead will be much higher then the savings.

Risk 2: Complexity and Low Cohesion

For decades, software engineers strove for height cohesion and less complexity. Domain driven design and microservices are a perfect match because they summarize the experience how to group related functionality.

There is the risk that developer ignore those lessons when building serverless architectures and that they end up in a set of unmaintainable functions. In my opinion, serverless architecture tend to produce "nanoservices" and requires more experienced engineers to get it right. See arnon.me for a defintion of nanoservices:

"Nanoservice is an antipattern where a service is too fine-grained. A nanoservice is a service whose overhead (communications, maintenance, and so on) outweighs its utility"

External Sources

[01] Peter Sbarski, Sam Kroonenburg; Serverless Architectures on AWS - With examples using AWS Lambda, Manning Publications

[02] Arnon Rotem-Gal-Oz; Services, Microservices, Nanoservices – oh my!