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
3. 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
Peter Sbarski intro slide
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
Notas do Editor
Before we start, I was told a good presentation must start with a personal story, in order to connect with the audience
So here is my personal story that I hope helps set the stage for this session.
I might be dating my self here, but let me take you to late 2001. Right after the .COM area, where I crushed and burned my start up, like so many others
I was leading a small team of developers working on creating an EPG for a set top box.
Technolgy: HTML and Javascript
Quick reminder, back in 2001 JS and HTML were somewhat early stage. How early, To give you example Yahoo and ask.com where the leading search engines…
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.
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. HW abstraction also increases density, which drives a lot of the cost benefits …
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 density, 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 buzz 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 improvements
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
We are at the beginning of the “Serverless-area”.
While Serverless is a very good improvement of Platform as a Service - Serverless builds on top of PaaS to further reduce Dev Ops from developers. It is still early days of serverlsss.
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
Offers an application model – event based
Stateless distributed system
Scale by design, if you follow some basic rules and properly design your solution to fit FaaS
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
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
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’
Deals with No visualization to show relationship between functions.
Queues (SQQ/ SNS) are an implementation detail.
We don’t have time to review this, but it is a nightmare
Here is a pointer to the repo
To Serverless and Beyond: Opening New Possibilities in App
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.