Serverless computing adoption is growing at exponential rates. As with any technology market experiencing hyper-growth, there is a constant supply of new entrants into the market, including some of the biggest names in technology. For most people looking to start leveraging serverless technology in today’s marketplace, the number of options can seem overwhelming, and can lead to decision paralysis. The best approach is to decide based on use case and what knowledge exists within your organization and choose the serverless platform that best fits.
This article will focus on the biggest three public clouds and the largest open source option (as the market is still forming), but these are the providers most people look at first. This means we will be looking at AWS Lambda, Azure functions, Google Cloud Functions, and Apache OpenWhisk. One important note about Apache OpenWhisk is that other than its being available to deploy on your own, multiple hosting providers offer it as a base for their serverless offerings, with IBM Cloud Functions currently the largest.
Development Languages Supported
When it comes to writing your serverless functions, not every language is available on every platform. JavaScript (Node.js) is really the only universally supported language and is the most commonly used in examples within documentation across all providers.
| AWS Lambda | Azure Functions | GCP Functions | Apache OpenWhisk | |
|---|---|---|---|---|
| JavaScript(node.js) | Yes | Yes | Yes | Yes |
| Java | Yes | Yes | No | Yes (Partial) |
| C# | Yes | Yes | No | No |
| Python | Yes | Experimental | No | Yes |
| PHP | No | Experimental | No | Yes |
| Go | Yes (Partial) | No | No | No |
| F# | No | Yes | No | No |
| Swift | No | No | No | Yes |
Accessing Services Within a Function
Accessing services and databases outside of the function you are writing is abstractly more similar than different across platforms than most other features. Once you are writing the code at the core of a serverless function, you can access any remote service you want, just like in any other development environment.
The semantics are around how to access services within the platform you are writing. For example, AWS’s IAM systems allow for access to other AWS resources to be handled outside of the function, where on the other platforms you need to manage environment variables to hold keys, usernames, and passwords for local services as well as remote services.
Triggering a Serverless Function
All serverless functions are launched by an event from a source, and based on how they are written, will either be synchronous (returns data to the caller) or asynchronous (acknowledges the caller, but doesn’t return anything). Outside of technology, think of this more like a phone call being synchronous and mailing a letter would be asynchronous. You may get information back from the letter, but you don’t wait around, and will be notified when it happens.
Google Cloud Functions have the most straightforward list of items that will trigger a function to run. They are an HTTP request (sync), pub/sub message (async), or a direct call to the function which can be either type.
Apache OpenWhisk’s triggers which are used to launch serverless apps deployed on its platform are based on either webhooks or polling using a predefined schedule. A webhook is simply an event that travels over HTTP, and OpenWhisk refers to polling as running on a predefined schedule. In OpenWhisk, once a function is triggered, if it needs any more information than was in the initial request, then OpenWhisk has a concept called feeds which involve retrieving a stream of data from a source system. A feed can be short-lived and managed within the serverless function, or use a concept called connections which leverages an external provider with a persistent connection to the source system, and this allows for better performance when interacting with the remote system and retrieving data.
AWS Lambda and Azure Functions target their offerings as what Google Cloud and OpenWhisk can do, and they can be launched via an incoming event from one of many sources or by leveraging a schedule. Where these two differ is in the use of serverless as a way to extend functionality of their cloud platforms. Additionally, they have extra complexity that both helps and hurts. As an example, AWS Lambda and Azure Functions can respond to HTTP requests, but require use of their respective API gateways. This allows much better reporting and control over requests and access to those HTTP endpoints, but is an extra layer to the architecture which requires additional expertise and can drive up the price if not configured properly.
Azure Functions has the longest published list of services it can be triggered by, but AWS Lambda builds its use case examples to push most events through SNS so a serverless app can be triggered by almost any service it offers on its cloud platform.
Many Azure customers for example use Functions to label all resources with things like who created them and their creation timestamp.
In AWS, customers can use CloudTrail to store logs in S3 and then have it trigger Lambda to parse that log and decide if there is something worth sending a notification on in that log.
Conclusion
All serverless platforms support the use case around running services, usually for a mobile or IoT backend, and also performing ETL functions where data is moved between locations and transformed in transit. Google Cloud Functions and OpenWhisk are aimed primarily at these use cases. If the use case involves extending monitoring or reacting to events within the cloud provider’s infrastructure, then organizations with existing deployments on AWS and Azure will be best served by leveraging the serverless platform that co-exists on their cloud of choice.
So while preferences like development language will drive some selections for which serverless platform to use, the vast majority will be based on existing cloud deployments and exact use cases.
