Introduction to service architectures and Azure platform Jeffrey

Introduction to service architectures and Azure platform Jeffrey Richter Boris Scholl

Jeffrey Richter: Microsoft Software Engineer, Wintellect Co-Founder, & Author Jeffrey. R@Microsoft. com www. linkedin. com/in/Jeff. Richter @Jeff. Richter

Boris Scholl: Principal PM, Azure Compute • Responsible for the open source development and devops strategy for containerized workloads on Azure compute • Responsible for container integration with Service Fabric • Passionate about distributed systems bscholl@microsoft. com http: //www. linkedin. com/in/bscholl

Course overview Introduction to service architectures and Azure platform Microservices patterns Building microservices on Azure Container Service Building microservices on Azure Service Fabric

Agenda Introduction Azure compute for Microservices Service Overview Glance at Azure Container Service 12 Factor apps Glance at Azure Service Fabric Container basics

Introduction § Every business will be a software business § Even companies that core competency is not software (Car manufacturers) § Satya Nadella, March 2015 (Convergence 2015 US conference) § Why? § Fast way to differentiate from competition § Fast to market § Respond to failure § Requires reliable, scalable cloud applications

Service § § § Code solving a domain-specific problem Built by small team using a particular technology stack Exposes features to caller via a well-defined API contract Degrades gracefully when dependent services fail Can be upgraded independently of calling services Dividing a big service into smaller services is often referred to as a microservices architecture

Scalable service considerations § You need to dynamically scale services to manage tension between processing requests quickly & cost § Clients dynamically discover services to communicate § Use load balancer § Use a registry § Data must be partitioned for size/speed § Diagnostic info must for all instances are buffered and archived in a central, external store

Canonical Service Architecture Load Balancer Web Site Svc (1+ instances) Internal Svc #1 (1+ instances) Internal Svc #2 (1+ instances) Service Registry IS #1 -1 http: //. . . IS #1 -? http: //. . . IS #2 -1 http: //. . . IS #2 -? http: //. . .

Pain points § More services means more network communication § Decreases overall performance due to network hops & (de)serialization § Requires more failure (timeout) recovery code § Hard to test in isolation without dependent services § Hard to debug/monitor across services § New service versions must support old & new API contracts simultaneously because client services don’t upgrade at the same time § Developers trade short-term pain for long-term gain

12 -Factor Apps http: //12 factor. net

12 -Factor Apps (1 -5) 1. 2. 3. 4. 5. Single root repo; don’t share code with another app Deploy dependent libs with app No config in code; read from environment vars Handle unresponsive app dependencies robustly Strictly separate build, release, & run steps § Build: Builds a version of the code repo & gathers dependencies § Release: Combines build with config Release. Id (immutable) § Run: Runs app in execution environment

12 -Factor Apps (6 -12) 6. 7. 8. 9. 10. 11. 12. App executes as 1+ stateless process & shares nothing App listens on ports; avoid using (web) host Use processes for isolation; multiple for concurrency Processes can crash/be killed quickly & start fast Keep dev, staging, & prod environments similar Log to stdout (dev=console; prod=file & archived) Deploy & run admin tasks (scripts) as processes

Containers

Density & Isolation levels More isolated More efficient PC VM Container Proces s Hardware Not shared Shared Kernel Not shared Shared* Shared System Resources (ex: File System) Not shared Shared

What is a container • § Allows a versioned set of dependencies (components, runtimes, etc. ) to run side-by-side with another set of dependencies in an isolated runtime environment on the same PC/VM Container: App-A: v 1 Container: App-B: v 3 Container: App-A: v 2 App-A v 1 App-B v 3 App-A v 2 Lib-L v 3 Lib-M v 2 Runtime v 7 Runtime v 6 Runtime v 5

“Docker Run App-A: v 1” Operating System (Linux/Windows) App-A: v 1 Docker Client Docker Daemon “docker run App-A: V 1” App-A: v 1 App-B: v 3 App-A: v 2 App-A: v 1

Microservices and containers “Microservices is an architectural design point; containers are an implementation detail that often helps. ”

