You have definitely heard about serverless computing of Functions-as-a-Service (FaaS) offerings from multiple cloud providers such as AWS Lambda, Azure Functions, and Google Cloud Functions. While introduced not so long ago (with AWS Lambda released in 2014, Azure Functions launched in 2016, and Google Cloud Functions in 2018), these services are steadily growing in popularity. The reason for this is simple — they remove a ton of overheads and costs when running your workloads in the cloud.

According to a GitLab survey on AWS Lambda usage from 2019, 90% of software engineers use FaaS in their production environments, and 53% have worked with Lambda for 1 to 3 years. More importantly, serverless computing works great for developers and Ops engineers; it is used by large corporations, startups and SMEs alike.

However, serverless computing is not a silver bullet and cannot help in every situation. Today we explore what is serverless computing, when it can (and can’t) be used, compare the functionality of Azure Functions vs AWS Lambda vs Google Cloud Functions and explore which of them work best for serverless architecture.

What is serverless computing?

Serverless computing is the cloud resource allocation model where the cloud vendor provides backend services on an as-used basis, rather than prepaid bandwidth or server capacities. In simple terms, you don’t pay for idling virtual servers. Instead, you upload the code that executes some function and configure various invocation scenarios (webhook, API calls, event triggers), so that you pay per invocation, not per instance.

All the IaaS and PaaS components of cloud vendor’s offers run under the hood so there is no need to handle their scaling and configuration. This sounds like a great solution, allowing you to avoid hiring expensive DevOps engineers to manage your cloud infrastructure. Any developer can use AWS Lambda, Azure Functions, or Google Cloud Functions web interface to configure the service and run your apps in FaaS, right?


What some software engineers and business executives fail to grasp is that FaaS is not a replacement for standard cloud computing instances. It is a glue that allows building event-driven workflows, but it cannot replace standard cloud services — file storage, databases, Kubernetes clusters, monitoring and security features, etc.

The reason is simple. FaaS is not meant to be a replacement for common cloud services and is not built to run 24/7. Functions are executed in invocations, meaning that when they are needed — they run and then are immediately shut down to conserve resources. The key difference with standard cloud instances is that a single instance can handle multiple connections and perform multiple tasks simultaneously, while an invocation is a single function, which is limited in size and execution time.

Serverless computing use case scenarios

If serverless computing does not fit every use case, where does it fit in? It is a great choice for infrequent, stateless, asynchronous, highly-dynamic, and concurrent workloads with sporadic demand and unpredictable resource usage. Think user registration or authentication, financial transactions, etc.

If your app runs as a bundle of microservices, having an instance (or a single container) running a registration module 24/7 is wasteful — because new registrations do not happen non-stop. It is much more feasible to invoke the required function when a new user wants to register and pay for the time the service was actually needed, not 24/7.

Here are other notable examples of FaaS usage:


Business logic. When your app uses a variety of cloud services and features, they can be invoked upon request, via webhooks, API calls, and other methods. This is especially useful for running microservice-based applications.


CI/CD pipelines. When your software delivery process automatically provisions the required environments only when and where they are needed, you save considerably on the software development pipeline, as you don’t run idle servers.


Stream data processing. Leveraging FaaS in complex corporate ecosystems with infinite message queues helps to streamline data processing at any scale.


Batch jobs and scheduled tasks. When you have scheduled jobs and tasks that need to be executed in a batch, serverless computing is a godsend. Invoke infrastructure that enables intense parallel computation, network access, or IO, perform the scheduled tasks, and shut everything down to conserve resources.


HTTP REST APIs for web apps. When your app needs to perform infrequent requests (the aforementioned user registrations and authentications, yeah.)


Chatbots. These should always be operational and meet a wildly fluctuating demand, so FaaS is the obvious choice.


Mobile backends. Why run a mobile app backend non-stop, if you can execute all the required business logic once the users demand it? Build the required workloads on REST APIs and invoke them upon request, not run servers 24/7 just in case.


IoT sensor input management. When an IoT sensor signals some disruption, the infrastructure required to handle the response is invoked, scaled to size, and then shut down.


Multimedia processing. A set of functions required to transform the multimedia object in the needed format starts once a new file is uploaded.


Database changes: auditing the changes made to the database to ensure the quality standards are met.

In short, serverless computing is a perfect choice for irregular jobs with fluctuating resource consumption. But what about use cases when serverless doesn’t work?

When should you avoid using serverless architecture?

Quite the contrary to the previous point, serverless computing is not viable for stateful, long-term, resource-intensive jobs, like Big Data analytics, Machine Learning model training, etc. For example, when a group of researchers at Berkeley used AWS Lambda for ML model training and making predictions, it cost them 57 times more than on EC2. Just imagine wearing shoes on your hands instead of your feet.

