Azure Functions wants to make it easy for developers to get started with serverless

Microsoft is now opening themselves to people who weren’t traditionally application developers with Azure Functions

Welcome to “Serverless Superheroes”!
In this space, we chat with the toolmakers, innovators, and developers who are navigating the brave new world of “serverless” cloud applications.

In this edition, we caught up with Chris Anderson, a senior software engineer at Microsoft and program/product manager for Azure Functions. The following interview has been edited and condensed for clarity.

Forrest Brazeal: Chris, how did you find yourself building serverless products? I’m guessing that wasn’t part of your original job description at Microsoft …

Chris Anderson: My passion has always been NodeJS, so a few years ago I typed “NodeJS” into Microsoft’s internal job site and out came the Azure Mobile Services team (since renamed the Mobile Apps team). I joined that team, and kind of just got assigned a random technology to keep track of customer issues.

The technology was called WebJobs, and we weren’t looking to invest heavily in it. We were doing event based programming for .NET console applications so you could do things that look very close to what “serverless” is today. For example, you could run a C# method every single time a new message queued or a new blob showed up in storage.

So, being a NodeJS fan, eventually I talked to the engineer who was in charge at the time and said, “Hey, we should try to get NodeJS working on WebJobs.” We just kind of hacked it together over a couple weeks in the summer. And then we had a thing that was worse than WebJobs. [Laughs] It was harder to use, harder to figure how to scale, but the advantage was I could now write JavaScript.

So we went through a couple more iterations on the thing, got a couple more people in the company excited at what we were doing, and we came to the conclusion that we needed to run it as a service. And then funnily enough, we discovered there’s already a growing market for “functions as a service”, and so we managed to pretty quickly get a team together to build WebJobs for multiple languages as a service, which then became Azure Functions.

So we didn’t start trying to do the serverless thing. We kind of backed into it from “Hey, wouldn’t this be a cool idea?” and then we worked backwards through all the experiences and it just so happened that we ended up with something that looked very “serverless”.

Have you found that the journey of your users has been similar — people using WebJobs that are evolving with you — or are more people just showing up to Azure now saying, “Got serverless?”

We’ve made it a pretty explicit goal that we weren’t trying to convert WebJobs users into Functions users. We did try to make it easy if they did want to move. But WebJobs have advantages over serverless in the same way that containers have advantages over serverless, and vice-versa. You have different aspects of control versus freedoms. We wanted you to be able to still do both. What we found interesting was we had users coming from all different directions.

We had PowerShell support on day one. It was really interesting that we had PowerShell users, not traditional developers, coming out and building web applications powered by PowerShell scripts, and the ability to write a PowerShell web service was a unique proposition.

Microsoft’s existing customer base are oftentimes just building services to extend our vast amount of SaaS offerings — Office, Sharepoint, Dynamics — and a lot of those folks are integration people who spend a lot more time with PowerShell scripting and operations at work than typical application development.

And it was really cool to see that functions as a service makes it so easy for them build a reliable scalable service. We’re now opening ourselves up to having people who weren’t traditionally application developers building applications without needing to go through extra hoops.

So even though you’re a NodeJS guy, you wouldn’t say serverless is just for developers?

Sometimes internally at Microsoft we refer to “cliffs”, knowledge barriers between roles that block people from expanding their comfort zone. If my main job is to be an integration specialist, I’m gonna spend more of my time trying to learn about the different services and how they fit together than I am gonna be learning about how to go write a simple application. But with functions it’s so easy to get started — that cliff is so small — that we are able to enable a lot of people.

So what type of problems do you see Azure Functions enabling people to solve that were harder for them to solve before?

We started Azure Functions thinking that most people were gonna be using it for, like, queue processing. That’s what WebJobs was really great for, background processing. But none of us thought when we added HTTP support initially that anyone would build full web applications with it. We were like, “Okay, this will be used to kick off an intermediate job.”

I recently sat down to write a serverless application for MS Build. It’s really rare when you build products that you get to sit down and just use them deeply, but I got to spend two weeks just using every single feature we have. And I’ve never missed having a regular web application server. It’s amazing to me that such a simple idea really does extend so far.

Is there anything in the serverless programming model that lends itself to a particular type of application, such as IoT?

IoT applications lend themselves to RPC-style architectures, and it’s really pretty simple to have functions act as your “C” at the end of the “RP”. So I think that is why they’ve gone together so well. Previously you had to stand up an application server and then have that “thing” go through there and get called by various IoT applications, and vice-versa.

