With a growth rate of 75% percent, Serverless computing is the fastest growing cloud service, with some calling it the Uber of infrastructure. Why? Because a Serverless platform allows engineers to behave much like Uber riders: with minimal choice and control over the car that picks them up, in lieu of a flexible, on-demand service.
Put simply, the server is taken out of the equation. Engineers can focus on building and deploying their application. In a Serverless model, the cloud provider manages resource provisioning. This allows your engineering team to focus on writing code because Serverless provides an application layer that is reliable—a DevOps dream come true.
In this post, we’ll review what it takes in terms of architecture to put an application into this new 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 nowadays.
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) went from being a technology for building distributed applications, to an architecture paradigm, it was conceptualized based on some important aspects:
- It should have a business-driven general goal
- The scope should be at an enterprise level, not project level
- High interoperability inside its components
- Reusability
- Consistency
- Requires the ability to adapt to changes in the business
These core values relied on patterns, not technology, which made it an unconventional way to develop and implement systems with a kind of Service Oriented Architecture. This resulted in failures and high costs for the companies that started to use 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 was to accomplish the lost intentions from SOA: speed up project delivery, increase IT agility, and reduce integration costs. Many called Microservices 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. And, original SOA principles such as business alignment, dependency minimization, and service contracts became Microservices principles as well.
Microservices architecture is based on the single responsibility principle. Let’s say, for example, a 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 into a Microservices model.
Comparison between monolithic and Microservices models.*
Microservices architecture led to independence between the services and includes a high level of communication across all of its components. It 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 has continued to be 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.
A generic serverless architecture diagram*
Function as a Service is about running these functions or pieces of code that contains your business logic. Performed on top of an infrastructure 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 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 with 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 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 difference, and one of the major benefits of Serverless, is its scaling capacity. This can also be a determinant factor when choosing to go for a Serverless model. And because enterprises only pay for resources used, versus renting or securing a fixed number of servers, or relying on cloud computing that’s “always-on,” a Serverless model is worth the cost-benefit analysis.
