Too much of the current literature dealing with serverless architecture is driven by cloud providers and focuses only on the benefits, Wisen Tanasa writes in a recent blog post. When a new technology emerges, it’s important to understand the implications of adopting it, and Tanasa therefore tries to give a better, more objective understanding of the traits of serverless architecture.
Tanasa, lead developer at Thoughtworks, started by noting that he prefers to use the word traits instead of characteristics since he believes these are elements of the serverless architecture that you cannot change, unlike characteristics which are malleable. Traits are also inherent so you must embrace them, not fight them.
Serverless architecture has a low barrier-to-entry; it’s easy to follow a tutorial to get starting. But Tanasa points out that although the learning curve for a developer is low to start with, it will get steeper as things get more complex. Things like infrastructure as code, logging and monitoring are still essential in a serverless world. He has also noted the tendency among developers to ignore code design, with the argument that they are only working with functions. He emphasizes that we shouldn’t ignore important architectural principles. Design concepts, like SOLID, are still important, as are continuous delivery principles.
In a serverless world you are hostless; there are no servers to work with. One advantage this brings is the significantly less operational overhead — there are no servers to upgrade and no security patches to apply. But it also means that different kinds of metrics need to be monitored in an application, and thus there is a need for relearning how to tune the architecture. Tanasa emphasizes that although security patches are automatically added, application security practices still apply. One example is storing secrets in code, which still is something that must be avoided.
Functions as a Service (FaaS) is ephemeral, which means that serverless are stateless. When state is not stored in applications, horizontal scaling is very easy — you just spin up more instances. Being stateless also means that room for error is greatly reduced. But being stateless also means that techniques that require state can’t be used in application development; for example, it's not possible to use HTTP sessions.
Being hostless also means that the architecture is elastic. This means there is no need for the manual management of resources, and that many challenges in resource allocation disappear. Commonly, it also means paying only for the resources that are actually used. When integrating with legacy systems, this elasticity may be a problem though. Tanasa notes that unless the legacy system scales as well as the serverless parts, the load may have to be limited to prevent it from breaking down due to overload.
A serverless architecture where many components are integrated via the network is distributed by default. Persistence is done in Backend as a Service (BaaS), code is run in multiple functions, other services are used for authentication and queues, etc. Being distributed also brings high availability to the architecture. If the current availability zone is facing problems, the architecture can utilize another zone that is available. One trade-off with a distributed application is consistency. Read-after-write and eventual consistency are two examples of behaviour in BaaS that must be considered when updating and reading data.
A serverless architecture is event-driven because of the utilization of BaaS which often support events. Tanasa notes that this doesn’t mean that an event-driven architecture must be fully embraced, although he believes that being event-driven brings many benefits. One example is the low level of coupling between components. One disadvantage is the risk of loosing the holistic view of a system which can make it a challenge to troubleshoot.
Tanasa concludes by noting that serverless architecture brings an interesting paradigm shift. It improves a lot of software development aspects, but also introduces some new challenges that developers and teams must become comfortable with.
In two blog posts, Mike Roberts, working for Symphonia, describes his definition of serverless. A serverless application is an application implemented using serverless services and he claims that such a service must exhibit five common traits:
- No management of server hosts or server processes are required
- Auto-scaling and auto-provisioning based on load
- Cost is based on usage
- Performance capabilities are defined in different terms other than host size or count
- Has implicit high availability
Roberts together with John Chapin, also at Symphonia, wrote the book What is Serverless? where they define and describe serverless in more detail, and how serverless differentiates from other cloud-native approaches.
Jonas Bonér wrote in a blog post earlier this year that although he strongly believes in the serverless movement, the programming model should not focus only on stateless functions, as this limits the range of supported use-cases.
In a blog post from 2017, Martin Fowler wrote about the risk with event notifications and notes that the event notification pattern can be useful, but it also adds a risk of losing sight of the larger-scale flow.