You know, IoT is still kind of nascent. It’s not a young industry, but there still aren’t a whole lot of well-worn patterns. And I think that serverless came about at the right time for IoT. We’ve seen so many large-scale IoT applications able to just take off and run as soon as they realized they could use functions to handle billions and billions of executions a day without having to think about it.

Depending on your workload, you can save money and it might make sense for you to run a dedicated instance, but it’s way faster to start with functions and then find some way of running your own specialized service after you’ve shipped your product.

I think that there’s a lot of synergy with functions as a service and streaming-based applications, and IoT is inherently a streaming-based operation for a lot of different scenarios.

Yeah, there’s the occasional one-off alert that comes from devices, but a lot of the times it’s streaming data that needs to transform some archaic binary format to some kind of JSON format that your other streaming analytic services can understand. That kind of use case is just a natural fit for something simple and scalable rather than something complex and stateful.

One of the awesome things about IoT is there’s oftentimes a lot of state involved in managing the stream itself. Looking at all the different streaming services, they almost all have client-side cursors of some kind when you’re using them in a server-based fashion. But all the serverless services have managed to abstract away storing the state of the stream, and so this helps make something which previously has been a stateful operation stateless.

Serverless scale sounds great, but it can be tricky, especially if you launch large numbers of stateless functions against a traditional database that relies on stateful behaviors like connection pooling. How are you tackling this problem at Azure?

You could say one “sin” of serverless is that when we killed your servers, we also got rid of all of your frameworks that you previously built things with on servers.And those frameworks used to do a lot of that connection pooling and resource management for you.

But when you went to a service model and serverless, we didn’t give you rich frameworks to fill in all those same gaps. And so while you still had the underlying frameworks of the actual platforms like Node and .NET themselves, you had to understand a lot more than you previously did.

So what we have tried to do at Azure is just document things. We have a big section in the Azure Functions docs about connection pooling, helping you understand that we’re not creating a new environment for you for every single execution because that’s a giant waste of electricity.

Azure Functions aren’t purely stateless, because you can have some lingering state between executions, and so you still need to write your application in a way that doesn’t affect the environment. You want to make sure that you don’t leave things lingering around and you want to be responsible with the amount of resources you’re consuming.

We now actually have little sensors in the environment that detect when you’re getting close to the edge of your resources and start firing alerts off — that way you know that if your code starts to behave in weird ways it was probably because of, say, a leaky function.

Out of curiosity, what is Azure Functions doing to mitigate the cold start problem?

Mostly we just try to never actually be cold. We try to keep something like a generic warm worker laying around, so we can toss your code into the Node process that is already running. Then we just need the amount of time that it takes to load your code from storage and have it parsed.

So there’s still advantages to writing small amounts of code, as it reduces the amount of time to parse, but yeah — the solution in our minds is to just never be cold.

With that said, what in your mind really makes Microsoft stand out in the serverless space relative to competitors?

Well, Azure Functions has various differentiating features, and we’ve got blog posts to talk about them. What I’d say that I’m really proud of at Microsoft, which I can’t necessarily fault other people for not having, is that because we have this legacy of building developer tools with Visual Studio and VS Code, we always put developer experience first. We’re not willing to ship something from my team unless it’s friendly for developers to use.

We were one of the first serverless services that supported local development, and I think (though I’m not sure) we still might be the only service that has local development with real events. That’s because we really want to make it easy to get started and test things quickly. You don’t even need an Azure account to start using functions with the local emulator. I’m really proud that we took that approach.

Chris, any amazing serverless stories from customers that are keeping you excited about this technology?

All the stories are interesting individually, but I think they all boil down to this common theme: “We thought this project was going to take a long time, but with serverless we got it done in a week.” That makes me so happy because it gets to my ethos as a hacker who likes to ship quickly.

I really do think that what we’ll see in the next year is a holistic realization that serverless managed services, beyond just functions as a service, are absolutely killing it. In terms of productivity, serverless blows everything else out of the water.

Now, granted, deploying a serverless app is still a bit too “ops-y”. (Is that a word?) As a developer, you can deploy a POC in a week, then spend a month trying to automate and configure everything in YAML — and we’re so far on the edge of productivity that we live and die by how fast people can build. So as a person who builds these products, I’m focused on streamlining users’ workflows in any way I can.

Forrest Brazeal is a cloud architect and serverless community advocate at Trek10. He writes the Serverless Superheroes series and draws the ‘FaaS and Furious’ cartoon series at A Cloud Guru. If you have a serverless story to tell, please don’t hesitate to let him know.