Thoughts on the new Serverless.
Going serverless with function apps has been quite enticing for some time. Not having to pay for 24/7 infrastructure, but getting complete auto-scaling is a game changer. But it’s never felt like serverless functions could replace your stack. Is it good for a simple Slack app? Sure. But not a complex backend. Until now.
Azure’s Durable Functions extend their already established Functions as a Service (FaaS) platform. Finally, serverless functions have state. You define workflows in code, all while enjoying the many benefits of serverless.
In many ways, Durable Functions feel like the way serverless functions were meant to be. And Azure is the only cloud provider currently offering such a tooling. Durable functions let you chain functions together. You can even run them in parallel, and easily track workflow progress. There are robust error handling and retry mechanisms that you get right out of the box.
After building a handful of proof of concepts, I was sold. It was time to refactor some production applications, as well as start a couple from scratch. Here’s what I’ve found so far.
More Coding, Less Plumbing
I’ve worked on a lot of larger scale Node.js applications with varying use cases. But it seems that no matter what, there is some sort of queue processing needed, and that’s where I spend most of my time.
Sure, there are great frameworks out there like Kue and Bull that do a lot of the heavy lifting for you. Look at those readme’s though. There is a lot of setup, and even more work to troubleshoot and maintain.
That’s Enough Plumbing for Me. (Damon Lam on Unsplash)
Durable Functions use a lot of the same mechanisms under the hood, but it’s all handled for you. This is a bit scary at first. Especially coming from a world where queue management was the source of most of my problems. But Azure has a much better solution, without the need to babysit every last transaction.
This has significantly increased output. I recreated functionality in hours what had taken days to do myself. Recurring tasks, automatic retry policies, and scheduled jobs just work. And if you have to troubleshoot, everything is queryable in Table Storage. No more need to parse through Redis keys. I can focus on business logic, instead of worrying about scheduled jobs.
Super Easy Hosting
Hosting is, of course, a breeze for large scale enterprise apps. But I don’t see myself using traditional hosting for my personal projects anymore. No longer do I have to struggle through the potato CPU and 128 bytes of RAM that the free hosting tiers provide. Or monthly fees to keep up a demo application.
Heck, if you need something up quickly, you don’t even need a GitHub repository or an IDE. I’ve already used the online code editor in Azure to host a couple demo functions for testing purposes. I now have my own servers I can host anything, at any time. And I don’t have to pay a dime.
Still on the Cutting Edge
While developing Durable Functions has been a good experience, there are issues. Everything is still pretty new and there is a lot of active development going on.
Tooling Issues
I’ve spent most of my time developing Durable Functions on a Mac. Don’t get me wrong, as a .NET developer for years, it’s a treat to be able to build .NET apps anywhere. But some things just don’t work right.
Azurite, a local Azure Storage simulator for Mac/Linux, straight up doesn’t work. Theres a different simulator for Windows that works great. But Azurite isn’t durable yet. This means I’m incurring (minimal) costs doing local development. I have to use Azure Storage.
The recommendation is to use the Functions extension for VS Code. But that is not quite durable either. It doesn’t setup projects the recommended ways. And it doesn’t seem to even know that Durable Functions are a thing yet. So I find myself creating functions from scratch rather than using the tool as intended.
Language Options
Durable Functions promise support for C#, JavaScript, F#, Java, and even more on the way. This is great news. It means that once you learn the Durable Functions patterns, you aren’t locked into a language choice.
Unfortunately, I’ve found that C# is the only valid option for right now. It is the only language that is “Generally available (GA) — Fully supported and approved for production use.” Azure Functions have more languages in GA. So it’s safe to say Durable Function support is coming.
Supported Languages for Azure Functions, But Not Durable (Source)
JavaScript is missing key implementations that make Durable Functions great. There is still a lot of stuff that doesn’t work. And the documentation is not even close to that of its C# counterpart. I found the development experience for JavaScript very frustrating. It was the opposite for C#.
I suspect Microsoft will address these issues whenever JavaScript becomes GA. Yet, it does seem C# will always be the preferred child.
“JavaScript support generally has dependencies on our .NET implementation.” -Chris Gillum, Principal Software Engineer on Durable Functions.
That’s not to say it won’t be usable, but something to keep in mind when making a language decision. Even in the JavaScript apps I’m refactoring using Durable Functions, C# is the language choice. JS just isn’t there yet.
Drastic Cost Decrease
The most obvious advantage of serverless in general is the cost savings. You only pay while the functions are being consumed. This is huge, especially if you aren’t Twitter and don’t have a ton of traffic at all hours of the day.
Durable Functions add a touch more cost, as they use Azure Storage a lot to keep everything, well, durable. Still, that cost is minimal. Much better than hosting your own Redis instance to mimic functionality.
I’m not sure how Azure is making money on these things. The average web app would never come close to having any significant cost. But I figure it’s a way for them to get developers to start using the platform. It’s awfully easy to start using something like CosmosDb with functions, and that is not cheap.
Give it a Try
All in all, the Durable Functions framework is an incredible tool. It has changed my mindset on how backend development can work. So give it a try! It’s free and easy to get going. You don’t even need an IDE, you can build out proof of concepts straight from the web portal.