What is serverless?

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 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!

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.

AWS calls their FaaS offering Lambda, Azure has Functions, and GCP has Cloud Functions.

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.

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.

There are a few other frameworks out there, such as Zappa, Apex Up, and Architect. Some people also use Terraform and Pulumi for their serverless landscape, 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 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.

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! 

• Serverless Concepts
• Intro to Serverless on Azure
• Serverless Computing with Azure Functions
• Introduction to Serverless on Google Cloud
• Google Cloud Functions Deep Dive
• Automating AWS with Lambda, Python, and Boto3

Get the Cloud Dictionary of Pain
Speaking cloud doesn’t have to be hard. We analyzed millions of responses to ID the top concepts that trip people up. Grab this cloud guide for succinct definitions of some of the most painful cloud terms.