Microservices: The View from the Peak of Expectations
6 likes1,444 views
The document discusses the benefits and challenges of moving from monolithic architectures to microservices architectures. It outlines some of the core tenets of microservices including small, independent teams focusing on individual bounded contexts. It also discusses important considerations for microservices like standardizing interfaces, service discovery, monitoring, and automation tools. The conclusion recommends judicious adoption of microservices and emphasizes the importance of architecture maturity, DevOps capabilities, and culture change.
Microservices: The View from the Peak of Expectations
- 1. The View from the Peak of Inflated Expectations Saul Caganoff CTO, Sixtree @scaganoff Melbourne Microservices Meetup
- 3. The 2015 Hype Cycle
- 4. § Get awayfrom the “Big Ball of Mud” § To go faster § Scale Better § Infinite scalability (bewarescale envy) § Differential scalability § Organizing & scaling teams § Open up new capabilities § Evolutionary architectures § Try new ideas Core Tenets: Culture Architecture Automation
- 5. § Depending on: Somebody else § siloed teams: front-ends, back-ends, QA, operations § Shared infrastructure § Shared database creates schema dependencies § Shared architecture layers – message queues & orchestration § Other people’s services § Shared code – shared libraries, packages,dependency management § Expert knowledge – no-one understands the whole system § Permission – centralised governance
- 6. § Small Cross-FunctionalTeams – give the team all they need to deliver business value – two pizza rule § Vertical partitioning – partition systems along vertical lines – eschew the horizontally layered architecture § Keep services small – so they fit in your head § Self-contained code – “a single unix process” (but containers) § Loose coupling – choreography vs orchestration § Standardiseat the interfaces – governance only where its needed Result:Ownership & Autonomy
- 8. § Collaboration § Shared Responsibility § Autonomy § Quality § Feedback § Automation § Small Teams § Segmented on business domain,not technology § Cross-functional § Autonomous § No hand-offs,no blame-shifting
- 12. Finance Sales Fulfilment Product § Bounded Contexts are areas of cohesion in your domain model § Boundaries appear where domain concepts “break” § Bounded Contexts are the handle for organizing your § Application § Teams § Runtime services
- 13. § Understand your application’s Bounded Contexts § Carve off a small domain (ideallynon-transactional) § Run as microservices § Autonomy § Choreography with rest of the monolith § Automation: CI/CD § Iterate DON’T § Still understand your application’s Bounded Contexts § But carving up a monolith addscomplexity – Stefan Tilkov
- 14. § Security § Data Integration & Duplication § Monitoring § Deployment & Management § Service Registration & Discovery § Developer Tooling § Partitioning § (No) Transactions § Reporting § Data Migration § Protocols & Standards § Distributed Tracing & Error Handling § Failure & Resiliency
- 16. § Standardiseall the Interfaces § Standard API:REST (ish) or RPC – use a contract! § Configuration:Environment Variables § Logging:common format to stdout/stderr § Monitoring endpoints: /stats or /health § Events: publish standard event structures
- 17. § Configuration: environment management § Log correlation & tracing: § Shipping and storage/analytics § Dapper & Zipkin § Monitoring: § Infrastructure monitoring is not enough § End-user experience § Synthetic transactions § Event processing: § Choreography, CQRS for reporting § Service registration & discovery: § Load-balancing, failover § Orchestration: § Canary deployments § Blue/Green Deployments
- 18. § Testing: § Continuous integration § Consumer-Driven Contracts § Resilience: § Bulkheads § Circuit Breakers § Partial Failure § Anti-fragility:extremely difficult to test for emergent behaviours § Failure Injection § Simian Army
- 21. § All inclusive or § Assemble your own ”best of breed”
- 23. Build Test Package Docker Build Docker Registry Ansible Deploy K8s Schedule K8s Run Docker Pull K8s Orchestrate § Dozens of Services § Project setup § Build & Test § Artefacts § Deployment § CI and CD are important pre-requisites for microservices
- 24. § Microservices architecture adoption is growing § Be judicious in deciding if it’s right for you § Architecture maturity § DevOps and automation § Team size § Infrastructure will become easier and more common § Culture is the harder thing to change § Microservices might just be the new de facto cloud-native architecture ? § And what about serverless?
- 25. § http://martinfowler.com/microservices/ § http://microservices.io/patterns/ § https://www.infoq.com/news/2015/06/monolith-vs-microservices § https://eng.uber.com/soa/ § https://yow.eventer.com/yow-2014-1222/the-odyssey-from- monoliths-to-microservices-at-realestate-com-au-by-beth-skurrie- and-evan-bottcher-and-jon-eaves-1751 § https://github.com/realestate-com-au/pact § https://www.youtube.com/channel/UCeRQROVrFDzKNq4e02ko4c w § http://www.meetup.com/Melbourne-Microservices/