What is serverless?
What does it mean to be serverless? And how do serverless options from AWS, Azure, and Google Cloud compare? Explore the basics of serverless and FaaS.
Jun 08, 2023 • 7 Minute Read
What does it really mean to be serverless? And how do serverless options offered by Amazon Web Services, Microsoft Azure, and Google Cloud Platform compare?
In this post, we explore the basics of serverless and FaaS (or Functions as a Service) and look at serverless options across AWS, Azure, and GCP. Read on for more!
Accelerate your career
Get started with ACG and transform your career with courses and real hands-on labs in AWS, Microsoft Azure, Google Cloud, and beyond.
What is serverless?
What do we mean when we say "serverless?"
Serverless is one of those terms that’s used for all sorts of stuff — some legitimate and some marketing fluff. But, in essence, serverless is a design approach that lets you build and run entire applications without having to directly manage servers.
Yes, there are still servers in serverless, but you won’t ever have to worry about their capacity, performance, patching, or fault tolerance.
This is a big plus for developers, but an even bigger benefit is scalability.
With serverless, apps can scale up and down 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.
First introduced in 2008, Google App Engine is considered by many to be the OG in public serverless offerings. In fact, there was a Google App Engine before there was even a Google Cloud Platform (if you’re curious, check out our History of Google Cloud Platform). It featured a metered pay for what you consume pricing model and allowed users to execute Python code discreetly.
Fast forward to today, and serverless is all the rage!
What is FaaS (Functions as a Service)?
At the heart of serverless architectures we have Functions as a Service, or FaaS.
These services are typically event-driven, so when something happens — for example, a REST API request comes in — the function will jump into action and perform whatever task you program it to do.
All support major development languages such as Python, Java, Node.js, and C#. If your language of choice isn’t covered, each of these services allows you to bring your own runtime. Although the methods to do this vary across providers, you basically create a custom Docker container and configure the FaaS platform to use that as a runtime.
What are serverless frameworks?
You might hear people talk about creating 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 hundreds of functions, it can get problematic. This is where serverless frameworks come into play. 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, complete with a cute squirrel mascot (who we’re guessing is called Sam). It’s built from the ground up to work with AWS resources and makes creating and deploying functions on AWS very simple.
On the downside, it does only work with AWS. If you’re looking for multicloud compatibility, you might want to check out the Serverless Framework. It supports several clouds, including AWS, Azure, and GCP, and is a pretty popular and well-documented framework.
What is orchestration?
Having a framework and a collection of functions is all well and good, but for serious applications, you need some way to tie these functions together. We call that orchestration. If you come from a more traditional IT architecture background, this would be our middleware, letting us chain together discrete functions into something that does what we need it to do.
Now, you could use traditional middleware, but cloud providers 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, and AWS has something similar called Step Functions.
For all their promise, serverless applications can be a pain to troubleshoot and debug. The most common way to debug serverless components is usually to debug locally before deploying to the cloud. AWS, Azure, and GCP all have a rich set of tools that allow you to simulate most components locally, and let you step through your serverless code right in your IDE.
Once your serverless app is on the cloud and out 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 apps to help pinpoint errors or 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 to. AWS provides this via Amazon CloudWatch and you can do the same in GCP through the Cloud Logging and Error Reporting services. Azure lets you review logs from the App Service platform, or you can also pipe them to Application Insights as well.
Want to learn more about serverless?
We’ve really just scratched the surface here, but hopefully this gives you an idea about how AWS, Azure, and GCP compare when it comes to serverless. To really dig in, check out this more detailed comparison of AWS Lambda, Azure Functions, and Google Cloud Functions.
We also have plenty of great serverless training content and hands-on labs — below are a few of our recommendations!