Overview

Many of the serverless offerings at the time of writing of this report (mid-2016) are rather new, and the space is growing quickly.

Table 2-1 gives a brief comparison of the main players. More detailed breakdowns are provided in the following sections.

Note that by cloud offering, I mean that there’s a managed offering in one of the public clouds available, typically with a pay-as-you-go model attached.

AWS Lambda

Introduced in 2014 in an AWS re:Invent keynote, AWS Lambda is the incumbent in the serverless space and makes up an ecosystem in its own right, including frameworks and tooling on top of it, built by folks outside of Amazon. Interestingly, the motivation to introduce Lambda originated in observations of EC2 usage: the AWS team noticed that increasingly event-driven workloads were being deployed, such as infrastructure tasks (log analytics) or batch processing jobs (image manipulation and the like). AWS Lambda started out with support for the Node runtime and currently supports Node.js 4.3, Python 2.7, and Java 8.

The main building blocks of AWS Lambda are:

• The AWS Lambda Web UI (see Figure 2-1) and CLI itself to register, execute, and manage functions

• Event triggers, including, but not limited to, events from S3, SNS, and CloudFormation to trigger the execution of a function

• CloudWatch for logging and monitoring

Figure 2-1. AWS Lambda dashboard

Azure Functions

During the Build 2016 conference Microsoft released Azure Functions, supporting functions written with C#, Node.js, Python, F#, PHP, batch, bash, Java, or any executable. The Functions runtime is open source and integrates with Azure-internal and -external services such as Azure Event Hubs, Azure Service Bus, Azure Storage, and GitHub webhooks. The Azure Functions portal, depicted in Figure 2-2, comes with templates and monitoring capabilities.

Figure 2-2. Azure Functions portal

As an aside, Microsoft also offers other serverless solutions such as Azure Web Jobs and Microsoft Flow (an “if this, then that” [IFTTT] for business competitors).

Google Cloud Functions

Google Cloud Functions can be triggered by messages on a Cloud Pub/Sub topic or through mutation events on a Cloud Storage bucket (such as “bucket is created”). For now, the service only supports Node.js as the runtime environment. Using Cloud Source Repositories, you can deploy Cloud Functions directly from your GitHub or Bitbucket repository without needing to upload code or manage versions yourself. Logs emitted are automatically written to Stackdriver Logging and performance telemetry is recorded in Stackdriver Monitoring.

Figure 2-3 shows the Google Cloud Functions view in the Google Cloud console. Here you can create a function, including defining a trigger and source code handling.

Figure 2-3. Google Cloud Functions

Iron.io

Iron.io has supported serverless concepts and frameworks since 2012. Some of the early offerings, such as IronQueue, IronWorker, and IronCache, encouraged developers to bring their code and run it in the Iron.io-managed platform hosted in the public cloud. Written in Go, Iron.io recently embraced Docker and integrated the existing services to offer a cohesive microservices platform. Codenamed Project Kratos, the serverless computing framework from Iron.io aims to bring AWS Lambda to enterprises without the vendor lock-in.

In Figure 2-4, the overall Iron.io architecture is depicted: notice the use of containers and container images.

Figure 2-4. Iron.io architecture

Galactic Fog’s Gestalt

Gestalt (see Figure 2-5) is a serverless offering that bundles containers with security and data features, allowing developers to write and deploy microservices on-premises or in the cloud.

Figure 2-5. Gestalt Lambda

IBM OpenWhisk

IBM OpenWhisk is an open source alternative to AWS Lambda. As well as supporting Node.js, OpenWhisk can run snippets written in Swift. You can install it on your local machine running Ubuntu. The service is integrated with IBM Bluemix, the PaaS environment powered by Cloud Foundry. Apart from invoking Bluemix services, the framework can be integrated with any third-party service that supports webhooks. Developers can use a CLI to target the OpenWhisk framework.

Figure 2-6shows the high-level architecture of OpenWhisk, including the trigger, management, and integration point options.

Figure 2-6. OpenWhisk architecture

Other Players

In the past few years, the serverless space has seen quite some uptake, not only in terms of end users but also in terms of providers. Some of the new offerings are open source, some leverage or extend existing offerings, and some are specialized offerings from existing providers. They include:

• OpenLambda, an open source serverless computing platform

• Nano Lambda, an automated computing service that runs and scales your microservices

• Webtask by Auth0, a serverless environment supporting Node.js with a focus on security

• Serverless Framework, an application framework for building web, mobile, and Internet of Things (IoT) applications powered by AWS Lambda and AWS API Gateway, with plans to support other providers, such as Azure and Google Cloud

• IOpipe, an analytics and distributed tracing service that allows you to see inside AWS Lambda functions for better insights into the daily operations

Cloud or on-Premises?

A question that often arises is whether serverless computing only makes sense in the context of a public cloud setting, or if rolling out a serverless offering on-premises also makes sense. To answer this question, we will discuss elasticity features, as well as dependencies introduced when using a serverless offering.

So, which one is the better option? A public cloud offering such as AWS Lambda, or one of the existing open source projects, or your home-grown solution on-premises? As with any IT question, the answer depends on many things, but let’s have a look at a number of considerations that have been brought up in the community and may be deciding factors for you and your organization.

One big factor that speaks for using one of the (commercial) public cloud offerings is the ecosystem. Look at the supported events (triggers) as well as the integrations with other services, such as S3, Azure SQL Database, and monitoring and security features. Given that the serverless offering is just one tool in your toolbelt, and you might already be using one or more offerings from a certain cloud provider, the ecosystem is an important point to consider.

Oftentimes the argument is put forward that true autoscaling of the functions only applies to public cloud offerings. While this is not black and white, there is a certain point to this claim: the elasticity of the underlying IaaS offerings of public cloud providers will likely outperform whatever you can achieve in your datacenter. This is, however, mainly relevant for very spiky or unpredictable workloads, since you can certainly add virtual machines (VMs) in an on-premises setup in a reasonable amount of time, especially when you know in advance that you’ll need them.

Avoiding lock-in is probably the strongest argument against public cloud serverless deployments, not so much in terms of the actual code (migrating this from one provider to another is a rather straightforward process) but more in terms of the triggers and integration points. At the time of writing, there is no good abstraction that allows you to ignore storage or databases and work around triggers that are available in one offering but not another.

Another consideration is that when you deploy the serverless infrastructure in your datacenter you have full control over, for example how long a function can execute. The public cloud offerings at the current point in time do not disclose details about the underlying implementation, resulting in a lot of guesswork and trial and error when it comes to optimizing the operation. With an on-premises deployment you can go as far as developing your own solution, as discussed in Appendix A; however, you should be aware of the investment (both in terms of development and operations) that is required with this option.

Table 2-1 summarizes the criteria discussed in the previous paragraphs.

Note that depending on what is important to your use case, you’ll rank different aspects higher or lower; my intention here is not to categorize these features as positive or negative but simply to point out potential criteria you might want to consider when making a decision.

Conclusion

In this chapter, we looked at the current state of the serverless ecosystem, from the incumbent AWS Lambda to emerging open source projects such as OpenLambda. Further, we discussed the topic of using a serverless offering in the public cloud versus operating (and potentially developing) one on-premises based on decision criteria such as elasticity and integrations with other services such as databases. Next we will discuss serverless computing from an operations perspective and explore how the traditional roles and responsibilities change when applying the serverless paradigm.