Presentation: Stateful Programming Models in Serverless Functions
This presentation is now available to view on InfoQ.com
Watch videoWhat You’ll Learn
- Hear about how Azure does serverless, how they make the code durable.
- Learn what and what cannot be done with serverless.
Abstract
Most will agree that Serverless is the future of cloud computing. But when most people think of Serverless, they think of FaaS (Functions as a Service), and when they think of FaaS, they think of functions that are ephemeral, stateless, and short-lived. But does this always need to be the case? Is it possible write functions that are stateful and long-running on top of ephemeral, Serverless compute platforms?
In this session, we'll explore two stateful programming models: workflows and actors. We'll discuss how they can simplify development and how they enable stateful and long-running application patterns within ephemeral, Serverless compute environments. We'll also explain why we're making a bit bet on these programming models in the Azure Functions service.
What are you doing these days?
I work on the Azure Functions team within the Azure organization. We focus on building programing models that run on a serverless compute platform. My team in particular focuses on advanced programming models, Durable Functions being one of them. My team also owns some of the platform pieces of Azure Functions, such as the elastic compute backend that your code runs on - we automatically scale out and scale in for you.
When you talk about durable services, what does that mean?
The term durable typically means that you want to write some code and you want it to be resilient to failure. For example, if the VM crashes underneath you, you want to know that that code is going to come back up on some other VM and it's going to continue running where it left off. You're not going to lose any data or lose any progress. That's what we mean by durable. There's a lot more to it. We chose just to use the word durable as the main descriptor of what this is. But, I'm hoping within my talk to go into more details about what else that includes, such as long-running, and whatnot.
When you talk about durable, you don't mean persisting something off? You mean not losing what's in memory, if a function were to crash?
It's a mix of both in the sense that when you write a durable function, like a durable orchestration, you're writing just regular code. It's going to have some local variables. It's going to call some other functions. Behind the scenes, we do store some state persisted somewhere for you. Your code doesn't really have to know about that, but it is there. And then we have some techniques where if the process crashes or the VM crashes, we can actually restore your function, including the local variables, back to the last known good state.
Do you go into the details of the techniques that you use to maintain that running state?
Yeah, absolutely. One of them is going to be the pattern known as event sourcing, which I assume people will be familiar with. We use that pretty heavily to accomplish some of this.
What do you want someone to walk away from the talk with?
I want someone to walk away with a broader picture of what serverless and functions as a service can be. I think there are a lot of assumptions out there that, when we say serverless, when we say functions as a service, we're talking stateless and that everything is completely ephemeral. It puts it into a box a little bit. I want to expand people's ideas of what can be accomplished. For example, you can solve stateful problems on a serverless platform using functions. When I say functions I mean that generically regardless of what platform you're actually running on. But I want to expand people's concepts on what can be solved with serverless.
Similar Talks
Observability in the Development Process: Not Just for Ops Anymore
Cofounder @honeycombio