Serverless in the cloud: AWS vs. Google Cloud vs. Microsoft Azure

With AWS Lambda, Google Cloud Functions, and Microsoft Azure Functions, a little bit of business logic can go a very long way

Serverless in the cloud: AWS vs. Google Cloud vs. Microsoft Azure

If you’ve ever been woken up at 3 a.m. because a server went haywire, you’ll understand the appeal of a buzzword like “serverless.” The machines can take hours, days, or sometimes even weeks to configure and then they need to be updated constantly to fix bugs and security holes. These updates usually bring hassles of their own because the new updates cause incompatibilities forcing other updates or so it seems ad infinitum.

The endless chain of headaches from running a server is one of the reasons that major cloud companies have embraced the “serverless” architecture. They know that the boss has heard the excuses—the server this, the server that—for far too long. If we could only get rid of those servers, the boss must think.

It’s a wonderful sales term with the only problem being it’s not strictly true. These apps are serverless in the same way that restaurants are kitchenless. If what you want is on the menu and you like how the cook prepares it, sitting down in a restaurant is great. But if you want a different dish, if you want different spices, well, you better get your own kitchen.

Amazon, Google, and Microsoft are three of the bigger companies that are battling to host applications of the future, ones that they hope will be written to their serverless API and managed through their automation layer. If the platforms do what you want—and the new models are pretty general—they can be the simplest and fastest way to create your own multibillion dollar unicorn web app. You write only the crucial bits of logic and the platform handles all of the details.

Serverless functions are becoming the glue or scripting language that links together all of the cloud features. The mapping or AI tools that were once fairly independent are now linked through the event-driven serverless functions. Now more of your work can be solved by requests that ripple and bounce through the various corners of each cloud, triggering and being triggered by a flow of events. If you want to explore machine learning and use it to analyze your data, one of the fastest ways to do it is to create a serverless app and start sending events to the machine learning corner of the cloud.


The implicit promise is that slicing everything thinner makes it easier to share resources in the cloud. In the past, everybody would be frantically creating new instances with, say, Ubuntu Server running in its own virtual machine. Everyone used the same OS and it was duplicated a zillion times on the same real box that was pretending to be a dozen or more virtual Ubuntu boxes. Serverless operations avoid all of that duplication, making cloud computing dramatically cheaper, especially for jobs that run sporadically and never really jammed up the old box sitting in your air conditioned server room.

Of course all of this convenience does have a hidden cost. If you ever want to leave or move your code to another site, you’ll probably be stuck rewriting most of the stack. The APIs are different, and while there is some standardization around popular languages like JavaScript, they’re pretty close to proprietary. There is plenty of opportunity for lock-in.

To understand the appeal of serverless options, I spent some time building out a few functions and poking around the stacks. I didn’t write much code, but that was the point. I spent more time clicking on buttons and typing into web forms to configure everything. Do you remember when we configured everything with XML and then JSON? Now we fill out a web form and the cloud does it for us. You still have to think like a programmer, though, to understand what’s going on behind the scenes and beyond your control.

AWS Lambda

AWS Lambda is growing into the shell script layer for Amazon’s entire cloud. It’s a basic system that lets you embed functions that respond to events that might be generated by almost any part of the vast Amazon cloud infrastructure. If a new file is uploaded to S3, you could have it trigger a function that does something interesting with it. If some video is being transcoded by the Amazon Elastic Transcoder, you could have a Lambda function waiting to be triggered when it finishes. These functions, in turn, can trigger other Lambda operations or maybe just send someone an update.

You can write Lambda functions in JavaScript (Node.js), Python, Java, C#, and Go. Given that these languages can embed many other languages, it’s quite possible to run other code like Haskell, Lisp, or even C++. (Check out this story on compiling legacy C++ to a library to use with AWS Lambda.)

