- 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.
(techno music)
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.
(techno music)
Serverless is one of those terms
that gets used for all sorts of stuff,
some legitimate and some complete marketing fluff.
(bubble popping) In essence,
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.
(air whooshing)
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.
(techno music)
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.
(air whooshing)
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.
(techno music)
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.
(air whooshing)
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.
(techno music)
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.
(techno music)
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.
(air whooshing)
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.
(techno music)