Serverless on Public Cloud: The Ultimate Showdown
Thundra sponsored this post.
With so many serverless offerings available, making the right choice can be problematic. Getting a straight feature comparison is challenging, as the actual operational characteristics of each serverless platform can vary significantly — from how the serverless functions are invoked, to how they are billed. In this article, we’ll discuss the serverless offerings of each of the three major cloud service providers: Amazon Web Services, Google Cloud and Microsoft Azure. We’ll compare each one against the others and determine a winner based on four criteria: cost, ease of integration, the number of integrable services, and industry adoption metrics.
Reviewing the Landscape
There are three major serverless players we’ll be discussing. The first is AWS Lambda, which was released in 2014 and was the first serverless offering available. It provides trigger integration with numerous AWS products, from simple HTTP-driven events to S3 executions based on file upload characteristics. For many companies, choosing AWS to drive their serverless functions means keeping all of their infrastructures in one place, as by some accounts AWS runs approximately 40% of the cloud market.
The next service we’ll examine is Google Cloud Functions, which runs on the Google Cloud platform and reached general availability on July 24, 2018, after a lengthy beta period. As with AWS, a number of triggers are available for Google Cloud Functions, from simple HTTP triggers to workflows driven by Cloud Scheduler and Cloud Tasks.
The final service of interest is Microsoft Azure Functions, which was released to general availability in 2017. This was after a long beta period, during which Microsoft continued to enhance the ties between Azure Functions and the rest of the Microsoft Azure platform. Microsoft’s offering has extensive notes and documentation, and depending on the version you are running, will allow multiple different services as triggers, input sources, or output sources.
Comparing Microsoft and Google
To begin our comparison, we’ll start by pitting Microsoft Azure Functions against Google Cloud Functions. Both offer scalable function infrastructure that can grow to meet the capacity needs of your serverless application. Let’s look at a few specifics: function execution times, ease of setup/integration, and pricing.
The infrastructure-based execution times for most public cloud services are comparable. Microsoft Azure Functions and Google Cloud Functions both have similar cold start times, with similar amounts of overhead, and since 2017 the gap has only grown smaller. Where Google Cloud Functions had an advantage over Microsoft Azure Functions was in ease of setup. While Microsoft Azure Functions features great flexibility in configuring new items, Google’s UI showcases its origins as a web-first company, with intuitive user interface flows and easily understood options.
As for pricing, Microsoft and Google bill similarly by resources used. Each has a generous free tier that can easily fill the needs of a hobbyist developer. With usage-based billing, both Microsoft and Google billaround $0.000016 per GB-sec and GHz-sec. So ultimately the choice of platform is going to be driven by the degree to which you consume related services. Each offers a similar number of service integrations, so unless you are looking to pursue a multi-cloud approach, making the right choice here may be as simple as choosing the option that exists on your current infrastructure provider’s platform.
Comparing Microsoft and AWS
Next, we compare Microsoft Azure Functions against AWS Lambda. Microsoft Azure Functions, like AWS Lambda, offers a number of different run-times and machine configurations that determine the final resources dedicated to your application. With similar cost structures (both services target $0.000016-$0.000017 per GB-second), there’s not much to distinguish the two services on an operational basis. In user interface, Microsoft has a bit of an edge as well, as their flexible configuration file format gives you more control over the containers running your functions than you would have received on a similar Lambda function in AWS.
AWS Lambda, however — being the oldest player in the game — has a number of benefits that Microsoft Azure simply can’t match. While function execution times and cold-start delays are roughly equivalent, the benefit of the platform’s age is evident in the comparable maturity of the toolchain. Tools like provisioned concurrency and AWS SAM provide a layer of configuration and complexity management that greatly eases the challenge of working with a serverless application, at no additional cost. While Microsoft has arguably done a better job of presenting its functions as part of a larger application, leading to more efficient organization, the progress AWS has made in this realm has mostly closed the gap.
Comparing Google and AWS
We’ll round out the direct comparison portion of our article by pitting Google Cloud Functions against AWS Lambda. As we’ve observed in our other comparisons, these three platforms are roughly equivalent in execution environments, tertiary-service integrations, and even cost levels. Thus, we are best served by looking at secondary characteristics of the ecosystem, as this will point us to the true differentiators.
While Google’s configuration flow is arguably more user-friendly than the AWS approach, this user-friendly approach makes some assumptions about how a platform should be used. While Google Cloud Functions prefers you to spend time in user interfaces, AWS Lambda leverages tools like CloudFormation to give your developers the option to take an infrastructure-as-code approach, improving ownership and maintainability of your application architecture.
The final differentiator in this comparison is third-party support. Because AWS has such a large user base, the type and variety of third-party tools available is simply greater in the AWS ecosystem than it is for Google Cloud. Without adequate third-party tooling, your dashboards and monitoring efforts will be limited to the tools available in your provider’s stack, some of which can be complex to decipher. Third parties like Thundra (working only on AWS for now) add an additional layer on top of these provider-specific interfaces, filling holes in the information flow that would otherwise require custom pipelines to fix.
Our Recommendation: AWS
What we’ve seen above is that most of the serverless cloud providers have reached a kind of feature parity. Execution statistics are similar for each of the three serverless function services, and on a cost basis there’s not much to differentiate the offerings from one another. Thus, for most serverless applications, choosing the “right” provider may simply be a question of how deeply you are already tied into an infrastructure services platform. If your application is already running on Microsoft Azure, it would make sense to look to Azure functions as a potential first option when building your serverless functionality.
For those applications for which you have the flexibility to choose a serverless function provider, tertiary characteristics take precedence in choosing the “right” platform. In such cases, we recommend AWS Lambda as your serverless function provider. AWS Lambda’s maturity and surrounding ecosystem gives it a distinct advantage in terms of usability when compared to Microsoft and Google, and the third-party ecosystem sets it above the rest.
Using AWS, you can leverage tools like Thundra to get a comprehensive view of your serverless application, providing insights beyond the native dashboards that can be critical when monitoring your application’s behavior. Coupled with a significant market share and the ease of integration with services like Route 53, API Gateway and S3, AWS is a clear winner in the third-party ecosystem department and it can help take your application to the next level.
Amazon Web Services is a sponsor of The New Stack.
Feature image via Pixabay.
At this time, The New Stack does not allow comments directly on this website. We invite all readers who wish to discuss a story to visit us on Twitter or Facebook. We also welcome your news tips and feedback via email: feedback@thenewstack.io.