What is Serverless? Part 2: What is a Serverless architecture?
In my previous post, it was explained the different models for applications, each one of them suitable for different requirements; in particular a Serverless model. In this post we’ll review what it takes in terms of architecture to put an application into this new paradigm model.
In our current software systems context, there are plenty of components, libraries and services that are involved when creating an enterprise application. From three-tier models, SOA, Microservices and Serverless models, systems architecture has evolved in order to solve all the goals that complex, large and scalable software needs nowdays.
In this evolution, there have been important aspects that defined the distributed architecture types and how Microservices and Serverless became affordable solutions.
SOA & Microservices
A while ago when SOA (Service-Oriented Architecture) started not being a technology for building distributed applications, but an architecture paradigm, it was conceptualized based on some important aspects:
- Should have a business driven general goal.
- The scope should be at an Enterprise level, not project.
- High interoperability inside its components.
- Reusability
- Consistency
- Required to have ability to adapt to changes in business.
These core values relied on patterns, not technology, which made it a no standard way to develop and implement systems with a kind of Service Oriented Architecture. Therefore, becoming into something that caused failures and high costs for the companies that started to used this type of architecture.
Despite the failures, there were some good lessons learned and the SOA paradigm started a new architecture model: Microservices. With Microservices the goal were to accomplish the lost intentions from SOA: speed up project delivery, increase IT agility, and reduce integration costs. Based on this, many said that Microservices were an evolution of SOA or SOA done well.
Microservice architecture matches that original SOA vision of a software system decomposed into loosely coupled services. That is a pattern. Furthermore, original SOA principles such as business alignment, dependency minimization, and service contracts became microservices principles as well.
Microservices architecture is based on the single responsability principle. Let’s take an example: monolithic application is split into several pieces (Microservices), where different responsibilities are placed into different services. Each service has its own code repository, each service instance is executed as a dedicated process, and inter-service communication is only allowed through a network connection. Services must use its official API to talk to each other. And last but not least, the protocol for communication must be technology agnostic. All this is part of the Microservices architecture.
The following diagram shows how monolithic evolved to a Microservices model.
Microservices architecture led to have an independence between the services and includes a high level of communication across all of its components. Also brought freedom between the interdisciplinary teams of companies where this architecture was adopted.
Of course all these benefits came with some costs for the enterprises that started adopting this model: operational side increased its complexity, given the need to manage hundreds of services and deploy them regularly; the distributed system infrastructure is harder to implement; the distributed architecture requires also a level of consistency, that along with the distributed system, becomes difficult to achieve, and finally there is a risk of failure.
Even with higher cost and feasible risks, Microservices has brought good patterns and solutions for companies demands which need to scale and adapt quickly to its market growth. And continue until today being a great architecture for distributed systems.
Serverless, beyond Microservices
Let’s say that you have done all the work and developt a Microservices architecture solution, and your company has been working productively in this new model. You have all your services working, such as controllers, authentication, logging, data storage, api gateway, etcetera. If you take away all the common parts between your Microservices you will end up only with the actual business logic. The rest is common functionality. You will realize that there is a sort of ecosystem that runs your business functions. And you could eventually create more functions and deploy them to this ecosystem. Here is where the Serverless or Function as a Service model comes into play.
Function as a Service is about running these functions or pieces of code that contains your business logic. Performed on top of an infrastrucure that you do not own, or manage. Serverless is about running only this backend code, uploaded previously to the FaaS provider. The horizontal scaling is completely automatic, elastic and also managed by the provider.
API Gateway
One of the key parts in the architecture of the FaaS model is the API Gateway: an HTTP server where REST endpoints are defined in configuration and each one of them is associated with a FaaS function. The API Gateway transforms the result of the FaaS function call to an http response, and returns this to the original caller. Other usages of API Gateway are authentication, input validation, response code mapping, among others.
The process of a Function as a Service, is something similar to the following, with some differences that might apply depending on the provider:
- An event is triggered (based on the launch configuration).
- An API launches a container where the code will be run, which was previously uploaded. All dependencies are already in place.
- The Function serves the request.
- The container is killed.
The process is short, same about the resources. The amount of disk space, the RAM that loads it, processing time, etcetera should also be short lived. This is also a high factor in order to consider if an application or function could live in a serverless model.
In summary Microservices and Serverless have some few principles in common; both are organized around business processes, both reinforce modularity design, have an independent deployment, both do infrastructure automation, but there are also significant differences. The most important one would be the scaling capacity which is one of the major benefits of the Serverless model. And which also can be a determinant factor when choosing to go for a Serverless model.
References
Serverless articles and resources
A guide to Serverless Model Application
Microservices
Introduction to Microservice by Oliver Wolf
SOA References
SOA manifest explained
SOA manifest
Diagrams credits
1-Diagram about Microservices from https://martinfowler.com/articles/microservices.html by Martin Fowler.
2-Diagram about Serverless from
Happy coding!