Sam Vanhoutte CTO Codit Integration MVP Azure Service

Sam Vanhoutte CTO Codit, Integration MVP Azure Service Fabric: notes from the field

Hello world 2000 Belgium 2004 France 2013 Portugal 2016 Switzerland 2016 U. K. Integration + 100 Active customers Io. T e-news + So. Me @Sam. Vanhoutte Integration MVP CTO +70 employees Azure API mgmt International Focus Close collaboration with Microsoft Focused on integration solutions 2

Agenda • • • Introduction Positioning Architecture Concepts Scenarios 3

Services built with Service Fabric

300+ Service Fabric Preview Customers

Positioning µ-services 6

Monolithic application approach • A monolith app contains domain specific functionality and is normally divided by functional layers such as web, business and data • Scales by cloning the app on multiple servers/VMs/Containers App 1 Microservices application approach • A microservice application separates functionality into separate smaller services. • App 1 App 2 Scales out by deploying each service independently creating instances of these services across servers/VMs/containers

Cloud Services vs. Service Fabric Azure Cloud Services Azure Service Fabric (Web and Worker Roles) • • • 1 role instance per VM Uneven utilization Low density Slow deployment & upgrade (bound to VM) Slow scaling and failure recovery Limited fault tolerance Node types ! (Stateless, stateful or Actor services) • • • Many microservices per VM Even Utilization (by default, customizable) High density (customizable) Fast deployment & upgrade Fast scaling of independent microservices Tunable fast fault tolerance

Architecture resilient against failure 9

Microsoft Azure Service Fabric Develop once deploy everywhere A platform for reliable, hyperscale, microservice-based applications Microservices High Availability Simple programming models Hybrid Operations High Density Hyper-Scale Windows Server Data Partitioning Rolling Upgrades Automated Rollback Service Fabric Low Latency Stateful services Health Monitoring Container Orchestration & lifecycle management Placement Constraints Fast startup & shutdown Load balancing Windows Server Linux Azure Self-healing Replication & Failover Linux Hosted Clouds Windows Server Linux Private Clouds

Service Fabric Microservices App 1 App 2 App Type Packages Service Fabric Cluster VMs

Handling Machine Failures App 1 App 2 App Type Packages Service Fabric Cluster VMs

Concepts µ-services 13

Programming models Actors Services Stateless Stateful State is external or non existing Multi-instance (parallel execution) Load balancing (singleton partition) Activation & Background work State is stored with the service Reliable secondaries exist on other nodes Ranged or named partitioning Concurrent transactional state changes Reliable collections Activation & Background work State is external or non existing Multi-instance (parallel execution) Load balancing (singleton partition) Simplified programming model Single threaded execution Turn based communication State is stored with the service Reliable secondaries exist on other nodes Ranged or named partitioning Simplified programming model Single threaded execution Turn based communication [State. Persistence(State. Persistence. None)] [State. Persistence(State. Persistence. Persisted)] Guest executables 14

Programming models Keep it simple to start Actors Services Stateless Stateful State is external or non existing Multi-instance (parallel execution) Web API’s Load balancing. Web (singleton partition) Frontend Activation & Protocol Background work Gateway Background Workers State is stored with the service Reliable secondaries exist on other nodes Services, containing partitioned data Ranged or named partitioning Stateful transactional receivers (locking, cursors) Concurrent state changes Often state still Simple queuing workers Reliable collections requires sync to scenarios Activation & Caching Background work external data source State is external or non existing Multi-instance (parallel execution) Load balancing (singleton partition) Short Lived actions Simplified programming model Fire & Forget Single threaded execution Turn based communication State is stored with the service Reliable secondaries exist on other nodes Longer running workflows Ranged or named partitioning Related to functional entities: Simplified programming model Shopping Basket, Conversations, Users, Single threaded execution Sensors Turn based communication [State. Persistence(State. Persistence. None)] [State. Persistence(State. Persistence. Persisted)] 15

Service type ➔ Services types are composed of code/config/data packages ➔ ➔ Code packages define an entry point (dll or exe) Config packages define service specific config information Data packages define static resources (eg. images) Packages can be independently versioned <Service. Manifest Name="Queue. Service" Version="1. 0"> <Service. Types> <Stateful. Service. Type. Name="Queue. Service. Type" Has. Persisted. State="true" /> </Service. Types> <Code. Package Name="Code" Version="1. 0"> <Entry. Point> <Exe. Host> <Program>Service. Host. exe</Program> </Exe. Host> </Entry. Point> </Code. Package> <Config. Package Name="Config" Version="1. 0" /> <Data. Package Name="Data" Version="1. 0" /> </Service. Manifest>

Application type ➔ ➔ ➔ Declarative template for creating an application Based on a set of service types Used for packaging, deployment, and versioning

Service Partitioning • • Services can be partitioned for scale-out. You can choose your own partitioning scheme. Service partitions are striped across machines in the cluster. Replicas automatically scale out & in on cluster changes Node 1 Node 2 Node 3 Node 4 S S P 4 P 2 S S P 1 S S S P 3 S Node 5 Node 6

Scenarios

Connected Building ➔ ➔ Enable state machine behavior for buildings, rooms, devices Scenario ➔ ➔ Physical events are ingested (Codit Io. T field gateway) Event routing • • ➔ Events are routed to the right device Actor Related infrastructure actors can observe events from their devices (Meeting room 1 wants to get events from Motion sensor 01) Stateful workflows (state machines)

Connected building Open Sourced Observer framework: https: //github. com/paolosalvatori/servicefabricobserver Diagram: Tom Kerkhove 21

Talk 2 Fans – a startup for sport clubs ➔ Social (few writes, lot’s of reads) ➔ ➔ Advertising ➔ ➔ Talkies per club Talkies per game Push notifications Targetted advertising with telemetry Reporting needs

Talk 2 Fans – a startup for sport clubs Diagram: Thomas Houtekier 23

City camp reservation systems ➔ Registering kids for holiday-camps (sports, leisure, language…) ➔ ➔ ➔ Big peak of requests (ticketing system) on predefined timestamps Per camp, first X registered persons are allowed Ticket dispenser service needed to distribute tickets to allow further registration.

City camp reservation system Communication Ticket dispenser REST API Latin Music Dev REST API Sport Music Math REST API Sport Latin Music REST API Dev Math Sport REST API Music Dev Math Stateless svc (OWIN) Stateful svc (Reliable. Queue) Registration process per user Jim Ann Tom Ann Node 02 Jim Ann Josh Jim Tom Stateful actors Node 01 Node 03 Node 04 Josh Node 05 25

Integration Cloud ➔ Started 6 years ago on Cloud Services. Challenges: ➔ ➔ Complex task & thread management Deployment and versioning Multi-tenancy Migration to Service Fabric ➔ ➔ Reliable services for adapters Stateful actors for tracking logic High density / multi tenancy Side by side versioning www. integrationcloud. eu

Integration Cloud – multi tenancy Diagram: Wouter Seye 27

Thank you! Keep in touch! Call or mail us. Ask questions. Happy to help. Stay tuned Linked. In Twitter blog. codit. eu Newsletter Pay us a visit