You may already understand the essentials of serverless architecture. But what does the overall serverless ecosystem look like, and what options do you have? In this guide I map it all out for you. I'll start with function as a service (FaaS), the linchpin of serverless computing, and expand into the cloud services used for building serverless architectures across major public and private cloud providers. From there I'll review the frameworks and tools you can use when building systems using a serverless stack. Finally, I'll draw the boundaries around "serverlessland" and show you where it lives in the overall world of cloud services.

It all started with FaaS

Despite vendor claims that serverless computing was born long ago, it actually started with the arrival of FaaS. The preview release of AWS Lambda, announced in November 2014, put FaaS firmly on the cloud computing map. (Amazon promoted Lambda to general availability status in April 2015.)

Yes, it was possible to run applications without directly managing servers before FaaS, using Google App Engine, Heroku, AWS Elastic Beanstalk, and others. But those compute services never offered a function-oriented execution model or per-invocation billing. Instead, they usually provided elastic scalability for server- or application-oriented workloads.

After AWS arrived, the other big public cloud providers began working on their own FaaS platforms. Azure Functions was released in preview in March 2016 and became generally available the following November. The preview release of Google Functions was released in February 2016 and promoted to beta on March 2017. The date of general availability is still unknown. There are many other FaaS platforms out there as well.

Why functions are not enough

While FaaS provides a way to execute arbitrary business logic using the function as a deployment and execution unit, by itself it’s not particularly powerful. The power of a serverless platform is only realized when you can integrate functions with many other services to build complete architectures.

Many people use the terms FaaS and serverless interchangeably, but there's an important distinction between the two concepts.

FaaS is a compute service that uses functions as the primary abstraction for deployment, scalability, execution, and billing.

Serverless is a form of platform as a service (PaaS) that's ideal for event-driven, potentially volatile workloads. It combines FaaS with other cloud services to build complicated systems, while offering scalability, operability, integrated security, and pay-per-use billing.

Serverless platforms: The options

At the moment the most effective way to build serverless architectures is to pick one of the many serverless platforms on offer and take full advantage of all of its capabilities. Here are your choices:

Amazon Web Services

Amazon was the first major cloud provider to roll out FaaS capability, in the form of AWS Lambda.

The power of a serverless platform is determined to a substantial degree by the number and quality of capabilities you can leverage within it. On AWS, functions can be triggered by an increasing number of other services. These include notifications from S3 buckets, HTTP requests from API Gateway, record changes in DynamoDB tables, messages arriving on SNS topics, and Kinesis streams. Lately, AWS has placed more emphasis on FaaS as the primary, or even sole, compute service that integrates with many of the new services.

You can use AWS Lambda functions to power IoT back ends, Alexa skills, conversational bots using Lex, and workflows with step functions. And the FaaS compute approach is being pushed into other execution environments, such as when using functions to augment the behavior of CloudFront, Amazon’s content delivery network, and even into IoT devices, with AWS Greengrass.

As with any other distributed system, building serverless architectures requires excellent support from IT operations. AWS Lambda integrates seamlessly with CloudWatch, the monitoring and logging service. Besides providing out-of-the-box log aggregation and metric collection, AWS CloudWatch lets you use Lambda functions to customize the operational capabilities of the platform.

Recently, X-Ray, a distributed tracing service, started supporting AWS Lambda (preview release) so that you can monitor and trace complex data flows. And AWS IAM, the identity and access control service, provides an integrated and fine-grained security model for function execution.

Azure adopts a more structured configuration model for its functions. It allows input and output bindings to be attached to the function, greatly simplifying—or completely removing—the code required to integrate with other services from within the function itself. Contrast this with AWS, where the SDK must be used for any form of integration. Similarly, Azure enables a few external integrations out of the box. For example, you can send text messages via Twillio or email messages using SendGrid.

When it comes to operational support for the serverless platform, however, Azure falls a bit short of AWS. Monitoring metrics are only available when using the App Service plan, which requires running a function on virtual machines managed by the cloud tenant. Is that really serverless?

