Azure Service Fabric: notes from the field (Sam Vanhoute @Integrate 2016)
•
1 like•585 views
This document summarizes Sam Vanhoutte's presentation on Azure Service Fabric. It discusses: 1. Codit's background and focus on integration solutions using Service Fabric. 2. An overview of Service Fabric's positioning as a platform for building microservices applications at scale, including comparisons to alternative approaches like Azure Cloud Services. 3. Key concepts in Service Fabric including programming models, service types, and partitioning for scale. 4. Examples of applications built on Service Fabric including connected buildings, sport club social platforms, and city camp reservation systems.
Report
Share
Azure Service Fabric: notes from the field (Sam Vanhoute @Integrate 2016)
- 1. Sam Vanhoutte CTO Codit, Integration MVP Azure Service Fabric: notes from the field
- 2. Hello world 2 International Focus + 100 Active customers 2000 Belgium 2004 France 2013 Portugal 2016 Switzerland 2016 U.K. Close collaboration with Microsoft +70 employees e-news + SoMe Focused on integration solutions @SamVanhoutte Integration MVP CTO Integration Azure IoT API mgmt
- 3. Agenda • Introduction • Positioning • Architecture • Concepts • Scenarios 3
- 4. Services built with Service FabricServices built with Service Fabric
- 5. 300+ Service Fabric Preview Customers
- 7. • Scales by cloning the app on multiple servers/VMs/Containers Monolithic application approach Microservices application approach • A microservice application separates functionality into separate smaller services. • Scales out by deploying each service independently creating instances of these services across servers/VMs/containers • A monolith app contains domain specific functionality and is normally divided by functional layers such as web, business and data App 1 App 2App 1
- 8. Cloud Services vs. Service Fabric Azure Cloud Services (Web and Worker Roles) Azure Service Fabric (Stateless, stateful or Actor services) • 1 role instance per VM • Uneven utilization • Low density • Slow deployment & upgrade (bound to VM) • Slow scaling and failure recovery • Limited fault tolerance • Many microservices per VM • Even Utilization (by default, customizable) • High density (customizable) • Fast deployment & upgrade • Fast scaling of independent microservices • Tunable fast fault tolerance Node types !
- 10. Microsoft Azure Service Fabric A platform for reliable, hyperscale, microservice-based applications Azure Windows Server Linux Hosted Clouds Windows Server Linux Service Fabric Private Clouds Windows Server Linux High Availability Hyper-Scale Hybrid Operations High Density Microservices Rolling Upgrades Stateful services Low Latency Fast startup & shutdown Container Orchestration & lifecycle management Replication & Failover Simple programming models Load balancing Self-healingData Partitioning Automated Rollback Health Monitoring Placement Constraints Develop once deploy everywhere
- 11. App1 App2 Service Fabric Microservices App Type Packages Service Fabric Cluster VMs
- 12. App1 App2 Handling Machine Failures App Type Packages Service Fabric Cluster VMs
- 14. State is external or non existing Multi-instance (parallel execution) Load balancing (singleton partition) 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 [StatePersistence(StatePersistence.None)] 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 stored with the service Reliable secondaries exist on other nodes Ranged or named partitioning Simplified programming model Single threaded execution Turn based communication [StatePersistence(StatePersistence.Persisted)] Programming models 14 StatefulStateless ServicesActors Guest executables
- 15. State is external or non existing Multi-instance (parallel execution) Load balancing (singleton partition) Activation & Background work Web API’s Web Frontend Protocol Gateway Background Workers State is external or non existing Multi-instance (parallel execution) Load balancing (singleton partition) Simplified programming model Single threaded execution Turn based communication [StatePersistence(StatePersistence.None)] 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 stored with the service Reliable secondaries exist on other nodes Ranged or named partitioning Simplified programming model Single threaded execution Turn based communication [StatePersistence(StatePersistence.Persisted)] Short Lived actions Fire & Forget Services, containing partitioned data Stateful receivers (locking, cursors) Simple queuing workers Caching scenarios Longer running workflows Related to functional entities: Shopping Basket, Conversations, Users, Sensors Programming models 15 StatefulStateless ServicesActors Keep it simple to start Often state still requires sync to external data source
- 16. 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 <ServiceManifest Name="QueueService" Version="1.0"> <ServiceTypes> <StatefulServiceType ServiceTypeName="QueueServiceType" HasPersistedState="true" /> </ServiceTypes> <CodePackage Name="Code" Version="1.0"> <EntryPoint> <ExeHost> <Program>ServiceHost.exe</Program> </ExeHost> </EntryPoint> </CodePackage> <ConfigPackage Name="Config" Version="1.0" /> <DataPackage Name="Data" Version="1.0" /> </ServiceManifest>
- 17. Application type ➔ Declarative template for creating an application ➔ Based on a set of service types ➔ Used for packaging, deployment, and versioning
- 18. Service Partitioning Node 5Node 4Node 3 Node 6Node 2Node 1 P2 S S S P4 S P1 S P3S S S • 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
- 19. Scenarios
- 20. Connected Building ➔ Enable state machine behavior for buildings, rooms, devices ➔ Scenario ➔ Physical events are ingested (Codit IoT 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)
- 21. Connected building 21Diagram: Tom Kerkhove Open Sourced Observer framework: https://github.com/paolosalvatori/servicefabricobserver
- 22. Talk2Fans – a startup for sport clubs ➔ Social (few writes, lot’s of reads) ➔ Talkies per club ➔ Talkies per game ➔ Push notifications ➔ Advertising ➔ Targetted advertising with telemetry ➔ Reporting needs
- 23. Talk2Fans – a startup for sport clubs 23Diagram: Thomas Houtekier
- 24. 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.
- 25. Node 01 Node 02 Node 03 Node 04 Node 05 City camp reservation system 25 REST API REST API REST API REST API REST API Stateless svc (OWIN) Communication Stateful svc (ReliableQueue) Latin Sport Sport Dev Music Music Music Latin Math Dev Dev Math Music Sport Math Ticket dispenser Stateful actors Jim Tom Jim Jim Tom Josh Josh Ann Ann Tom Ann Josh Registration process per user
- 26. 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
- 27. Integration Cloud – multi tenancy 27Diagram: Wouter Seye
- 28. Thank you! Keep in touch! Call or mail us. Ask questions. Happy to help. Stay tuned LinkedIn blog .codit.eu codit.eu NewsletterTwitter Pay us a visit