Stop me if you’ve heard this one: A lawyer, a plumber, and an Azure Function walk into an espresso bar. The lawyer immediately announces, “I make $400 an hour. The lattes are on me!” Not to be outdone, the plumber shouts, “I make $125 just for showing up and then charge $300 per hour. The pastries are on me!”

After an awkward silence, both the plumber and the lawyer glance at the function, who blusters, “What are you looking at me for? I’m a serverless function. I earn only pennies an hour!” Adding, “And you know me; I’m a lightweight. I’ll just have a single shot of espresso and go home.”

True story.

Well, okay, I may have added a few details for dramatic effect. But the most important part I didn’t make up is the fact that well-written Azure Functions — when deployed in a serverless architecture — cost very little per runtime hour, do one thing very well, and then bow out.

The key phrase here is “serverless architecture.” Just because somebody codes and deploys an Azure Function does not immediately confer serverless status on that code. Microsoft offers several ways to host Azure Functions, and, by my accounting, only two of those offerings are fully “serverless.” 

Serverless hosting, regardless of the cloud provider, is generally accepted to have three distinguishing features:

1. The cloud provider manages the server(s) that run the code.
2. Server resources behind the code can scale up and down dynamically.
3. The cloud customer pays only for the server resources consumed when the code is running.

Azure’s Consumption hosting plan and Premium hosting plan for functions meet this definition, and Microsoft describes these as “Functions as a Service.”

The other hosting plans for Azure Functions, which involve various configurations of the Azure App Service, as well as Kubernetes and Arc, certainly qualify as cloud architectures, but just not fully serverless architectures. Those hosting choices could best be described as server-some. Imagine the various hosting options on a continuum based on the industry standard “something-as-a-service” categories:

All of the server-some hosting options fall somewhere on the continuum between Infrastructure as a Service (IaaS) and the outer fringes of Platform as a Service (PaaS), just slightly outside of Functions as a Service (FaaS). These options free the developer of many aspects of infrastructure management, but none quite as fully as a true serverless offering.

Affixing labels within this fluid continuum is a lot like defining coffee drinks (The simile was intentional; the pun was serendipity). Is a shot of espresso with a half-inch of foamy milk a “latte with extra foam” or a “wet cappuccino?” Is a chai tea latte with two shots of espresso a tea drink or a coffee drink? And what about a “single, tall, decaf, non-fat, sugar-free mochaccino” — isn’t that just brown water? Maybe that one doesn’t even find its way into the coffee continuum.

I fear I may be treading on sacred grounds here, so let’s get back to the business of functions and their hosting architectures. 

All of this is not just an exercise in arguing semantics; there is actually a clear benefit to categorizing or labeling architectures involving Azure Functions. Given clear boundaries, a team can ensure everyone is starting with the same set of premises in order to drive to an optimal design or hosting decision. 

(Can you imagine deciding on a coffee drink without a shared understanding of the custom labels, aka, a menu? Try ordering a venti brewed coffee anywhere but a Starbucks, and you’ll see what I mean.)

That said, it’s easy to become overwhelmed. All of the cloud providers – but Microsoft, in particular – try to offer everything to everyone, all the time. While choice is nice, it can make for a confounding matrix of pros-and-cons.

Fortunately, in the case of how, when and why to use Azure Functions – and whether to deploy them in a serverless environment – many of the design decisions boil down to resource management (By the way, you should never let coffee water boil; it bruises the beans). This focus on resource management is readily apparent once you ask the right questions and draw your own custom sub-definitions and labels within the broader categories of IaaS, PaaS, and FaaS.

You should ask yourself questions like:

1. Do you have more IT admin folks than developers, or vice-versa? 
2. Do you have more time than money? 
3. Do you have the luxury of coding from scratch? 
4. Are you trying to drag a monolithic application, kicking and bucking, into the cloud? 
5. Are the functions you envision for your solution lightweight and single-responsibility bits of code that run quickly, or are they a bit meatier, and trend toward consistently or constantly running applications?

Armed with the answers to these questions, your label gun, a whiteboard – and access to the hot drinks of your choice – you and your team can enjoy more fruitful design discussions around serverless and server-some choices (Did you know that coffee is a fruit?). As a bonus to this approach, you can refer back to your team-defined framework of labels when the inevitable course corrections are required.

To learn more about serverless concepts, in general, and serverless in Azure, specifically, consider checking out the following ACG courses:

• Intro to Serverless on Azure
• Changing Architectures from Containers to Serverless
• AZ-305: Designing Microsoft Azure Infrastructure Solutions

To learn more about coffee and opinions about coffee . . . well . . . I’m not dipping my finger in that hot cup-o-joe! Pick your favorite search engine and go for it.