Download as PDF, PPTX
![]
Monitoring is the new testing](https://image.slidesharecdn.com/divideandconquer-170313111540/75/Divide-and-Conquer-Easier-Continuous-Delivery-using-Micro-Services-24-2048.jpg)
![]
Monitoring is the new testing](https://crownmelresort.com/image.slidesharecdn.com/divideandconquer-170313111540/75/Divide-and-Conquer-Easier-Continuous-Delivery-using-Micro-Services-24-2048.jpg)
Uploaded byCarlos Sanchez
Divide and Conquer: Easier Continuous Delivery using Micro-Services
This document discusses using microservices for easier continuous delivery. Some key points discussed include: - Microservices involve developing an application as a suite of small services that communicate lightly and deploy independently. - Benefits include organizing around business capabilities, decentralized governance and data management, and infrastructure automation. - Continuous deployment requires automation at all stages including monitoring, reacting to problems, and preventing problems. - Techniques like blue-green and canary deployments allow deploying without downtime. Monitoring is also important for taking proactive actions. - Designing infrastructure as "cattle" rather than "pets" and embracing failure are discussed as important principles. Stateful services and ensuring resilience and self-healing
More Related Content
Similar to Divide and Conquer: Easier Continuous Delivery using Micro-Services
Divide and Conquer: Easier Continuous Delivery using Micro-Services
- 1. DIVIDE AND CONQUER EASIERCONTINUOUS DELIVERY USING MICRO-SERVICES Carlos Sanchez csanchez.org @csanchez Watch online at carlossg.github.io/presentations
- 2. ABOUT ME Engineer @CloudBees, scaling Jenkins Author/contributor of Jenkins Kubernetes and Mesos plugins Long time OSS contributor at Apache (Apache Maven), Eclipse, Puppet,…
- 3. MICRO SERVICES the microservicearchitectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, o en an HTTP resource API.
- 4. These services arebuilt around business capabilities and independently deployable by fully automated deployment machinery. James Lewis and Martin Fowler
- 5. One application, multiplesmall services Separate processes with lightweight comunications, typically HTTP Deployed independently Minimal centralized management Fully automated deployment
- 6.
- 7. COMPONENTIZATION VIA SERVICES vslibraries
- 8. ORGANIZED AROUND BUSINESSCAPABILITIES cross functional teams PRODUCTS NOT PROJECTS business oriented ongoing maintenance
- 9. DECENTRALIZED GOVERNANCE different lenguages Amazon:you build it you run it
- 10. DECENTRALIZED DATA MANAGEMENT eachservice manages its own database
- 11.
- 12. EVOLUTIONARY DESIGN modular designand replaceability
- 13. DESIGN FOR FAILURE resiliencyand self-healing
- 14. Rapid provisioning Basic monitoring Rapidapplication deployment - DevOps Culture https://martinfowler.com/bliki/MicroservicePrerequisites.html
- 15. ORGANIZATIONAL STRUCTURE Any organizationthat designs a system will inevitably produce a design whose structure is a copy of the organization's communication structure. Conway's Law
- 16. CONTINUOUS DEPLOYMENT The first90% Develop Build Test Deploy
- 17. CONTINUOUS DEPLOYMENT The other90% Monitor React to problems Prevent problems
- 18.
- 20. If you haven'tautomatically destroyed something by mistake, you are not automating enough
- 21. DEPLOY WITHOUT DOWNTIME Blue-Greendeployment Canary deployment
- 24. ] Monitoring is thenew testing
- 25. Use data frommonitoring Take proactive actions, ie. scaling
- 26.
- 27.
- 28. EXAMPLE: AWS Resource limits:VPCs, snapshots, some instance sizes Rate limits: affect the whole account
- 29. EXAMPLE: AWS Always usedifferent accounts for testing/production and possibly different teams Retrying is your friend, but with exponential backoff
- 30.
- 31. How would youdesign your infrastructure if you couldn't login? Ever. Kelsey Hightower
- 32. STATEFUL SERVICES AREHARD Inherently Do your services need to be deployed in a specific order?
- 33. Adding more replicasto services is not trivial data needs to be synced across replicas what if you kill a master node vs a replica
- 34. RESILIENT & SELF HEALINGSYSTEMS
- 35. Services need toauto adapt to changes and errors In case of unexpected errors, try to adapt and restore to working condition
- 36. Never expect anorder of deployment Will your app crash if database is not yet up and running?
- 37. In case yourdatabase is down, what would you do? 1. send an alert and fail fast 2. keep trying
- 38. Services need toretry calls Can conflict with fail-fast
- 39. In complex systemsthere is no single cause of failure
- 40.
- 41. THE PRINCIPLES OFCHAOS ENGINEERING principlesofchaos.org Build a Hypothesis around Steady State Behavior Vary Real-world Events Run Experiments in Production Automate Experiments to Run Continuously
- 43. FIT : FAILUREINJECTION TESTING Middle ground between isolated testing and large scale chaos exercises http://techblog.netflix.com/2014/10/fit-failure-injection-testing.html
- 44.
- 47. BUT IT ISNOT TRIVIAL
- 48. CLUSTER ORCHESTRATION Allow runningservices in cluster Abstract underlying infrastructure High availability Handle persistence for you Network isolation and SDNs
- 50.