Introduction to Serverless

Cloud computing, which started with Infrastructure-as-a-Service (IaaS), Platform-as-a-Service (PaaS), and Software-as-a-Service (SaaS), is fast moving into a Function-as-a-Service (FaaS) model where users don’t have to think about servers. Serverless applications don’t require the provisioning, scaling, or management of servers, as everything required to run and scale the applications with high availability is provided by the platform itself. This allows users to focus on building their core products, instead of worrying about the runtime infrastructure demands; and to pay only for the actual compute time and resources consumed, instead of the total uptime.

Server-Less?

Serverless is merely an abstraction wherein the users (developers and maintainers in general) have zero or minimal visibility and control on the “server” aspects of their target environment — processes, the kernel, the filesystem, OS configurations, and so forth. From a traditional developer perspective, this may seem like a considerable restriction, but the same abstraction opens up wonderful possibilities for platform providers to optimize their infrastructure utilization (more bang for their buck), and for users to avoid unnecessary charges with per-usage billing. In this sense alone it’s a win-win, not to mention the ensuing resource optimization and “green computing” benefits.

FaaS is solely the computation aspect of serverless, which in itself is quite broad in scope: storage, hosting, relational/non-relational persistence, messaging, API/web service provisioning and management, and even IoT coordination. The first commercially successful serverless (“pay-as-you-go”) platform was Google’s App Engine in 2008 (which is now, arguably, categorized as a PaaS). However, the real surge was in 2014, when AWS announced Lambda as “serverless compute” as a novel, pay-per-execution alternative for pay-per-allocation VMs.

The Awakening

As of now, we see a few major players in the arena: AWS with Lambda (which, not coincidentally, fits nicely with the “as-a-service” stack they have been building since the beginning); Microsoft Azure with its Azure Functions (catching up fast, along with their other service offerings like Azure Storage, CosmosDB, and Event Grid), and Google Cloud Platform with its Cloud Functions and Firebase Functions (the former having gone GA in July this year — although it is seemingly lagging in comparison to its competitors — and the latter being a more “managed” version of the former, tailored for the Firebase backend-as-a-service (BaaS) platform). In addition, we see many new players waiting in line — IBM Cloud Functions based on OpenWhisk, PubNub Functions, MongoDB Stitch, and Function Compute from Alibaba Cloud.

In addition to such public cloud-based providers, there’s an increasing number of do-it-yourself serverless platforms which one can deploy on their own cloud infrastructure — Kubernetes-based Kubeless and Funktion; Apache OpenWhisk; Docker-based Oracle Fn and IronFunctions; even totally novel experiments like OpenFaaS on Raspberry Pi.

“Why” and “When”

Given the pay-per-use model of serverless, it is mostly suited for batch and event-driven workloads. An ideal example is end-of-month payroll processing; rather than running and maintaining a dedicated compute instance (such as a server, container, or platform (PaaS) app) throughout the month, or going through the hassle of starting, configuring, running, and shutting down such an instance just for the EoM batch process (while having to pay for the passive resources for the whole month), the organization can simply deploy a set of serverless components (a function, connected to a pay-per-use data store or source, such as Google Cloud Datastore or AWS DynamoDB). This way, the payroll personnel can simply invoke the function on demand to get their EoM calculations done, and literally forget about it — until the end of next month.

Another remarkable feature of serverless functions is their near-infinite scalability — the ability to scale from virtually nothing to literally tens of thousands of concurrent instances — which makes them perfect candidates for handling highly variant and highly unpredictable loads, such as traffic for a real-time sports score app. In most cases, it is much more economical to have serverless infrastruc- ture handling on-demand loads rather than running, managing, and paying for over-provisioned VM instances or container clusters just to handle a rarely occurring peak load.

A Blooming Ecosystem

Parallel to platforms, serverless frameworks are also booming. The literal Serverless Framework and SAM (Serverless Application Model) from AWS are two of the key players. Both are open-source (although the mechanisms behind SAM are embedded in the opaque AWS platform), have installable CLI components that can be set up to run quickly, and integrate with CI/CD workflows as well. The Serverless Framework supports multiple languages, provides lifecycle management, and is extensible via plugins (already growing into a rich ecosystem), whereas SAM has relatively limited capabilities due to being tightly coupled with AWS and its CloudFormation deployment service. While a basic Serverless Framework app could be portable across cloud platforms (currently AWS, GCP, Azure, and OpenWhisk), customizability and advanced features still have to be achieved via platform-specific configurations.

Additionally, we see different forms of serverless development tools in emergence: frameworks like Apex, Up, and Spring Cloud Functions; design stacks like Project Flogo; IDEs like AWS Cloud9 and SLAppForge Sigma; API-centric tooling like Shep and Lambda Forest; testing tools like SAM Local, and so forth. Anibal maintains an extensive curated list of tooling in his GitHub repo, which is one of the most comprehensive sources for staying current with serverless technologies.

Operational concerns of serverless — security, compliance, monitoring, and management — are just as important as the development aspect. PureSec, Protego, and other security-oriented ventures are introducing security best practices to the serverless world (least privileges for function runtimes, vulnerability analysis, DDoS/attack detection, and so forth) whereas others like Dashbird, IOpipe, and Epsagon are improving the monitoring aspects via unified dashboards, log analysis, automatic alerting and throttling, performance tracking, and cost estimation/prediction.

Many prominent enterprises are already moving parts of their production workloads to serverless. Prominent figures include Coca-Cola, The New York Times, Thomson Reuters, Fuji, and Localytics. So far, these have been mainly focused on event-driven workloads such as analytics, IoT coordination, on-demand image processing, and email sending. However, there are also full-stack examples like OpenGamma and Torii. Furthermore, recent surveys by Serverless, Inc. revealed that, among its respondents, the percentage of enterprise serverless usage has increased from 43% in 2017 to 82% in 2018.

Fragile: Handle with Care

Despite its traction and popularity, it should never be forgotten that serverless is no silver bullet for all your cost and scalability issues. In fact, beyond a certain point, serverless can be more expensive than dedicated provisioning; and this point can be closer to reality than you expect. As a rule of thumb, if your application needs continuous computation at a higher concurrency (the latter being inevitable for cases like HTTP request handling), you are better off running a dedicated compute instance (which can usually serve multiple concurrent requests and generally has access to larger memory and disk capacities as well). Despite the lack of “ops-free” benefits on serverless provisioning, there are written accounts of how untamed scalability can wreak havoc with your bill as well as on how giving up on serverless can cut down your costs by orders of magnitude.

“Going serverless” is not an overnight feat, especially when “serverfull” architecture is already baked into your systems, developers, and maintainers. The “think serverless” initiative should be adhered to from the start of a project, with developers, team leads, architects, and even project managers being well aware of the strengths, limitations, and pitfalls of the serverless “version” of what they are about to implement. Without a well-planned architecture, a serverless system can very easily turn into a mess or a white elephant — the chances are much higher than with a “traditional” server architecture.

Despite all these hardships, pitfalls, and controversies, serverless will survive — and thrive — just like it is doing now. Grab it by its correct end, and you’ll attain your nirvana.

#aws #web-service #microservices #serverless