And if functions are executed on the provider-managed compute, no monitoring information is available. Instead, Azure provides a set of guidelines. Also, it defines security policies for functions implicitly, based on input and output bindings, rather than explicitly configuring them using a dedicated service, as with AWS.

Operationally, GCP provides well-integrated support for the functions in Google's Stackdriver monitoring service. As with AWS, logs emitted from Google Functions are automatically stored, in this case by Stackdriver. Logging and metrics are recorded by Stackdriver Monitoring, and GCP offers a Stackdriver Debugger that you can use to investigate the behavior of function’s code. That's quite helpful when troubleshooting. GCP’s security model is somewhat different from that of AWS, however, and it doesn't yet provide support for fine-grained security policies.

IBM Bluemix/OpenWhisk

IBM Bluemix is a PaaS offering that includes Apache OpenWhisk, an open-source FaaS/serverless platform with capabilities similar to offerings from the big three public cloud providers. Because OpenWhisk is an open-source project, you have complete visibility into the workings of the FaaS platform, and it's extensible and customizable. When running Bluemix, you can run OpenWhisk on your own infrastructure on-premises, in the cloud, or as a fully managed platform.

Functions (called "actions "in OpenWhisk) can be triggered by HTTP requests, messages from Apache Kafka or Message Hub topics, changes in Cloudant noSQL DB tables, scheduled events, or virtually any type of external system, provided an integration has been created for it.

From an IT operations point of view, OpenWhisk focuses mostly on the visual presentation of activities associated with function execution but also allows command-line interface-based polling for activity logs. Sadly, metrics, logging collection, and storage are not yet available, and the security model is not very well defined or documented. Developers may need to manage it explicitly, without a great deal of support from the platform.

Other FaaS platform choices

Many other products and projects are competing for a place in the serverless space. Some only offer FaaS capabilities (optionally with HTTP access to functions), while others provide a few other services, such as messaging or storage. Most started as BaaS providers and have rebranded themselves as serverless products. A few of note include:

Iron.io, one of the most complete platforms in this group. It offers a FaaS product called IronWorker, as well as a distributed queue service (IronMQ) and cache service (IronCache).

PubNub, which allows for arbitrary code, called blocks, to execute within real-time messaging flows while it takes care of managing scalability of the compute stack.

Webtask.io, a mobile BaaS platform that you can use for running arbitrary code. It's packaged as "webtasks" and offers good support for creating Slack bots.

Hook.io, a similar product that offers its own key-value data store, as well as integrations with many cloud storage services.

Frameworks and tools

While serverless platforms sounds great, they don't always offer the best developer experience. That's why it makes sense to create or use frameworks and tools. In fact, the serverless space is experiencing something like the Cambrian Explosion when it comes to available tool options. New offerings are emerging rapidly, and you have many choices.

Besides frameworks, you can find many tools that can help you build and deploy functions or serverless architectures. For example, you can use HashiCorp Terraform as an alternative to your provider's own infrastructure-provisioning capabilities (such as AWS CloudFormation). Other popular tools include Apex, Gordon, and Kappa.

Where serverless fits in the cloud computing landscape

Many technologies and products provided PaaS and BaaS capabilities before either FaaS or serverless became popular. You had lots of SaaS products offering anything that could possibly be consumed either as an end-user functionality or a third-party product that could be integrated into an application or a system.

These categories are still relevant now, even with FaaS and serverless entering the cloud computing landscape. To recap:

FaaSis a high-abstraction compute service where the service provider takes full control over managing compute resources, including the runtime process executing the code.

Serverless describes a specialized PaaS that combines FaaS for compute with other managed cloud services in order to create scalable architectures that are cost-effective to operate.

BaaS offers back-end capabilities to browsers or mobile apps. It can be delivered on top of the serverless stack, as well as on a container-as-a-service (CaaS), infrastructure-as-a-service (IaaS), or other technology stack.

SaaS just means any software-based system offered without the need to run it on your own infrastructure. SaaS systems can be built on any technology stack; what matters is how users consume it.

No doubt, the word serverless will be used to describe all of these other services, and that may confuse many people. But that’s okay, as long as in the end the IT industry experiences even greater innovation. Your businesses will certainly benefit from the increased business agility that comes from adopting serverless computing.