The cases when you should avoid using serverless computing:

  • Long-term tasks. Running your apps with FaaS might seem a great idea unless they grow in popularity rapidly. When the user numbers start to kick in, paying per invocation becomes very expensive.
  • Resource-intensive jobs. Training a Machine Learning model is best done using conventional infrastructure, not FaaS.
  • When monitoring is essential. With FaaS you have very limited observability, so monitoring of your operations is literally impossible. Every FaaS platform provides some basic monitoring capabilities, but they are quite rudimentary and non-configurable. You will need to use tools like Dashbird or X-ray to enable at least some visibility.
  • When latency matters. FaaS means cold start every time, so you need to account for it. The more complex the workflow, the bigger the code size, the larger the functions — the longer it takes to invoke them. Python and Go launch the quickest, C# and Java launch the longest. If you need lightning-fast execution, you either need to keep your FaaS warm by invoking them at regular intervals — or avoid going for serverless architecture in the first place.
  • Vendor lock-in. When you go for AWS Lambda, you have a very limited range of database options (namely, DynamoDB or Aurora) to work with. If you wish to use RDS or ElastiCache, you need to connect them via a VPC. Most importantly, should you decide to move to another cloud vendor in the future, you will need to build your functions from scratch using their components. Thus, FaaS equals vendor lock-in.

To sum it all up, serverless architecture is not a “one size fits all” solution, by far. It works great as a glue for multiple aspects of your software delivery pipeline. More work can now be done with requests that bounce between various corners and components of your cloud ecosystem, but FaaS will never replace standard cloud instances in a wide range of cases.

Cloud Migration For Startups

Migrate your business-critical data, workloads, application, and database seamlessly and without disruption.

A brief overview of major serverless market players — AWS Lambda, Google Functions, Azure Functions

Let’s take a look at what the big three cloud vendors have to offer in terms of FaaS.

AWS Lambda

AWS Lambda is rapidly becoming a shell scripting language for the entirety of AWS infrastructure. By using Lambda you can create unlimited scenarios in response to various types of events that can happen anywhere within your AWS infrastructure or be triggered from the outside. When an event occurs, it invokes a Lambda function, which can invoke another function in turn, allowing for really complex workflows.

Lambda supports functions in Node.JS, Java, Python, Go and C#. As these languages can easily embed code in other languages, you can use wrappers to work with Haskell, Lisp or compile legacy C++ to run on Lambda.

Lambda provides a clean web interface, where you can configure any pipelines. Where previously you should have written configurations in text files, you can now click several web forms to leverage all the power of the Amazon cloud with a few lines of code. However, testing new functions can be somewhat cumbersome, as you have to configure the API gateway and open specific firewall ports to see how your functions work.

You can build Lambda workflows from the source of events to the destination and configure any response scenarios.

Lambda is very user-friendly, as it provides ample explanations and warnings on the underwater reefs of its functions. For example, if a function you create requires working with external libraries, you will receive a warning in your browser. Previously, you were expected to know this yourself or had to discover this dependency after googling for the meaning of the error message you receive. Now, you are forewarned, which saves tons of time and effort.

Lambda is not the only serverless offering from AWS, as many other products relieve you from server management. For example, Elastic Beanstalk enables you to upload the code, takes it to web servers, and handles the load balancing and scaling automatically. Yet another useful feature is AWS Step Functions, which allows to glue stateless Lambda with stateful events. This is crucial for any complex business logic, like when you need a client to complete a flowchart or a checklist. With Lambda, you would have to reload the client’s info from the database every time they reload a page. With Step Functions, you only need to do it once.

Google Cloud Functions

Google has been providing “serverless” capabilities long before FaaS became a thing. With the release of Google App Engine in 2008, Google enabled developers to concentrate on writing code instead of configuring and managing the environments to run it. With Google Cloud Pub/Sub you don’t need to handle the message queuing, only to write the code for the event producer and the consumer. Google Firebase is a database with superpowers, which allows you to mix the database layer with JavaScript functionality while delivering the data to your clients. Finally, Google Cloud Functions provides event-driven computing, which blends various GCP products into a powerful and flexible mix.

Firebase takes the idea of serverless to the extreme, handling all server-side business logic, including data storage and authentication. You can really run an app with a bit of client-side HTML/CSS, and Firebase. Firebase code is written in JS, so it will run locally on Node.JS. You can handle any business logic this way because there are multiple Node libraries for doing exactly this. In addition, you will enjoy the benefits of working with isometric code, running the same for the client, the server — and now the database. Your client apps are just other Firebase nodes, so you can write the information to Firebase once, and it will replicate the relevant data (and only the relevant one) to wherever it needs to be.

