SERVERLESS ARCHITECTURE: FROM BUZZWORD TO REALITY
This is the first part of a Serverless series, read part II here. You might be also interested in this other article I wrote about what Microservices
The term Serverless Architecture has been around for the last few years. During that time there has been a lot of skepticism surrounding this concept, and some argue it is just another buzzword, a marketing strategy. Although it has started to change lately.
Nowadays, the maturity of some big platforms created by companies like Google or Amazon, as well as the growing number of applications based on those platforms, are changing the buzzword around Serverless Architecture into a reality that should be seriously considered in any new project.
What are the key concepts behind Serverless Architecture and what are their advantages and drawbacks? Let’s take a look and find out why it is so promising for the software industry.
WHAT IS SERVERLESS ARCHITECTURE?
The term is confusing as one may think that we are building a software that runs completely on the client side (user’s PC), probably distributed among different clients.
But when we talk about Serverless Architecture we would rather use and think about this term as Martin Fowler explains it: “Serverless Architectures refer to applications that significantly depend on third-party services (known as Backend as a Service or “BaaS”) or on custom code that’s run in ephemeral containers (Function as a Service or “FaaS”), with the best known vendor host currently being AWS Lambda. By using these ideas, and by moving much behavior to the front end, such architectures remove the need for the traditional ‘always on’ server system sitting behind an application”.
As we can see, there is a server component after all. But, since there is no single centralized server that needs to be “always on”, developers coined the term serverless for these kinds of systems.
Although we may think this is just another flavor of client-server architectures, the shift in the way behavior in the back-end side is decentralized makes a huge impact on how applications are developed and overall in the reduced effort and costs for deploying and maintaining the system (part of these operations costs is what is currently being managed by DevOps).
In certain aspects, one can think of Serverless systems as a special kind of micro-services architecture where the focus is mainly on the development of each service whereas everything related to infrastructure and deployment is taken care of by the Cloud.
Microservices is a technical term describing how services interact between them, providing a flexible and scalable platform. Serverless systems allow developers building microservices to forget about the hassle of building and deploying their services, and for some cases even implementing the service backend logic could also be taken away from the developer perspective.
From the point of view of hardware requirements, Cloud services providers change the offer of a virtual machine and raw hardware power by computation power (regardless of how that power is delivered and managed under the hood).
TWO TYPES OF SERVERLESS ARCHITECTURE
As we mentioned above, the key difference between an application consisting of multiple micro-services and a Serverless system is the degree of automation of the backend side. There are two types of Serverless Architecture: Backend as a Service (BaaS) and Function as Service (FaaS).
Using BaaS, you get lean unified access to some specific services: persistent storage, security, and messaging. You do not have to worry about building any REST or any similar interface to interact with the data, however, a user must be authenticated. All that can be leveraged to the back end service.
The main beneficiary of this kind of technology are mobile developers that can bring first class applications to almost every business domain with a very short time-to-market: Android and iOS users can focus on building the UI and client logic interacting with BaaS platform for all its non-functional needs (persistency, logging, auditing, and authentication), creating a fully functional application in days instead of months. The major BaaS platform for this kind of development is Amazon Mobile.
But, BaaS cannot cover all scenarios. Sometimes, your application needs to do a lot of intensive computational work (e.g. determining the best selection for a set of elements based on the history and user profiles for a given network). This kind of specific computation cannot be generalized and offered in the same way you get an authentication or data access service. Also, if that logic is complex and time-consuming it will not fit well on the client side.
For these types of requirements you need a way of uploading the custom backend algorithm and a well-defined interface to invoke such a backend logic with a certain input. And this is exactly what Amazon created, offering Lambda AWS: develop and run in the Cloud at the finest granularity of a function call. The term coined by this sort of Serverless Architecture is FaaS. (Function as a Service).
The shift in the paradigm generated by Amazon Lambda is what finally permitted developers to forget about the server and to start talking about Serverless Architectures and frameworks. Developers only need to worry about the algorithm and logic that solve a given functionality of its application. They can even code and implement it on the client side while prototyping and building the application in its earlier stages. Once you have the desired implementation, the Cloud provider will take care of where to run it, scaling it up when necessary.
Some may argue that there is nothing new about Serverless and that it is just another kind of Platform as a Service (PaaS) where the Cloud provider takes care of running your code. But there is a fundamental change in the level of abstraction: you do not need to think about how many servers, virtual machines, or containers are needed for your application. And even considering auto-scaling, the unit of work in FaaS is much more minimal than an entire Virtual Machine (VM) or container environment (with its own process and memory), leading to a fraction of the costs at the level of function calls.
Amazon, Microsoft, Google, and IBM have all been offering PaaS services over the last few years. But it was with Amazon Lambda functions that we started to see actual Serverless platforms reachable to a general audience.
Nowadays, Amazon is not the only one providing FaaS. Most of its competitors are catching up with its own execution environments: Microsoft Azure Functions, Google Cloud Functions, IBM, and OpenWhisk. We can also see newcomers in the field, with startups such as Iron.io, Webtask and Serverless, to name a few.
TO SUM UP
Serverless systems offer an incredibly faster way of building software that reach millions of users with ease, requiring zero effort on infrastructure and deployment of the systems.
Although it is easy to be tempted by the speed of development of these solutions compared to the traditional full stack client server architecture, not all organizations are prepared to even try the microservices style.
In the second part of this series, we are going to review the main strengths of this technology, and we will also have a look at the main risks and issues that any organization should consider before deciding to start or migrate to a Serverless solution.
This is the first part of a Serverless series, read part II here
This article was originally published on Hexacta’s blog April’s 2017