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.
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.
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.
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 and that spin up and shut down servers, and , 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 , 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.
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 Cloud Functions does not reach as deeply into the Google Cloud as AWS Lambda reaches into AWS, at least at this point. When I poked around looking at building a function to interact with Google Docs, I found that I would probably have to use the REST API and write the code in something called Apps Script. In other words, the Google Docs world has its own REST API that was serverless long before the buzzword was coined.
It’s worth noting that Google App Engine keeps going strong. In the beginning, it just offered to spin up Python applications to meet the demand of anyone coming to the website, but has been extended over the years to handle many different language runtimes. Once you bundle your code into an executable, the App Engine handles the process of starting up enough nodes to handle your traffic, scaling up or down as your users send in requests.
There continue to be a few hurdles to keep in mind. As with Cloud Functions, your code must be written in a relatively stateless way, and it must finish each request in a limited amount of time. But App Engine doesn’t toss away all the scaffolding or forget everything between requests. App Engine was a big part of the serverless revolution and it remains the most accessible to those who keep one foot back in the old school method of building their own stack in Python, PHP, Java, C#, or Go.
Microsoft Azure Functions
Microsoft, of course, is working just as hard as the others to make sure that people can do all of these clever serverless things with the Azure cloud too. The company has created its own basic functions for juggling events—the —and built some sophisticated tools that are even more accessible to semi-programmers.
The biggest advantage Microsoft may have may be its collection of Office applications, the former desktop executables that are slowly but surely migrating into the cloud. Indeed one Microsoft ahead of Amazon, in part by lumping some of its Office revenue into the ephemeral rubric of “cloud.”
One of the best examples from the Azure Functions documentation shows how a cloud function can be triggered when someone saves a spreadsheet to OneDrive. Suddenly the little elves in the cloud come alive and do things to the spreadsheet. This is bound to be a godsend to IT shops supporting teams that love their Excel spreadsheets (or other Office docs). They can write Azure Functions to do practically anything. We often think that HTML and the web are the only interface to the cloud but there’s no reason why it can’t be through documents formats like Microsoft Word or Excel.