From a monolith to microservices with Azure Service Fabric
•Descargar como PPTX, PDF•
0 recomendaciones•1,221 vistas
Presentation of an in depth analysis of a large monolithic system, moving to microservices. Stephane Erbrech talks about the challenges met, and demonstrates how Azure Service Fabric can enable and facilitate major aspects of this type of architecture.
Recomendados
Recomendados
Más contenido relacionado
Destacado
Destacado (14)
Similar a From a monolith to microservices with Azure Service Fabric
Similar a From a monolith to microservices with Azure Service Fabric (20)
Último
Último (20)
From a monolith to microservices with Azure Service Fabric
- 1. Service Fabric Result of an experiment Stéphane Erbrech @serbrech
- 2. Stéphane Erbrech Webstep 02/12/2016 2 Twitter : @serbrech http://www.erbrech.com/blog
- 3. Origins of this experiment Microservices DevOps Concepts : Service Discovery Concepts : Reverse Proxy Demos Challenges Conclusion 02/12/2016 3
- 6. Think locally, Act Globally 02/12/2016 6
- 7. The road to Microservices 02/12/2016 7
- 8. 02/12/2016 8
- 9. 1 year of “Microservices” Which module does this functionality fit? Add code Merge Get a coffee 02/12/2016 9
- 10. 1 year of “Microservices” How/where do we host this service? Where? Cloud? Which product? How to deploy? Monitor? communicate with The Monolith? Business case validation? Configuration management? (that one is a biggy) On premise? IIS Setup? Authentication/Authorization? Logging? What DB can/should we use? SqlServer, Ravendb, DocumentDB? Versioning? Test environments? CI setup? Deployment scripts? Internet facing services? What about security? Etc, … 02/12/2016 10
- 11. New services nearly every release, every week 150 git repos 1 person can’t assess the entire system 1 year of “Microservices” 02/12/2016 11
- 12. 1 year of “Microservices” # Windows services # IIS processes 02/12/2016 12
- 13. 1 year of “Microservices” 40 Windows services (doubled) 52 IIS processes (doubled) X2 (x4) 02/12/2016 13
- 15. Scalability Highly Available 24/7 Zero Down Time DeploysCloudServerless DevOps Blue Green 02/12/2016 15
- 18. Service Discovery Decouple the who from the where 02/12/2016 18
- 19. Service A Service B config Communicate 02/12/2016 19
- 20. Service Discovery Service A Service B Config Communicate 02/12/2016 20
- 21. Service Discovery Service Discovery Service Discovery Service A Service B Communicate Highly available, Consistent 02/12/2016 21
- 22. Service Discovery Service Discovery Service Discovery Service A Service B Communicate Highly available, Consistent Service A Service A Service B Service B 02/12/2016 22
- 26. Service DiscoveryService DiscoveryService Discovery Service A Service B Service AService A Service BService B R Reverse proxy 02/12/2016 26
- 29. 02/12/2016 29 Cluster management for microservices Windows or Linux Process deployment and orchestration
- 30. 02/12/2016 30 Stateless / Stateful services Partitions Health monitoring Actors Containers
- 34. Minimize (negative) impact, Maximize benefits 02/12/2016 34
- 35. Can we do this? What would this mean for developers? What would it mean for DevOps? What does it mean for the Lifecycle? What do we get from this? So, can we have the cake, and eat it too? 02/12/2016 35
- 36. Challenges MSMQ : bound to a machine Distributed Transactions 02/12/2016 36
- 40. DTC DTC (and other 2PC protocols) require HA and low latency between resources. Incompatible with the cloud 02/12/2016 40
- 41. Outbox and Deduplication Pattern “Using Outbox allows for running endpoints with similar reliability to DTC while not actually using DTC.” At least once + deduplication DTC : Msmq/NServiceBus 02/12/2016 41 https://docs.particular.net/nservicebus/outbox/
- 42. 02/12/2016 42 DTC : WCF No tricks there unfortunately Move data Replace with messaging
- 43. 02/12/2016 43 Wrap up Service Fabric ticks all the boxes Cloud vs On-prem Not invasive Future proof (cloud, container, no vendor lock-in) Remove DTC and MSMQ
- 44. 02/12/2016 44 Thank you Microservices article http://www.erbrech.com/blog/2016/10/27/What-we-dont-tell-you-about-microservices.html Hosting a web app In Service Fabric http://www.erbrech.com/blog/2016/11/01/Hosting-a-web-application-in-Service-Fabric.html Service Fabric Overview https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-overview Twitter : @serbrech http://www.erbrech.com/blog
Notas del editor
- Workers Comp : This time we’re going to be more independent… Success, but painful Contact : New ravendb -> ARM + DSC on our shoulders Separate app server -> ARM + DSC (msmq sucks!) And that’s fare, you bear the extra work because we don’t fit in the current picture.
- Build script, leveraged by everyone Versioning/nuget RavenDb (cry) Octopus and teamcity templates Building blocks, legos
- History of waypoint from monolith to microservices NSB before it was even cool Distributed, but not really Dependency Transactions It was a long debate, but we understood it now. It’s still hard though. Towards smaller services The first ones were adventurous and had to tackle lots of questions that were unanswered. paved the way, paved the way further… And here we are today, with about 10 teams writing new small(ish) services, web apis, web components, spas, etc… WE DO MICROSERVICES
- WE DO MICROSERVICES
- New services nearly every release, if not every week 150 git repos in a year. (SPAs, Web Apis, Wcf, Windows Services, Batch, Infrastructure Services) Majority of services still dependent in some way on waypoint Only a few developers are involved in the big bang deployment that occurs once a month It becomes increasingly hard (read, impossible) for 1 person to know if the system is 100% OK
- Everything is a trade off in software Clear that we do not get the local simplicity for free The cost is the architecture and infrastructure complexity. Devops We do all this because we need flexibility… there are reasons behind.
- Single instance of every Messaging services running our core business logic, all on the same physical machine. Infrastructure Suffering. So how do we go from there?
- So that if I deploy a service to
- Service B Config to call Service A Drawback. What happens if I want to move service A to a different place? Ouch…
- Abstract the where, and the namig service. Gateway to our cluster
- Pretty negative because too invasive. But it’s not All in one What I told you and more Integrate with Azure Provides apis Runs locally on dev machine Can install on-premise. Can provision on azure with portal integration The more you use it, the more benefits you get from it
- Cluster management bells and whistles
- Electronic Consent Self Hosted (Owin) App Manifest, Service Manifest, Service Proxy Communicate with RavenDB just the same. No difference there. It’s just network, it’s just processes. No magic
- Show setup Show caller Call endpoint directly. Scale up WOW! Scale Down to 0 Scale back up Tax caller to reverse proxy
- What about windows services? Again, not magic… But…. msmq
- Progressively migrate services? All but queues…
- If not we need to think twice about microservices… Ideally, not much… keep working the same as today Stop thinking about server, think about environment Flexibility, scale endpoints Deployment? Enables progressive rollout!
- Azure Service Bus, Rabbitmq But also SqlServer
- Cloud strategy : handle failures through HA archi and infra. Handle the Chaos monkey.
- Reliability : ExactlyOnce At least once + Deduplication
- Thank If to let me work on this and support the research I wish I could help taking this further, Hope it will be taken further at waypoint as I will unfortunately not be on the project from December 15