{"id":267,"date":"2019-02-22T05:31:47","date_gmt":"2019-02-22T04:31:47","guid":{"rendered":"https:\/\/www.codemotion.com\/magazine\/azure-durable-functions-and-serverless-orchestration\/"},"modified":"2021-12-23T14:26:28","modified_gmt":"2021-12-23T13:26:28","slug":"azure-durable-functions-and-serverless-orchestration","status":"publish","type":"post","link":"https:\/\/www.codemotion.com\/magazine\/devops\/cloud\/azure-durable-functions-and-serverless-orchestration\/","title":{"rendered":"Azure Durable Functions and Serverless Orchestration"},"content":{"rendered":"

S<\/span>erverless computing is becoming extremely popular in the cloud world, with all the major players offering their own implementation of FaaS<\/strong> (Function as a Service<\/em>) solutions. This success should not be surprising since there are many advantages in taking the serverless approach for the design of a distributed application.<\/p>\n

First of all, a serverless cloud application does not require any management of the underlying infrastructure: there is no server to maintain, no operating system to update, etc. The cloud provider is responsible for the performance and the availability of the computing resources. Moreover, providers are also responsible for making the application scale correctly, relieving developers and operators from the responsibility of tuning and testing scaling policies. Last, but not least, serverless architectures may reduce the overall costs because the providers charge only for the time the functions run.
\n <\/p>\n

\"\"<\/a>
\n <\/p>\n

The development model usually associated with serverless computing is based on three main concepts: it forces an event-driven approach, requires functions to be short lived and requires functions to be purely stateless.<\/p>\n

The event-driven requirement is a direct consequence of the serverless approach. Functions are loosely coupled entities in our application that exchange asynchronous messages that describe a change in a state and react accordingly. They run only when they are triggered by specific events and they do not care about who generated the trigger.
\nThe requirements on the nature of the serverless functions are due to the provisioning models used by the cloud provider. Since function instances can be provisioned and de-provisioned at any time, on different servers, they must run for a short period of time and cannot carry any stored data with them.<\/p>\n

Implementing a fully serverless application can be quite challenging. First of all, as for any event driven approach, when components are highly decoupled the system become opaque and can exhibit an unpredictable behaviour. Moreover, stateless components do not fit every possible use case and relying on external storage may not be the best option in terms of both performance and costs.<\/p>\n

The most common usage of serverless functions is to implement some “glue” logic that interconnect several services in an efficient way. Managed services generate or consume events while serverless functions<\/a> implement the application business logic one piece at a time. However, while the initial development of an application like this can be fast and straightforward, debugging and implementing error handling can be quite difficult. Even simple back propagation of an error condition can be difficult: since functions are stateless, how can a function notify an error event to the previous function in a sequence?<\/p>\n

Talking about these limitations and the solutions offered by the Azure platform, Mikhail Shilkov<\/a>, Microsoft Azure MVP, gave an interesting talk at Codemotion Milan 2018<\/a>.
\nShilkov showed how Azure Durable Functions<\/strong> can be used to overcome the limitations of Azure Functions as described above. In particular, Durable Functions bring orchestration abstractions to Azure Functions, allowing the implementation of stateful functions.<\/p>\n

\n

Slides for my “Serverless Workflows with Durable Functions” @CodemotionIT<\/a> #Codemotion<\/a>https:\/\/t.co\/YFc0PAHTca<\/a><\/p>\n

\u2014 Mikhail Shilkov (@MikhailShilkov) November 29, 2018<\/a><\/p><\/blockquote>\n