View recording of this session at https://www.youtube.com/watch?v=oE5lrNn7bAg
Serverless Design Patterns - a quick overview of 3 very common design patterns with Azure Functions
2. Yochay Kiriatry
Principal Program Manager @ Microsoft
Azure Functions/ App Service
Technical Evangelist / Advocate
Bunch of startups
https://blogs.msdn.microsoft.com/appserviceteam
@yochayk
yochay@microsoft.com
13. • Azure Queues (SNS/ SQS) are an implementation detail.
• No visualization to show relationship between functions.
• There is no way to ‘represent’ a group of Function as ‘chained’.
F1 F2 F3 F4
14. TriggerFunc F1 F2 F3
• Azure Queues (SNS/ SQS) are an implementation detail.
• Each individual Function needs to be “aware” of other functions.
• Functions need to be idempotent.
• Functions need to “DoWork” and “UndoWork”
15.
16. TriggerFunc F1 F2 F3
• Azure Queues (SNS/ SQS) are an implementation detail
• Central Error Handling Function “understand” the chain/flow
Error Handler
29. Yochay Kiriatry
Principal Program Manager @ Microsoft
Azure Functions/ App Service
Technical Evangelist / Advocate
Bunch of startups
https://blogs.msdn.microsoft.com/appserviceteam
@yochayk
yochay@microsoft.com
Notes de l'éditeur
Yochay Kiriaty is a principal program manager at the Microsoft Azure team, specifically driving Web, Mobile, API and Functions experiences as part of Azure App Service Platform. Yochay has been working with web technologies since the late 90s and has a strange passion for scale and performance. Yochay joined Microsoft in 2006 after managing engineering teams for several Internet and Telecommunications start-ups. Until 2011 Yochay worked as a Technical Evangelist working with marquee customers on Windows and Azure adoption. In 2011 Yochay joined the Azure team working on a new project called Azure Websites, which today is known as Azure App Service. Yochay have been working on Azure App Services since project from the project’s day one. As part of the core team Yochay helped architect, shape the user experience and deliver one of the most popular services on Azure. Recently Azure launched the Azure Functions service and is now one of the fastest growing Azure services offering easy to start Serverless compute. You can contact Yochay at yochay@microsoft.com and follow him on Twitter at twitter.com/yochayk.
Yochay writes books, blogs, and articles about scale, apps, and good end-2-end user’s experience.
Evolution of “software” over time
Happening across two main axis:
Hardware abstraction: with HW virtualization, moving HW to the cloud, reducing HW operations with PaaS and Serverless. HW abstraction focuses on reducing the cost (time) of setting up and long term HW management. Basically, it takes about a minute to setup a VM that someone else manages, HW, for you.
Software architecture: from Monolithic, to N-Tier, to Micro-Services (SOA), to Functions (Serverless). I will argue, that the main advances in Application Software architecture focuses on reducing the long term cost of maintaining complex software system. Everyone agrees that monolithic architecture approach, is supper inefficient over the long run because it is hard to test and verify changes and it just doesn't’t scale- Not from engineering or management. The move to smaller and smaller chunks of code that are self-contained is happening. The latest buz word such as MicroServices and Functions are a good example.
If you think about it, Serverless is the first time we can actually use a single word, “Serverless”, to describe both the HW and Software improvments
On one hand, everyone understands Serverless mean a fully managed, self-contained ; system that abstract the use of servers
On the other hand, Everyone agree Serverless is event-based programing model
Evolution of “software” over time
Happening across two main axis:
Hardware abstraction: with HW virtualization, moving HW to the cloud, reducing HW operations with PaaS and Serverless. HW abstraction focuses on reducing the cost (time) of setting up and long term HW management. Basically, it takes about a minute to setup a VM that someone else manages, HW, for you.HW abstraction also increases desnsity, which drives a lot of the cost benefits …
Software architecture: from Monolithic, to N-Tier, to Micro-Services (SOA), to Functions (Serverless). I will argue, that the main advances in Application Software architecture focuses on reducing the long term cost of maintaining complex software system. Everyone agrees that monolithic architecture approach, is supper inefficient over the long run because it is hard to test and verify changes and it just doesn't’t scale- Not from engineering or management. The move to smaller and smaller chunks of code that are self-contained is happening. The latest buz word such as MicroServices and Functions are a good example.
If you think about it, Serverless is the first time we can actually use a single word, “Serverless”, to describe both the HW and Software improvments
On one hand, everyone understands Serverless mean a fully managed, self-contained ; system that abstract the use of servers
On the other hand, Everyone agree Serverless is event-based programing model
We are at the beginning of the “Serverless-area”.
Serverless is a very good improvement of Platform as a Service. Serverless builds on top of PaaS to further reduce Dev Ops from developers.
however, because we are at the early stages of the Serverless-Area and revolution, there still growing pains and lack of clarity. Fundamentally, with Functional Programing Model, the we are dealing with
Stateless distributed system
Scale by design, if you follow some basic rules and properly design your solution to fit FaaS
Offers an application model
But the thing is, with Serverless, we are getting a LOT of Functions!
There are a lot of Functions – even with a basic “CRUD” as single functions, you can very easily end up with many Functions. 50 to 200 functions are “standard” number of Functions in a given small-to-medium application.
Beyond the management nightmare, there are some software architecture ‘issues’
Expressed over many different functions:
With no an easy way to ‘group’ (cluster) them into logical building blocks.
Functions can’t “easily talk” to each other, so we end up using queues, SNS, etc… which can lead to spaghetti code
Visualizing the big picture is difficult – often I hear developers complaining it is hard to see/ understand the entire system. which raises the interesting questions, whether you even care to see / understand the entire system
A Function is not aware of other Functions… how do you handle errors across multiple functions that represent a given business process?
There are no ‘clear’ guidelines, best practices, only few patterns with focus on dev-ops
There are no ‘formal’ patterns
With that in mind, one of this session goals is to just highlight the fact we need to build and foster common usage patterns and start building repository of common Serverless ‘design’ patterns
There are a lot of Functions – even with a basic “CRUD” as single functions, you can very easily end up with many Functions. 50 to 200 functions are “standard” number of Functions in a given small-to-medium application.
Beyond the management nightmare, there are some software architecture ‘issues’
Expressed over many different functions:
With no an easy way to ‘group’ (cluster) them into logical building blocks.
Functions can’t “easily talk” to each other, so we end up using queues, SNS, etc… which can lead to spaghetti code
Visualizing the big picture is difficult – often I hear developers complaining it is hard to see/ understand the entire system. which raises the interesting questions, whether you even care to see / understand the entire system
A Function is not aware of other Functions… how do you handle errors across multiple functions that represent a given business process?
There are no ‘clear’ guidelines, best practices, only few patterns with focus on dev-ops
There are no ‘formal’ patterns
We are at the beginning of the “Serverless-area”.
Serverless is a very good improvement of Platform as a Service. Serverless builds on top of PaaS to further reduce Dev Ops from developers.
however, because we are at the early stages of the Serverless-Area and revolution, there still growing pains and lack of clarity. Fundamentally, with Functional Programing Model, the we are dealing with
Stateless distributed system
Scale by design, if you follow some basic rules and properly design your solution to fit FaaS
Offers an application model
With that opening in mind and somewhat general understanding of what we are trying to prove here
Now that we understand some of the pain points with having big application with many functions.
It is important to take a moment to review some basic best practices for Functions:
Functions should do one thing
Functions should finish as quickly as possible
Functions should be stateless
Functions should be idempotent
Why breakup a function?
Let’s imagine a simple solution – the new “Functions” hello world
Func1 – is a webhook for Twilio
Func2 - sentiment analysis + phrase analysis
Func3 – check if this number already called me – if yes… another call to a database
Func4 – store data in DocDB + send twilio reply
Amazon SQS requires you to implement your own application-level tracking, especially if your application uses multiple queues
https://agilevision.io/blog/serverless%20architecture/2017/02/12/easily-create-complex-workflows-with-aws-step-functions.html
Both allow you to orchestrate functions and create a ‘workflow’
Help with the issues of:
No visualization to show relationship between functions.
Queues (SQQ/ SNS) are an implementation detail.
But…
Building a very ‘monolithic’ design on Serverless architecture …
Building a very ‘monolithic’ design on Serverless architecture …
Building a very ‘monolithic’ design on Serverless architecture …
Scenarios and examples
Standalone (independent) functionality
X = Work todo
X = x1+… xi
foreach (xi)
DoWork(xi)
foreach (xi)
push xi Q (or topic)
DoWork “picks” work from Q (or topic)
Yochay Kiriaty is a principal program manager at the Microsoft Azure team, specifically driving Web, Mobile, API and Functions experiences as part of Azure App Service Platform. Yochay has been working with web technologies since the late 90s and has a strange passion for scale and performance. Yochay joined Microsoft in 2006 after managing engineering teams for several Internet and Telecommunications start-ups. Until 2011 Yochay worked as a Technical Evangelist working with marquee customers on Windows and Azure adoption. In 2011 Yochay joined the Azure team working on a new project called Azure Websites, which today is known as Azure App Service. Yochay have been working on Azure App Services since project from the project’s day one. As part of the core team Yochay helped architect, shape the user experience and deliver one of the most popular services on Azure. Recently Azure launched the Azure Functions service and is now one of the fastest growing Azure services offering easy to start Serverless compute. You can contact Yochay at yochay@microsoft.com and follow him on Twitter at twitter.com/yochayk.
Yochay writes books, blogs, and articles about scale, apps, and good end-2-end user’s experience.