Demo

Azure Compute Platform

Azure Compute Platform Overview Paa. S Service Fabric Apps Power Apps Azure Functions Web/ Mobile App Service Media Services Stream Analytics Rapid Development VM Scale Sets Iaa. S Virtual Machines High Control Azure

What are Virtual Machine Scale Sets? • A way to deploy and manage a set of identical VMs • Integrate with Azure Autoscale • Integrate with Azure Load Balancer • An Azure Compute resource Microsoft. Compute/virtual. Machine. Scale. Sets • Scalable compute layer for hyper scale apps • An infrastructure for Paa. S

VM Scale Sets in ARM Manage groups of identical VMs Auto-Scalable Fast Customizable Windows or Linux VM extensions Open Paa. S platform Ease of Management Focus on target instance count • Updateable • • Resource Group Subnet Scale Set V M V M Scalable NIC Scalable Storage V M … Extensions VNET https: //github. com/Azure/azure-quickstart-templates

Azure Container Services Service Tooling Containers Layer Supported Technologies Configuration as Code Host cluster management Container orchestration Monitoring ARM, Dockerfile, Docker Compose VM Scale Sets Docker Swarm, DC/OS App. Dynamics, OMS, AI

Docker Swarm Mode

DC/OS Mode

Building service based applications on ACS § ACS provides the infrastructure § No opinion on the Docker registry § Use the service of choice for Service Registry/Discovery § Mesos-DNS § Marathon-LB § Minuteman § Use your favorite CI/CD pipeline § Use your favorite diagnostics/monitoring solution § Check out Building and deploying distributed applications to the Azure Container Service

Demo

Azure Service Fabric

Service Fabric: A Microservices Platform Public Cloud On Premises Private cloud Other Clouds Developer

Service Fabric Cluster with 5 Nodes Datacenter (Azure, Amazon, On-Premises) PC/VM/C #2 Service Fabric Your code, etc. PC/VM/C #3 Service Fabric Your code, etc. PC/VM/C #1 (Port: 19080) Service Fabric Load Balancer Web Request (Port: 80/443/? ) *SF supports 1, 000 s of nodes Your code, etc. PC/VM/C #5 Service Fabric Your code, etc. PC/VM/C #4 Service Fabric Your code, etc.

Service Fabric Platform Capabilities § All code and programming models § § Fast deployment Placement and activation Reliability High density § Health reporting § Coordinated upgrades § Service endpoint discovery

Website Guest Executable Service. Manifest. xml <Service. Manifest Name="Pkg-Svc. Website" Version="1. 0. 0" …> <Service. Types> <Stateless. Service. Type. Name="Svc. Website. Type" Use. Implicit. Host="true"/> </Service. Types> <Code. Package Name="Code" Version="1. 0. 0"> <Entry. Point> <Exe. Host> <Program>node. exe</Program> <Arguments>Server. js</Arguments> </Exe. Host> </Entry. Point> </Code. Package> </Service. Manifest>

Service Fabric Platform Capabilities § All code and programming models § § Fast deployment Placement and activation Reliability High density § Health reporting § Coordinated upgrades § Service endpoint discovery § Reliable Services programming model § Dynamic resource balancing based on actual resource usage § Integrated application patterns e. g. Actor pattern and Web. Api § Visual Studio development e. g. F 5 debugging, diagnostics events, package and deploy

State Architectures: Traditional vs Service Fabric Load Balancer Stateless Web Load Balancer Stateless Compute Stateful Data Cache Stateless Web Stateful Compute Other Internal Tiers ?

Service Fabric Platform Capabilities § All code and programming models § § Fast deployment Placement and activation Reliability High density § Health reporting § Coordinated upgrades § Service endpoint discovery § Reliable Services programming model § Dynamic resource balancing based on actual resource usage § Integrated application patterns e. g. Actor pattern and Web. Api § Visual Studio development (packaging, deploy, debugging, diagnostics) § Reliable Collections programming model § No external storage service § Lower latency compared to external storage

Demo