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, 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:
you now can say
It’s obvious that serverless computing is very effective regarding the resource usage when operating such a solution.
Risk 1: Vendor Lock-In
At the moment, platforms to host serverless architectures are only 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 made in software engineering for many years.
There is the risk that developer ignore those lessons when building serverless architectures and that they end up in a hell of unmaintainable functions. In this situations the benefits of lower operations costs are overshadowed by much higher maintenance costs.