1.
Lalit Kale
Develop in Ludicrous mode with
Azure Functions

2.
About Me
• 15 years of Programming
• Use .NET to earn bread and butter
• Worked on very large scale systems in e-
Commerce , Banking and Insurance
• In spare time
• python, Go-Lang, OSS
• Loads of TED Talks

3.
Goal
• Serverless
• Azure Serverless Offerings
• Introduction to Azure Functions
• Build Microservice with Azure Functions
• Durable Functions
• Durable Functions Patterns

4.
Microservices – architectural approach
for cloud native apps
Monolithic
APP APP APP
Microservices
Large, all-inclusive app Small, independent services

5.
Independent modules Isolated points of failure
Autonomous scalability
Microservices
Tech flexibility
Faster value delivery

6.
Serverless – Great fit for Microservices
• Problems of traditional microservices
• Scaling of compute resources
• Operations dependency
• Pay per hosting nodes
• Services discovery and
• managing services integration
• Serverless solution
• Automatic scaling based on workload
• No infrastructure management
• Pay per execution (micro-billing)
• Event-Driven programming model
• (triggers + bindings), instant scale

7.
Event-driven/
instant scale
Micro-billingAbstraction
of servers
What is Serverless?
$

8.
What is Serverless?
clear separation between the code and its hosting environment

9.
Azure Serverless Offerings
</>

10.
Our Focus Today…
</>

11.
Introducing Azure Functions
Code EventsAzure
Functions

12.
Azure Functions Internals
Function Code Function Configuration
Language Runtime
WebJobs Core
Azure AppService

13.
Functions Secret Sauce…
• Triggers are ways to start executing Azure function code
• Bindings are declarative way of binding data to Azure function
• All triggers have input data
• Data coming from services become input values for function code
• To output data to another service use the return value of the
function.

14.
Functions Secret Sauce…
• Triggers
• Blob Storage
• Cosmos DB
• Event Hub
• HTTP
• Queues
• Service Bus
• Timer
• Webhook
• Bindings
• File
• Table
• Excel
• OneDrive
• Email
• Mobile app
• Notification
• More…

15.
Scaling happens at the Function App level
Usually, each Function App
represents a different
microservice
Each Function App would
be an API with grouped
endpoints
(one function per endpoint)
Flexibility choosing the
language for each
microservice – one per
Function App

16.
Hosting
options
Gain flexibility and develop your way

17.
Web application backends
Mobile application backends
IoT-connected backends
Real-time file processing
Real-time stream processing
Automation of scheduled tasks
Extending SaaS Applications
Conversational bot processing
Sample scenarios for Functions

18.
Demo
Azure Functions Hello World
- Portal Experience
- Visual Studio
- Azure Functions Core Tools

19.
Migrate from VMs → serverless
Thermostat intelligence
is a clear differentiator
Ready for sudden vertical growth
in the consumer market—charged
for usage as they scale
20K+ IoT devices simulated
Event driven architecture works well for
IoT
Customer Success Story
GLAS®Smart Thermostat by Johnson Controls

20.
Device to Cloud
Cloud to Device
IoT Hub for messaging
and managing devices
Event Hubs for routing
and throttling
Functions as
microservices
SignalR for device
messaging

21.
Demo
Building a Microservice with Azure Functions

22.
Stateless Microservices
What about Stateful Operations?

23.
Not everything fits on a few-seconds
execution

24.
Durable functions

25.
What is Durable Functions?
• Advanced feature for writing long-running orchestrations as a single
C# function. No JSON schemas. No designer.
• New orchestrator functions can synchronously or asynchronously call
other functions.
• Automatic checkpointing, enabling “long running” functions.
• Solves a variety of complex, transactional coding problems in
serverless apps.
• Built on the open source Durable Task Framework.

26.
Durable Functions Patterns

27.
Pattern #1: Function chaining - Today
Problems:
• No visualization to show relationship between functions and queues.
• Middle queues are an implementation detail – conceptual overhead.
• Error handling adds a lot more complexity.
F1 F2 F3 F4

28.
Pattern #1: Function chaining - Better
// calls functions in sequence
public static async Task<object> Run(DurableOrchestrationContext ctx)
{
try
{
var x = await ctx.CallFunctionAsync("F1");
var y = await ctx.CallFunctionAsync("F2", x);
var z = await ctx.CallFunctionAsync("F3", y);
return await ctx.CallFunctionAsync("F4", z);
}
catch (Exception)
{
// global error handling/compensation goes here
}
}

29.
Pattern #2: Fan-out/Fan-in - Today
Problems:
• Fanning-out is easy, but fanning-in is significantly more complicated
• Functions offers no help with this scenario today
• All the same problems of the previous pattern
F1
F2
F3

