Choosing a Serverless Framework
If you’ve been living on this planet at any point in the last couple years you’ve probably heard of “serverless”. In case you haven’t, I’ll give you the quick rundown.
“Serverless” is a very confusing name for a cloud computing model in which a cloud provider runs the servers (yes, there are technically “servers” involved) and dynamically manages the allocation of resources. What this means in simple terms is:
- You don’t have to configure or manage your own server.
- You only pay for server resources while you are actually using them.
- Your application scales up and down dynamically to meet demand, without any extra effort on your part.
Sounds pretty awesome, right? Well, it is, but as with all good things it comes with some caveats. For instance, by going serverless, you are putting yourself at the mercy of a particular cloud provider. Because after all, they own the servers and they control what goes on them. This includes how they get allocated, how much you pay for using them and what they can do.
That’s why it’s very important that you choose the right cloud provider for your needs. For all those awesome features in points 1, 2 and 3 above, you are giving up a lot of control that you would normally have in a traditional server environment (even if those servers are cloud-hosted).
The three big players in cloud computing – AWS, Google and Azure – all have their own serverless frameworks. I’ll be going over the benefits and drawbacks of all three so you can make an informed decision about what direction to go with your serverless architecture.
First of the big three on the scene was AWS’s Lambda functions. This function-as-a-service platform was introduced in November of 2014.
AWS Lambda supports the following development languages:
- C# (.NET Core only)
AWS Lambda is a well-developed platform and one of the most widely used services in AWS. The language support covers the most popular languages. And in 2018, AWS introduced custom runtimes, making it possible to run a Lambda function in any language of your choice, though the process to get that working is a little more involved.
Lambda also pairs well with other AWS services you may want to use in your serverless application. Aurora is a serverless SQL database option. API Gateway interfaces smoothly with lambda functions to create and manage APIs. Cognito manages users, roles and authentication (and also integrates nicely with API Gateway).
It’s worth noting that AWS Lambda functions can only run in a Linux environment so “language of your choice” really means Linux-compatible language of your choice. If you’re looking to run something Windows specific, you might be interested in the next major player (although if you are heavily invested in Windows you probably already knew that).
In 2016, Microsoft announced their competitor to AWS Lambda, Azure Functions. Azure Functions has support for both Windows and Linux runtimes, and has a decent number of supported languages. Along with that, if you do your development in Visual Studio, there are a number of built in tools and features to help you develop, publish and test serverless applications on Azure.
Azure Functions support the following development languages:
- C# (.NET 4.7 and .NET Core 2.2, 3.1)
Azure doesn’t have quite as extensive a cloud offering as AWS but if you are invested heavily in a Microsoft / Windows stack, it’s a very compelling option. Azure also provides an API management service similar to AWS API Gateway.
Google’s implementation of a serverless architecture is called Cloud Functions. Introduced in 2017, it’s the newest player on the field among the big three. In the cloud services realm Google has historically been an underdog to AWS and, to a lesser extent, Azure. However, Google is investing heavily in their cloud offerings so there’s no reason to think that Google Cloud Functions won’t continue to grow into a major player.
Google Cloud Functions supports the following development languages:
As the newest player of the three on the scene (not just for serverless, but for cloud services in general), Google’s offerings are a little more limited. However, the ability to trigger Cloud Functions with Google Pub/Sub can ultimately give you the flexibility to trigger your cloud functions through any Google Cloud service and many outside services. There will be a lot more customization required on the developer’s end than what you might encounter with AWS or Azure.
If you are content with using one of the languages supported and are able to stick to a simple triggering method or willing to put in the development time for anything more complex, Google Cloud Functions is a solid option.
Serverless Triggering Options
An important consideration when choosing a serverless framework is how you are going to trigger your functions. Each of the 3 providers covered here presents a few different options.
The list of ways you can trigger a lambda function is extensive. You can use API Gateway to direct your REST API or send a WebSocket API request to your lambda functions. You can use cron to run them on a schedule. And you can trigger them with a S3 upload or from Amazon’s SQS service.
You can even trigger them from another lambda function, which was triggered by a lambda function, which was triggered by a lambda function, and so on.
For a full list of options, see Invoking AWS Lambda functions from the AWS Lambda Developer Guide by AWS.
Azure Functions also support a wide range of trigger types, very similar to Lambda. Microsoft lists the most common types as: Timer, HTTP, Blob (Azure equivalent to Amazon’s S3 storage), Queue (Azure equivalent to Amazon’s SQS), Azure Cosmos DB, and Event Hub.
For a full list of Azure’s options, see Azure Functions triggers and bindings concepts from Microsoft’s Azure Functions documentation.
Google Cloud has the most limited official options for triggering functions. They natively support the following trigger mechanisms:
- Cloud Pub/Sub
- Cloud Storage
However, it is possible to use their Cloud Pub/Sub topic functionality to integrate with other Google services that support Cloud Pub/Sub as an event bus. See the Events and Triggers page of Google’s Cloud Functions documentation for more details.
Another important consideration when choosing a serverless framework is overall pricing. This can be difficult to digest because it’s both granular and subject to selected configurations. But in all cases it centers on utilization. In other words, you pay for what you use.
To help put these numbers into perspective, we’ll take a look at the actual cost of a project we have running on AWS Lambda. The application gets moderate to high usage and has some relatively complex computing needs (e.g. video and image processing).
Pricing for AWS Lambda Functions is based on executions and compute time. Adding Provisioned Concurrency enables greater control over performance, but it comes at a higher price point. See Amazon’s pricing page for full details.
At a glance:
- $0.20 per 1M executions (1M executions included per month while in the free tier)
- $0.0000166667 per GB-second (400,000 GB-seconds included per month while in the free tier)
For our case study application described above, the actual cost for a single month amounts to $21.42. Not bad.
Pricing for Azure Functions is also based on executions and compute time. In addition, Microsoft offers a Premium plan at a different pricing point, which comes with some advanced features. See Microsoft’s pricing page for full details.
At a glance:
- $0.20 per 1M executions (1M executions included per month)
- $0.000016 per GB-second (400,000 GB-seconds included per month)
For our case study application described above, the actual cost for a single month amounts to $20.57. Not bad.
Pricing for Google Cloud Functions is a little more nuanced. Like the others, it is based on executions and compute time. However, you can assign one of five different memory and CPU configurations to a function, which affects overall costs. Also, regions are priced at different tiers. See Google’s pricing page for full details.
At a glance:
- $0.40 per 1M executions (2M executions included per month)
- $0.0000025 per GB-second (400,000 GB-seconds included per month)
- $0.0000100 per GHz-second (200,000 GHz-seconds included per month)
For our case study application described above, the actual cost for a single month amounts to $36.92. While this is higher when compared with the other offerings, it’s based on Tier 1 pricing with a 2048 MB memory and 2.4 GHz CPU configuration. Lower configurations are available and would bring cost down.
If you’re looking to leverage a serverless framework to implement an API, beyond looking into each service’s function capabilities, you are likely going to want to compare their API Management platforms. You can, of course, create your API using HTTP triggers and not use an API Management service, but that is a lot more work. All three provide a similar product for API Management:
AWS – API Gateway
Azure – API Management
Google Cloud – Cloud Endpoints
As usual, AWS provides the most mature and developed option here. API Gateway offers more features than either of the competitors. Azure’s offering is a worthy contender and Google Cloud’s is the most barebones option by far. I won’t go too much into detail about each of these options here (that warrants its own blog post). However, it is worth noting that if you want to use a WebSocket API, currently AWS API Gateway is the only option that supports it.
Concurrency and Execution Time
Concurrency is the number of requests that your function is serving at any given time. When your function is invoked, the framework allocates an instance of it to process the event. When finished, the function can handle another request. If the function is invoked again while a request is still being processed, another instance may be allocated, which increases the function’s concurrency.
AWS enforces a concurrency limit of 1,000 simultaneous executions (this is account wide, per region) and a maximum execution time of 15 minutes. (As a point of note, API gateway enforces a maximum execution time of 29 seconds.) Concurrency limits can be modified for an individual function up to the hard limit of 1,000.
Azure limits each function to 200 instances. But, each instance can process more than one request, so there’s not a set limit for concurrency rate. For HTTP triggers, new instances are allocated, at most, one per second. For non-HTTP triggers, it’s once every 30 seconds; though, scaling is faster with the Premium plan. On the default hosting plan, maximum execution time is 10 minutes.
Google cloud provides unlimited concurrency for HTTP triggers and a 1,000 limit for other trigger methods. By default, a function times out after 1 minute, but you can extend this period up to 9 minutes.
Amazon, Microsoft and Google all provide some production-ready serverless computing options which interface nicely with each company’s corresponding suite of cloud services. When it comes to serverless frameworks, you are really tying yourself heavily to the cloud provider you use. Therefore, it’s important to pick a provider that, well, provides what you need.
If you have existing infrastructure on one of these providers, the easiest option for you may be to stick with that provider and just do the specific research to ensure that their serverless option offers all the functionality you need before you get too far into your project. If you are starting from scratch or looking to switch providers, you really can’t go wrong with AWS. They’ve been around the longest in this market, they offer the most services, and they are far and away the most widely used. That being said, if you are heavily invested in a Microsoft / Windows development stack, it may be worth considering Azure as they put a particular focus into supporting features and tools for this (naturally). And if you are looking to actually run your serverless functions in a windows environment, Azure is the only provider who offers that.
All in all, the most important thing is to do your research. Serverless technology is a powerful development in cloud computing and its certainly here to stay. However, you should be cautious about which cloud provider you tie yourself to, because it is just the nature of serverless architecture that you are at the mercy of your cloud provider, in terms of what you can and cannot do.