Google Cloud Functions allows embedding custom Node.JS code throughout the whole GCP ecosystem. However, while GCP at large works with Go, Python, PHP, Java and C#, Cloud Functions currently support only Node.js and pure JS. Support for other languages is announced but not implemented yet. However, Google Cloud Functions has to work through the REST API to even interact with Google Docs. Additionally, your code has to be stateless and every request can run for a limited time only.

Microsoft Azure Functions

Azure Functions is Microsoft’s answer to FaaS offerings from AWS and GCP. One of its biggest applications is working with Office products, which are slowly but steadily moving from desktop apps to the cloud. This way, HTML and web interfaces are not the only way to the Azure cloud — much can be achieved using Excel spreadsheets and Word documents.

Azure Logic Apps provides you with an ability to create workflows using built-in connectors for Azure and third-party apps. Instead of worrying about the semantics and syntax of the code, you fill out the forms that enable you to link stateful code with stateless functions.

Logic Apps supports the same push and pull methods to exchange data between Salesforce, Office 365, Twitter, and other tools. This way your enterprise IT teams can use Azure Logic Apps to build consistent workflows the way they used Powershell scripts.

Another great addition to this roster is Durable Functions, which allows creating and managing stateful functions, greatly enhancing the range of capabilities for building your event pipelines and workflows in the Azure cloud.

Another great feature from Azure is CosmosDB, a SQL/NoSQL database. Azure has duplicated Cassandra and MongoDB APIs, so you can easily push and pull data to and from your various databases. Cosmos DB works as a central nexus and continuously builds indexes to keep things running smoothly. Should you need to write pure SQL — you can do that too. This way you can consolidate your existing database ecosystem and keep it open to implementing new approaches in the future.

Comparison: advantages and disadvantages of serverless PaaS from the big three cloud service providers

While each of the big three FaaS offerings has a different set of features, they all have a set of characteristics that can be easily compared. These include pricing per invocation, programming languages supported, trigger types, concurrency and execution time length, etc. The table below showcases these parameters.

Regarding trigger types, Lambda and Azure work via APIs. With Lambda, you can use API Gateway, dynamic triggering from DynamoDB or files-based triggering from Amazon S3. For Azure Functions, you have web API triggering, scheduled invocations and event-based triggers via Azure Event Hub or Azure Storage. For Google Cloud Functions, you have a wide range of trigger types, described in their documentation. The key benefit here is that you can integrate your FaaS with any Google Cloud service, and use Cloud Pub/Sub or API callbacks, for instance.

Concerns about using FaaS in real life

While this all looks fine and dandy, the real question is whether it actually works this way in real life. Regarding this question, the answer is… not so much.

AWS Lambda runs best, being the oldest, most popular, and polished of them all. When you use Lambda for any of the scenarios it supports, it runs reliably. Building complex scenarios might require additional configuration, though (like adding some extra connectors when operating a less popular database used in your product, for example).

Google Functions present yet another level of challenges, due to the limited application scenarios. Besides, at times they experience deployment and scaling issues, which are quite hard to debug and resolve.

As for Azure, you might find it difficult to believe, but it is Microsoft at its best. Sometimes they just freeze, not to mention having the lowest number of runtimes of the three. Perhaps it was caused by project specifics yet from our experience AWS FaaS felt a bit raw.

Conclusions: Which cloud platform Works Best for Serverless Architecture?

As you can see, all of the three leading cloud providers offer mature and robust serverless computing features. They slightly differ in various aspects but their core benefit remains the same: they enable developers to build various CI/CD pipelines and leverage all the power of the respective cloud platforms from a convenient FaaS dashboard, without having to mess with provisioning and configuration of various IaaS and PaaS modules.

So, which one to choose? The point being, while you can configure Lambda to invoke Azure services or upload files from GCP storage, it is best to go with the FaaS offering from the cloud vendor you use. You will have to rebuild everything from scratch, should you ever decide to switch to another provider, yes. However, while you are with AWS, Lambda will provide the widest range of possibilities. The same goes for Azure and Google Cloud tools.

We hope this article was informative and useful and helped you to gain a better understanding of the similarities and differences between the serverless computing offerings of Azure, AWS and Google Cloud. Should you have any additional questions or inquiries, please feel free to contact us, we would be more than happy to provide assistance!

Share on:

Don’t miss updates from us!
Subscribe to our monthly newsletter!