Serverless patterns v3 public

Editor's Notes

• #3: 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.
• #4: 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
• #5: 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
• #6: 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
• #7: 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
• #8: 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
• #10: 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
• #11: Amazon SQS requires you to implement your own application-level tracking, especially if your application uses multiple queues
• #12: 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…
• #14: Building a very ‘monolithic’ design on Serverless architecture …
• #15: Building a very ‘monolithic’ design on Serverless architecture …
• #17: Building a very ‘monolithic’ design on Serverless architecture …
• #23: 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)
• #30: 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.