- Serverless, where on earth do we begin? Where do we end? What do we cover? And what do we exclude? This Cloud Comparison might've been just one of the most challenging to write, and I'm sure someone somewhere is gonna take exception to how we cover this topic but here goes.

In this Cloud Comparison, we're gonna do our best to compare the serverless options offered by AWS, Azure and GCP. I'll focus on frameworks, functions, orchestration, and debugging and yes, technically any service you can call as a pay-per-use API could be considered serverless. Hence, where do we draw the line? For me, it's gonna be around the services that we might've already covered in other Cloud Comparison episodes. For example, AWS has DynamoDB or Azure's Cosmos DB could easily be considered serverless, but we've already covered those in the Database Comparison episode. Same goes for all the AI and ML services that providers have packaged up into APIs.

Yep, that fits into a serverless bucket too, but you can check out our episodes on AI and ML for those comparisons.

Serverless is one of those terms that gets used for all sorts of stuff, some legitimate and some complete marketing fluff.

serverless is a design approach that lets you build and run entire applications without having to directly manage servers. With traditional infrastructure-as-a-service offerings, you're responsible for the care and feeding of the operating system and any applications that live on that server. Now, be assured that we still have servers and server lists, but you'll never have to worry about their capacity, performance patching or fault tolerance. For developers, not having to deal with servers is a big plus, but an even bigger benefits is scalability. With serverless, our apps can just scale just about as large as we could ever want, and then they can scale down to zero without us having to do anything at all.

With traditional server-based applications, you're likely to always have something up and running in case your users need it. With serverless, if you're not actively using it, there's no processing and nothing to pay for. Google App Engine is considered by many to be the OG of public serverless offerings, being introduced back in 2008.

In fact, there was a Google App Engine before there was even a Google Cloud Platform. It featured a metered pay-for-what-you-consume pricing model and allowed users to execute Python code discreetly. Fast forward nearly 14 years later and serverless is all the rage. Let's see how the clouds compare today.

At the heart of serverless architectures, we have functions as a service. Functions as a service or FaaS, as they're sometimes called, are typically event-driven. When something happens, say a REST API request comes in, the function will jump into action and perform whatever task you program it to do. GCP calls theirs Cloud Functions, and Azure just went with Functions. AWS calls their service Lambda.

All these services support the major development languages, such as Python, Java, Node.js, and C#. If by chance your language of choice isn't covered, all these services allow you to bring your own runtime. Now, although the methods to do this vary across provider, you're basically creating a custom Docker container and configuring the function as a service platform to use that as a runtime.

You might hear people talk about serverless frameworks. Creating a few functions is, usually, no big deal to manage and deploy, but if you're trying to manage an entire application that consists of, maybe, hundreds or even thousands of functions, that gets problematic. This is where serverless frameworks come in to play, and they're, usually, sets of utilities that make it easy for you to manage and deploy large quantities of serverless resources and functions. AWS built its own framework called the Serverless Application Model or SAM for short, complete with a cute little squirrel mascot, presumably named SAM.

It's built from the ground up to work with AWS resources and makes creating and deploying functions on AWS very simple. Now, on the downside, it does only work with AWS. If you're looking for multi-cloud compatibility, you might wanna check out the Serverless Framework. It supports several clouds, including AWS, Azure and GCP and is pretty popular and well-documented. There are a few other frameworks out there, such as Zappa, Up Architect and people also use Terraform and Pulumi for their serverless landscapes, especially if they already use those for infrastructure as code.

Having a framework and a collection of functions is all well and good, but for serious applications, you really need a way to tie all of these functions together, and we call this orchestration. If you come from a more traditional IT architecture background, this would be where our middleware comes in, letting us chain together discrete functions into something that does what we need it to do. Now, one could use traditional middleware to do this, but our cloud providers do have some tools of their own. Azure Durable Functions are an extension of Azure functions that lets you create stateful workflows using what it calls orchestration functions and entity functions. GCP's recommended serverless orchestration tool is Workflows.

AWS has something similar called Step Functions.

For all their promise, serverless applications can be a real pain to debug and troubleshoot. Usually, the most common way to debug serverless components is to debug locally before deploying to the cloud. All the cloud providers we talk about here have a rich set of tools, which allow you to simulate most components locally and let you step through your serverless code right in your IDE, but once your serverless app is on the cloud and in the real world, things get a little more tricky. If you're working on AWS, you can use AWS X-Ray to run traces on your app and help pinpoint errors and performance bottlenecks. With GCP, you can do something similar with Cloud Trace.

Azure's distributed trace tool is called Application Insights.

Of course, you can still get down and dirty with the logs of your serverless app, if you want. AWS provides this via Cloudwatch, and you can do the same in GCP through Cloud Logging and error reporting services. Azure lets you review logs from the App Service platform, or you can also pipe them into Application Insights as well. Well, we have really just scratched the surface of serverless. There are entire books on this topic but hopefully, this episode gave you some idea of how Azure, AWS and GCP compare.

To really dig in, We have plenty of great serverless training content and hands-on labs over on the A Cloud Guru platform, which cover all three platforms mentioned here. That, my friends, has been Cloud Provider Comparison, Serverless Edition. If you're so inclined, why not subscribe to be alerted on future episodes or give us a thumbs up and let us know you've found this useful? Thanks for sticking around. Stay safe. Take care of one another and keep being awesome, cloud gurus.