Writing Lambda functions often feels much more complex than you expect because Amazon offers so many options for configuration and optimization. While it’s technically true that you can write just a few lines of code and accomplish great things, I felt like I then had to allocate more time to configuring how the code runs. Much of this is accomplished by filling out forms in the browser instead of typing into text files. At times it feels like we’ve just traded a text editor for a browser form, but that’s the price of retaining all of the flexibility that Amazon extends to the Lambda user.

Some of the additional steps are due to Amazon exposing more options to the user and expecting more of the first-time function writer. Once I was done writing a function at Google or Microsoft, I could point my browser to the right URL and test it immediately. Amazon had me clicking to configure the API gateway and open up the right hole in the firewall.

aws lambda configuration IDG

AWS Lambda’s configuration page lets you click on the source of the events that trigger a function and the destination for more events.

In the end, all of this clicking adds a layer of handholding that makes the job just a bit easier than starting with a text file. When I was creating one function, the browser had a warning, “This function contains external libraries.” Back in the days of pure Node, that was something that I would just be expected to know, or I would learn it by Googling the error message while crossing my fingers and hoping that the answer was out there. Now the cloud is rushing in to help.

Amazon has a number of other options that are just about as “serverless” as AWS Lambda, if serverless means relieving you of server management chores. It has elastic tools like Amazon EC2 Auto Scaling and AWS Fargate that spin up and shut down servers, and AWS Elastic Beanstalk, which takes your uploaded code, deploys it to web servers, and handles the load balancing and scaling. Of course, with many of these automation tools, you’re still responsible for creating the server image.

One of the more useful offerings is AWS Step Functions, a sort of code-less flowcharting tool for creating state machines to model what software architects call workflow. Part of the issue is that all of the serverless functions are meant to be entirely free of state, something that works when you’re enforcing pretty basic business logic but that can be a bit of a nightmare when you’re walking some client through a checklist or a flowchart. You’re constantly going out to the database to reload the information about the client. Step Functions glue together Lambda functions with state.

Google Cloud Functions and Firebase

If getting rid of the hassle of configuring servers is your goal, Google Cloud has a number of services that offer various amounts of freedom from things like needing a root password or even using a command line at all.

Starting with the Google App Engine in 2008, Google has been slowly adding different “serverless” options with various combinations of messaging and data transparency. One called Google Cloud Pub/Sub hides the messaging queue from you so all you need to do is write the code for the data producer and consumer. Google Cloud Functions offers event-driven computation for many of the major products including some of the marquee tools and APIs. And then there’s Google Firebase, a database on steroids that lets you mix JavaScript code into a data storage layer that delivers the data to your client.

Of these, Firebase is the most intriguing to me. Some suggest that databases were the original serverless app, abstracting away the data structures and disk storage chores to deliver all of the information through a TCP/IP port. Firebase takes this abstraction to the extreme by also adding JavaScript code and messaging to do almost everything you might want to do with the server-side infrastructure including authentication. Technically it’s just a database but it’s one that can handle much of the business logic and messaging for your stack. You really can get away with a bit of client HTML, CSS, JavaScript, and Firebase.

You might be tempted to call Firebase’s JavaScript layers “stored procedures,” just like Oracle did, but that would be missing the bigger picture. The Firebase code is written in JavaScript so it will run in a local version of Node.js. You can embed much of the business logic in this layer because the world of Node is already filled with libraries for handling this workflow. Plus you’ll be enjoying the pleasures of isomorphic code that runs on the client, the server, and now the database.

The part that caught my eye was the synchronization layer built into Firebase. It will synchronize copies of objects from the database throughout the network. The trick is that you can set up your client app as just another database node that subscribes to all of the changes for the relevant data (and only the relevant data). If the data changes in one place, it changes everywhere. You can avoid all of the hassles of messaging and concentrate on just writing the information to Firebase because Firebase will replicate it where it needs to be.

google firebase error console IDG

Google Firebase provides an error console that shows a timeline for good and bad events as they’ve unfolded.

1 2 Page 1
Page 1 of 2