Serverless Hosting Comparison
A head-to-head showdown of the providers fighting for your dollars
I recently published “Coding for a serverless future” to give a primer about what this new architectural approach means for developers. I alluded to the options available, but I’ve been asked to provide a little more detail about what the main options are for anyone looking to get rolling with serverless right now.
New players are entering this space rapidly, but as you’d expect, the largest cloud providers have the most extensive set of geographical locations and supporting resources for hosting serverless applications.
So who are the players in this space, and what development technologies do they currently support? How much would it cost to build and run your application on these services?
First, a note on comparative pricing
In this article I’m trying to get as much of an apples-to-apples comparison as I can put together at a high level. Things are of course never that simple. Comparisons of pricing won’t take into account the surrounding ecosystem of supporting services and libraries that you might need for your project — nor will it count discounts that apply to your specific circumstances based on your current use of other products by the same vendor.
In addition, it’s impossible to give a “typical” traffic scenario as it will differ wildly between projects, and the examples here aren’t particularly realistic either — they’ve been chosen to show how the pricing model reacts to changes at every level, whether that’s reflective of how a given application might scale or not.
In order to distill the pricing to some kind of common ground where it can be compared on a best effort basis, I’ll provide comparative rates based on four example monthly use cases (all quoted based on each vendor’s official pricing calculator).
Unicorn: 5000ms execution time, 512MB reserved memory, 500m executions
Heavy: 3000ms execution time, 256MB reserved memory, 10m executions
Moderate: 1000ms execution time, 128MB reserved memory, 5m executions
Light: 1000ms execution time, 128MB reserved memory, 1m executions
Lambda (Amazon AWS)
Amazon Web Services (AWS) is usually the first name that comes to mind when you think of cloud computing for good reason — they are by the far the largest provider in this space and are host to a much broader set of supporting tools and resources than any of their competitors.
AWS Lambda is the functions-as-a-service offering that enables serverless development on the Amazon cloud, and as a result of being around the longest, is also the largest service in use currently.
Supported Languages
Lambda currently supports functions written in Javascript (and languages that compile to it) with Node.js, Python, Java (Java 8 is supported) and the Microsoft family of .NET languages (C#, Visual Basic and F#) by way of support for .NET Core.
It’s encouraging to see .NET Core being supported on more providers. It should go a long way to remove any lock-in concerns that people have of adopting the technology with regards to having freedom of movement later.
Documentation and Community
The documentation is comprehensive for Lambda, as you’d expect from the most mature product on this list. It’s updated to reflect new features as they come online too, so there’s no frustrating it-doesn’t-work-like-it-says-it-does moments to contend with.
The community likewise is quite large, owing again to the fact that it’s had that much more time to grow in the almost 3 years since Lambda came onto the scene.
Pricing model
Lambda currently has a free tier that allows for one million requests and 400 terabyte-seconds of compute time per month, which is enough to allow for a lot of runway before you start seeing any bills at all. Requests above this threshold are billed at $0.00001667/GB-s, which is among the lowest of anyone in this space — and is also simple to forecast ahead of time.
Comparative monthly prices
Unicorn: $20,830.83. Heavy: $120.16. Medium: $4.55. Light: $0.00.
Azure Functions (Microsoft Azure)
Microsoft’s Azure platform has been rapidly expanding it’s features (and it’s customer base) in recent years, as it’s been aggressively competing with AWS for a share of this market. The list of supported resources largely parallels what AWS is offering, but Azure also provides quite a few additional features specific to the .NET and Typescript audiences, as you’d expect.
Azure Functions is Microsoft’s serverless offering, and provides a similar functions-as-a-service model to AWS Lambda.
Supported Languages
The landscape here deviates a little from AWS. The languages supported here are JavaScript (and languages that compile to it) with Node.js, C#, F#, Python, PHP, Bash, Batch and PowerShell.
The inclusion of the last three options above is interesting in that Microsoft have chosen to include languages which are traditionally considered most useful for locally managing machine instances and automating tasks. It could be a signal that Microsoft sees serverless extending yet further into the datacenter and is anticipating a large audience among that subset of the dev-ops crowd.
Documentation and Community
As you’d expect, Microsoft has documented every inch of the product extensively — they’re the most experienced company on Earth when it comes to interacting with their developer community, and it shows here.
The community is also growing rapidly, not least as it’s an obvious first choice for developers on Windows and .NET, and because it’s pricing model is extremely competitive as we’ll see below.
Pricing model
Microsoft has put it’s pricing for Azure Functions head-to-head with Amazon, and matched the Lambda free tier identically. When traffic is added in to the cost, the cost estimates are actually the lowest of the large providers when quoting for the same workload. Performance appears to be comparable to other providers based on recent reviews.
This means that between these two big players its likely to come down to which environment you’re more comfortable with, and which provider has the best support for the other technologies that you want to use in your stack.
If you’re working on a technology stack based in the Microsoft world (e.g. .NET), you can at least breathe a sigh of relief that you’re not being treated as a captive audience or ripped off when it comes to billing for your service. In part, this is down to Microsoft offering the lowest going rate for execution of $0.000016/GB-s, which is just a hair lower than Amazon.
Comparative monthly prices
Unicorn: $19,993.60. Heavy: $115.40. Moderate: $3.60. Light: $0.00.
Cloud Functions (Google Cloud Platform)
It won’t surprise anyone to know that all of the “Big Three” of cloud computing each have their own offerings in this space, although Google’s functions-as-a-service product does seem to have received less attention than Microsoft and Amazon’s offerings. I’m a little surprised by this, as when you look under the covers at what Google is providing here its really every bit as compelling as it’s peers (with a few qualms about pricing being my only concern at this stage).
Cloud Functions is Google’s serverless proposition, and while it largely follows Azure and AWS in terms of feature parity, there are a few notable differences.
Supported Languages
Currently Google Cloud Functions only supports Javascript, but it is anticipated (although as yet unconfirmed) that this will be expanding in the near future.
If you think you’re noticing a pattern here, it’s because you are, and it does look (at least for the moment) like it’s really Node.js developers that will have the most options when transitioning to a serverless architecture.
It’s also worth noting (and this is true of other providers too) that other languages which can be compiled to Javascript (e.g. Typescript, Coffeescript) are also perfectly valid candidates when developing software for these services.
Documentation and Community
The documentation is comprehensive for Cloud Functions, and I’ve found it fairly easy to find my way to what I’m looking for with minimal effort.
In terms of community the service does lag Amazon and Microsoft if only because they don’t have the first-mover advantage of Amazon or the extensive developer community of Microsoft to lean on for support. Expect the community to grow substantially over time, though — Cloud Functions is still quite a young product so it will take time to find its audience.
Pricing model
The pricing model for Google Cloud Functions changes subtly from the way it’s been implemented at AWS and Azure — Google’s free tier allows for 2 million invocations per month, with a charge of $0.0000004 per invocation after that. The billing then also takes the network traffic used by your functions in the aggregate into account.
It’s for this reason that I’ve attributed a value of 200kb of traffic per request in the calculations as a baseline, which seems reasonable for a web application.
Unfortunately, the pricing calculator on Google’s website does not appear to take traffic pricing or the free tier into account correctly when pricing estimates — so as a substitute I’m using the calculator at ServerlessCalc.com for the Google quotations.
With the above ominous caveat out of the way, and without further ado, the Google Cloud Functions comparative pricing for our sample workloads…
Comparative monthly prices
Unicorn: $23,321.20. Heavy: $138.95. Moderate: $9.76. Light: $0.00.
These prices should be treated as a really rough ballpark due to the aforementioned calculator issue. Even so, only at our really outlandish Unicorn level are the costs per month starting to show meaningful variation between providers, and based on these prices Google seems to be charging a premium over other providers in the space. I expect (if I haven’t completely misunderstood the pricing) that Google will change this quickly if they want to achieve any kind of traction in this market — or at the least update their calculator to count the free tier correctly.
OpenWhisk (IBM Bluemix + OSS)
It’s interesting to see IBM enter the serverless arena. While they haven’t been a huge player in the cloud space to date relative to their peers, IBM have invested heavily in building out and promoting Bluemix as the future of their online services.
The intrigueingly named OpenWhisk is IBM’s serverless proposition and where it varies quite a bit in terms of both architecture and the extent of the supporting services available to users, it does have a couple of aces up it’s slieve when it comes to it’s developer appeal.
You see, while OpenWhisk is available as a FaaS offering from IBM, at it’s core its also an open-source project under the guidance of the Apache foundation.
In many ways this is the best of both worlds — it largely nullifies any concerns about lock-in, while also providing the benefits of the all-in pay-per-event model that makes serverless so appealing in the first place.
The open-source nature of the project should also lend itself well to building a thriving array of community contributions over time, not only in the form of bugfixes — but in terms of interfaces to third-party services, too.
Supported Languages
Officially, OpenWhisk currently only supports Node.js and Swift — but it’s possible to run just about any language or runtime that you can build a docker container around, albeit with some caveats. There is a stated goal to increase the number of officially supported languages over time, and some work is already underway towards that goal (watch this space!).
Documentation and Community
As you’d expect from an Apache project, the documentation is well fleshed out and expanding constantly. There’s also quite a lot of material available scattered around the web — and the official YouTube channel contains a lot of guidance to help you get started.
Pricing model
Pricing works a little differently on Bluemix than it does on the other large providers in regards to serverless.
While Bluemix also offers the same 400 terabyte-seconds per month free tier that AWS and Azure provide, requests above this level are priced at a rate of $0.000017/GB-s, which is reasonable in and of itself, but just a little above average.
Comparative monthly prices
Unicorn: $21,243.20. Heavy: $120.70. Medium: $3.83. Light: $0.00.
Fission.io (OSS)
I covered Fission briefly in the previous article, but it’s worth mentioning and reviewing again here — as it’s fairly unique on this list in that it’s an open-source framework to provide serverless architecture over Kubernetes rather than an all-in provider like the options above.
This has it’s pros and cons. The obvious negatives are that you’ll still need to engage with a provider to pay “metal” costs to run your application, and you’ll not be free from managing your infrastructure resources to the degree you would be if you went with one of the dedicated FaaS providers mentioned above.
The benefit of Fission is that your code can still be written and executed in a serverless way, and Fission largely handles the work required to automatically scale your resources within Kubernetes as you’d expect it to, freeing you from managing resources manually.
Perhaps the largest benefit of Fission is that (as is the case with OpenWhisk) you’re not locked in to a single provider, and can freely move between providers if they support Kubernetes clusters (and any other specific requirements your application might have).
Supported Languages
Another area where Fission shines is that it doesn’t really care which language your application is written in. As long as you can install the runtime for your chosen language you can create your serverless actions with any technology you wish, with minimal effort.
If you happen to be developing in C#, Go, Node.js, PHP or Python you’ll be happy to know that support is available out-of-the-box today, but extending to additional stacks (as long as the runtimes/compilers are available on Linux, and almost all are) is trivial.
Documentation and Community
At this point in time the Fission community is quite small, although the documentation has good coverage of the major features. If you’re going down this road, it would be best to get involved with their official Slack channel to make sure your up-to-date on what’s going on.
Pricing
Pricing will really come down to how much your chosen provider charges for the infrastructure you need to run either a managed Kubernetes cloud or the shared/dedicated servers to install your own Kubernetes cluster on top of.
In truth, at this point in time it’s unlikely to work out cheaper to run your own Kubernetes cluster in this way, either in terms of real costs or time spent maintaining it — but you do get the benefit in return of being able to leave the provider whenever you so choose which should help keep pricing competitive over the long term.
So that’s a broad head-to-head of the current options available if you want to move to a serverless architecture on your next project. If you’ve spotted any mistakes with the pricing please do let me know and I’ll correct them— I’m eager to have this be a fair comparison.
If you have any other providers / frameworks you think should be on the list and I’ve missed them, please let me know in the comments section below. Finally please click ❤ and (Follow) below if you’ve found the article helpful. It’s really encouraging and it helps me understand which topics people find interesting!