30.
Pattern #2: Fan-out/Fan-in - Easy
public static async Task Run(DurableOrchestrationContext ctx)
{
var parallelTasks = new List<Task<int>>();
// get a list of N work items to process in parallel
object[] workBatch = await ctx.CallFunctionAsync<object[]>("F1");
for (int i = 0; i < workBatch.Length; i++)
{
Task<int> task = ctx.CallFunctionAsync<int>("F2", workBatch[i]);
parallelTasks.Add(task);
}
await Task.WhenAll(parallelTasks);
// aggregate all N outputs and send result to F3
int sum = parallelTasks.Sum(t => t.Result);
await ctx.CallFunctionAsync("F3", sum);
}

31.
Pattern #3: HTTP Async Response
Problems:
• Execution state needs to be explicitly stored and managed.
• Execution state and trigger state must be kept in sync manually.
• Start and GetStatus is often boilerplate code that is not related to the business problem.
Start DoWork
GetStatus

32.
Pattern #3: HTTP Async Response – Built in!
> curl -X POST https://myfunc.azurewebsites.net/orchestrators/DoWork -H "Content-Length: 0" -i
HTTP/1.1 202 Accepted
Location: https://myfunc.azurewebsites.net/orchestrators/b79baf67f717453ca9e86c5da21e03ec
Server: Microsoft-IIS/8.0
> curl https://myfunc.azurewebsites.net/orchestrators/b79baf67f717453ca9e86c5da21e03ec -i
HTTP/1.1 202 Accepted
Content-Length: 173
Content-Type: application/json
Location: https://myfunc.azurewebsites.net/orchestrators/b79baf67f717453ca9e86c5da21e03ec
Server: Microsoft-IIS/8.0
{"runtimeStatus":"Running","createdTime":"2017-03-16T21:20:36Z","lastUpdatedTime":"2017-03-16T21:20:47Z"}
> curl https://myfunc.azurewebsites.net/orchestrators/b79baf67f717453ca9e86c5da21e03ec -i
HTTP/1.1 200 OK
Content-Length: 175
Content-Type: application/json
Server: Microsoft-IIS/8.0
{"runtimeStatus":"Completed","createdTime":"2017-03-16T21:20:36Z","lastUpdatedTime":"2017-03-16T21:20:57Z"}

33.
Pattern #4: Actors
Problems:
• Functions are stateless and short-lived.
• Read/write access to external state needs to be carefully synchronized.
• Functions do not support the singleton pattern today.

34.
Pattern #4: Actors (Eternal Orchestrations)
public static async Task Run(DurableOrchestrationContext ctx)
{
int counterState = ctx.GetInput<int>();
string operation = await ctx.WaitForExternalEvent<string>("operation");
if (operation == "incr")
{
counterState++;
}
else if (operation == "decr")
{
counterState--;
}
ctx.ContinueAsNew(counterState);
}

35.
Pattern #5: Human Interaction w/Timeout
RequestApproval
Escalate
ProcessApproval
Problems:
• Can’t easily coordinate a timeout with an approval request notification.
• Need a mechanism to reliably cancel either the approval handling or the
timeout depending on the outcome.

36.
Pattern #5: Human Interaction w/Timeout
public static async Task Run(DurableOrchestrationContext ctx)
{
await ctx.CallFunctionAsync<object[]>("RequestApproval");
using (var timeoutCts = new CancellationTokenSource())
{
DateTime dueTime = ctx.CurrentUtcDateTime.AddHours(72);
Task durableTimeout = ctx.CreateTimer(dueTime, 0, cts.Token);
Task<bool> approvalEvent = ctx.WaitForExternalEvent<bool>("ApprovalEvent");
if (approvalEvent == await Task.WhenAny(approvalEvent, durableTimeout))
{
timeoutCts.Cancel();
await ctx.CallFunctionAsync("HandleApproval", approvalEvent.Result);
}
else
{
await ctx.CallFunctionAsync("Escalate");
}
}
}

37.
Important Orchestrator Limitations
• Orchestrator code is replayed on every rehydration to restore all local
state (local variables, etc).
• Function calls are never replayed – the outputs are remembered.
• This requires the orchestrator code to be deterministic.
• Rule #1: Never write logic that depends on random numbers,
DateTime.Now, Guid.NewGuid(), etc.
• Rule #2: Never do I/O directly in the orchestrator function.
• Rule #3: Do not write infinite loops
• Rule #4: Use the built-in workarounds for rules #1, #2, and #3

38.
Takeaways
• Serverless – Glue of Cloud
• Sub-Second Billing
• Instant Scaling
• Focus on your code – Let Azure do the heavy lifting for you.

39.
Questions and Answers

40.
Thank you!
https://tryfunctions.com/ng-min/try?trial=true