This article discusses what serverless is, comparing it with PaaS and SPaaS, the benefits and costs of a serverless architecture and the need for a framework.
Initially, serverless meant developers did not have to care for setting up and administering the servers running their back-end applications. Not that there were no servers involved, but the back-end infrastructure was maintained by third party providers and the functionality needed was offered as services, covering databases, messaging, authentication, etc. This service infrastructure was usually called Backend-as-a-Service (BaaS) or Mobile Backend-as-a-service (MBaaS).
But Amazon took the serverless paradigm to another level when they announced AWS Lambda back in 2014, introducing a new system architecture for applications running in the cloud. There is no perpetual process running on a server and waiting for HTTP requests or API calls, but an event mechanism that triggers the execution of a piece of code, usually just a function, on one of AWS’ servers.
One does not have to consider the server when using this paradigm. All that matters is to write the piece of code to be executed when a certain event takes place. The cloud provider takes care of finding a server where the code is to run, and to scale up when necessary. The containers used to run these functions are decommissioned as soon as the execution ends. And the execution is metered in units of 100 ms, the user being charged only for the resources consumed when the code is run. Some have called this type of functionality Function-as-a-Service (FaaS), which is Yet-Another-as-a-Service (YAssS), one of many that have appeared since cloud computing made its debut.
Amazon is not the only FaaS provider. Others include Google Cloud Functions, Microsoft Azure Functions, IBM OpenWhisk with an open source implementation, Iron.io, and Webtask.
The serverless architecture goes well with nanoservices. If a microservice is a process meant to address a relative small business capability, a nanoservice deals with a fraction of the respective capability. For example, a microservice could be represented by the code needed to perform all CRUD operations on an account, while there is a nanoservice for each account operation: create, read, update, and delete. When a “Create Account” event is triggered, the respective nanoservice is executed as a AWS Lambda function. Few use the term nanoservice, most preferring microservice or even just service.
Some consider FaaS as just another PaaS, but Mike Roberts, VP of Engineering at Intent Media, has another opinion:
Most PaaS applications are not geared towards bringing entire applications up and down for every request, whereas FaaS platforms do exactly this. …
The key operational difference between FaaS and PaaS is scaling. With most PaaS’s you still need to think about scale, e.g. with Heroku how many Dynos you want to run. With a FaaS application this is completely transparent. Even if you setup your PaaS application to auto-scale you won’t be doing this to the level of individual requests (unless you have a very specifically shaped traffic profile), and so a FaaS application is much more efficient when it comes to costs.
Roberts did not consider that everybody should dump PaaS and start using FaaS, naming a few reasons: “tooling, and maturity of API gateways, are probably the biggest. Furthermore, 12-Factor Apps implemented in a PaaS may use an in-app read-only cache for optimization, which isn’t an option for FaaS functions.”
Camille Fournier, who calls herself a Senior Thinker and Raconteur, wondered in a tweet “if serverless services will become a thing like stored procedures, a good idea that quickly turns into massive technical debt.” Addressing this issue, Roberts considered that FaaS could be replaced with SPaaS (Stored-Procedures-as-a-Services) only if serverless functions are just “small pieces of code that wrap access to a database.” But since FaaS functions can be used for many other purposes, the comparison is invalid. He also noted that unlike stored procedures, serverless functions do not require a vendor-specific language or framework, they can be tested and can be versioned easily.
Discussing serverless architectures, Badri Janakiraman, a ThoughtWorks developer, noted a shift introduced by FaaS: the long-lived server process which usually contains most of the logic is broken down into proprietary and third party services while the flow control of the application moves to the client:
Serverless applications often make extensive use of third party services to accomplish tasks that are traditionally taken care of by servers. These services could be rich ecosystems of services that interoperate, such as Amazon AWS and Azure, or they could be a single service that attempt to provide turnkey set of capabilities such a Parse or Firebase. The abstraction provided by these services could be infrastructural (such as message queues, databases, edge caching…) or higher-level (federated identify, role and capability management, search…).
One of the primary responsibilities of a general purpose server based web application is to control the request-response cycle. Controllers on the server side process input, invoke appropriate application behavior and construct dynamic responses, typically using a templating engine. In a serverless application, where application behavior is woven together from third party services, client side control flow and dynamic content generation replaces the server side controllers. Rich JavaScript applications, mobile applications (and increasingly, TV or embedded IoT applications) coordinate the interaction between the various services by making API calls and using client side UI frameworks to the generate dynamic content.
Regarding the benefits of implementing a serverless application, Janakiraman listed a significant reduction in costs because one does not have to pay for renting an entire server in the cloud but only for resourced consumed during execution; scalability, because it is easy to scale independent services triggered to action by events; and the lack of operating and maintaining infrastructure. When it comes to costs, Janakiraman remarked the “conceptual overhead of splitting a single application into something that woven from a fabric of services is significant and increases with the number and variety of services used,” and the raise in development and testing complexity.
And there is another hidden cost in using a serverless approach when creating an entire back-end based on FaaS. serverless.com explains in their documentation:
While AWS Lambda offers a powerful new way of developing/running applications, when we began building our first project based entirely on AWS Lambda, we realized structure was badly needed. Managing all of the containers that Lambda introduces is a difficult task. Add to that multi-developer teams, multi-stage and multi-region support and you will quickly get into a messy situation.
For that purpose, Serverless Inc. has created the Serverless Framework, an open source project meant to help with building web, mobile, and IoT applications with FaaS. Currently working with AWS Lambda, the creators of the framework intend to support other providers in the future. The framework has a number of features, including: running and testing Lambda functions locally or remotely, deploying Lambda functions, deploying REST APIs to the AWS API Gateway, deploying Lambda events, support for multiple AWS regions, and others. The supported languages are JavaScript/Node.js, Python and they are working on adding Java to the mix. Other languages will be added later.
Another serverless framework is Apex, with similar functionality, support for AWS, JavaScript/Node.js, Go, Java and Python and plans to support other providers in the future.
For those interesting in learning more on the serverless architecture, Werner Vogels, CTO at amazon.com, has published a number of reference architectures for building applications with AWS Lambda. He provided guidance on creating a Mobile Back-end, a Real-time File Processing, a Web Application, a Back-end for IoT, and a Real-time Stream Processing based on Kinesis. The principles outlined in these reference architectures are applicable to other FaaS providers, the only change being the services used.