Microsoft has provided an Azure Functions extension for Dapr - Distributed Application Runtime - but currently it cannot be used with the hosted Azure Functions cloud service.
The company’s habit of slapping the Azure brand on everything is perhaps part of the confusion here. Casual observers may have thought that Azure Functions is a serverless platform running on Azure, a competitor to AWS Lambda, but that is not the whole story.
The scaling controller adds and removes compute capacity for the functions according to demand. You can indeed use Azure Functions as a Lambda-like hosted service, but there are other supported ways of deploying the runtime, including on Azure App Service, Kubernetes, or Azure IoT Edge.
In the Kubernetes case, the role of the scale controller is performed by KEDA (Kubernetes Event-driven Autoscaling), a CNCF project supported by Microsoft, Red Hat and others.
The Dapr runtime supports services on a variety of platforms including Azure Functions, but the new extension makes that particular link smoother and easier to use
It is this Kubernetes case that Microsoft has in mind for the new Dapr integration, explained here by Principal Program Managers Jeff Hollan and Mark Fussell. Dapr was introduced in October 2019, and before you get too excited, note that the project page on GitHub stated that “Dapr is currently under community development in alpha phase. Dapr is not recommended for production workloads until the 1.0 stable release,” though this limitation is not mentioned in Hollan and Fussell’s post.
Dapr runs natively on Kubernetes (as one deployment option) and is useful for things like state management and reliable messaging.
“Dapr brings a bunch of capabilities that Azure Functions out of the box doesn’t provide,” Hollan told The Register. “We saw there was growing interest in running Functions in environments like Kubernetes and cloud native applications, and we want to make it easier to use Dapr. This extension takes the 10-15 lines of code you would have to learn and write before, and makes it a single line of code where you just say, 'use Dapr'.
“Dapr is optimized for Kubenetes workloads, so for the time being the extension is only working in those environments where Dapr runs alongside it today, on Kubenetes or IoT devices. That said, we’re interested in hearing from the community. If they want to start using these Dapr capabilities in the fully managed Azure Functions service, we’re happy to solve those problems.”
Since Azure also has a Kubernetes service (AKS), you could then use Azure Functions hosted on AKS rather then the managed service. Would that ever make sense?
“I talk about the spectrum between productivity and control,” said Hollan. “For the majority of people, try running in the managed service. That said, there are times when devs do need more control, such as they are going multi-cloud, it has to run on Amazon, Google, Azure or on-premises. Then Kubernetes is a great solution. Drop in Dapr and KEDA and it will make it even better.”
Some enterprises, said Hollan, have simply standardised on Kubernetes. “They have done a bunch of work to make it so that Kubernetes is used everywhere, it’s got all the policies and compliance.”
In this case, running Azure Functions on Kubernetes rather than using the managed servicer makes sense, whether on AKS or elsewhere.
Dapr is winning interest because the building blocks meet common requirements for developers deploying to Kubernetes, such as stateful services, and is easy to manage, claimed Hollan. “We are seeing a lot of uptick. We are working with a handful of customers outside the Microsoft community who are getting prepared to go to production. It will help us validate to 1.0,” he said.
For many people the serverless concept is all but defined by AWS Lambda, which was first to market. Can Azure or Google Cloud Platform catch up? Hollan said that Azure Functions has some unique features, like Durable Functions which let you run stateful functions on the runtime. The key differentiator though is open source – Azure Functions is on GitHub.
“We don’t want people to fear vendor lock-in, which is a curse word in the serverless community. We give you the tools to run it wherever you want,” he told us.®