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.

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

9. Domain SYSTEM ORGANIZATION

10. Domain SYSTEM ORGANIZATION

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/