1. Pattern language
1.1. Reusable solution to a problem occurring in a particular context
1.1.1. Name
1.1.2. Context
1.1.3. Problem
1.1.4. Forces
1.1.5. Solution
1.1.6. Resulting context
1.1.6.1. Benefits
1.1.6.2. Drawbacks
1.1.6.3. Issues to resolve
1.1.7. Related patterns
1.1.7.1. Alternative solutions
1.1.7.2. Solutions to problems introduced by this pattern
1.2. Great framework to describe and discuss about tech
2. What?
2.1. Microservices = SOA done right
3. When?
3.1. In the beginning (startup)?
3.1.1. You don't need it
3.1.2. It will slow you down
3.2. Later on?
3.2.1. You need it
3.2.2. Refactoring is painful
3.3. Microservices are necessary but insufficient
3.3.1. MS-based app arhitecture
3.3.2. Deployment
3.3.3. People
4. How?
4.1. Art of scalability
4.1.1. Scale by splitting different things (Y) - functional decomposition
4.1.1.1. Goals
4.1.1.1.1. Separate components with conflicting resource reqs => scale more easily
4.1.1.1.2. Most changes affect only a single service <=> Develop and deploy independently in parallel with other changes
4.1.2. Scale by splitting similar things (Z)
4.1.3. Horizontal duplication (X)
4.2. Partitioning
4.2.1. Partitioning strategies
4.2.1.1. Parallelise development and deployment
4.2.1.2. Partition by noun (Catalog service)
4.2.1.3. Partition by verb (Checkout UI)
4.2.1.4. Partition by subdomain
4.2.1.5. Single responsibility principle (Bob Martin)
4.2.1.6. Do one focussed thing well (unix utilities)
4.2.2. How to enforce consistency without 2PC?
4.2.3. How many services?
4.2.3.1. Too few
4.2.3.1.1. Drawbacks of monolithic architecture
4.2.3.2. Too many
4.2.3.2.1. Runtime overhead
4.2.3.2.2. Risk of excessive network hops
4.2.3.2.3. Potentially difficult to understand system
4.2.4. Anti-pattern: distributed monolith
4.3. Deployment
4.3.1. Forces
4.3.1.1. Cost-effective
4.3.1.2. Reliable
4.3.1.3. Isolated service instances
4.3.1.4. Independently
4.3.1.5. Building and deploying must be fast
4.3.1.6. Services are written with many techs
4.3.2. Multiple service instances per host
4.3.2.1. Benefits
4.3.2.1.1. Efficient resource utilization
4.3.2.1.2. Fast deployment
4.3.2.2. Drawbacks
4.3.2.2.1. Poor isolation
4.3.2.2.2. Poor visibility
4.3.2.2.3. Difficult to limit resource utilization
4.3.2.2.4. Risk of dependency version conflicts
4.3.2.2.5. Poor encapsulation of implementation technolgy
4.3.3. Service per VM
4.3.3.1. Benefits
4.3.3.1.1. Great isolation
4.3.3.1.2. Great manageability
4.3.3.1.3. VM encapsulates implementation technology
4.3.3.1.4. Leverage cloud infra for autoscaling/load balancing
4.3.3.2. Drawbacks
4.3.3.2.1. Less efficient resource utilization
4.3.3.2.2. Slow deployment
4.3.4. Service per container
4.3.4.1. Benefits
4.3.4.1.1. Great isolation
4.3.4.1.2. Great manageability
4.3.4.1.3. Container encapsulates implementation tech
4.3.4.1.4. Efficient resource utilization
4.3.4.1.5. Fast deployment
4.3.4.2. Drawbacks
4.3.4.2.1. Immature infra for deploying containers
4.3.4.2.2. Containers are not as secure as VMs
5. Monolithic
5.1. Simple to...
5.1.1. Develop
5.1.2. Test
5.1.3. Deploy
5.1.4. Scale
5.2. Long-term commitment to a tech stack
5.3. Successful applications have a habit of growing <=> big, complex monolithic apps
5.3.1. Not so simple anymore
5.3.2. Overloads your IDE and development
5.3.3. Agile dev and deployment becomes impossible
6. Why?
6.1. What's the deployment architecture?
6.2. Business must innovate faster <=> develop more complex higher-quality software faster
6.3. Benefits
6.3.1. Smaller, simpler apps
6.3.2. Scales development: develop, deploy, scale independently
6.3.3. Improve fault isolation
6.3.4. Eliminates long-term commitment to a single tech stack
6.4. Drawbacks
6.4.1. Complexity of developing a distributed system
6.4.2. Multiple DBs & transaction management
6.4.3. Complexity of testing a distributed system
6.4.3.1. Fred George - different approach
6.4.4. Complexity of deploying and operating a distributed system
6.4.5. Developing and deploying features that span multiple services requires careful coordination
7. Chassis
7.1. Cross-cutting concerns
7.1.1. Time consuming
7.1.2. External configs
7.1.3. Logging
7.1.4. Service discovery
7.1.5. Circuit breakers
7.1.6. Health checks
7.1.7. Metrics
7.2. Framework that simplifies the initial setup
7.2.1. Spring Boot + Sprint Cloud
7.2.2. Dropwizard
8. Event-driven
8.1. Forces
8.1.1. Update data owned by multiple services
8.1.2. Join data owned by multiple services
8.1.3. Different storage requirements between services
8.1.4. DBs replicated and sharded for scalability
8.1.5. Loosely coupled services
8.2. Shared database
8.2.1. Benefits
8.2.1.1. Easier operationally
8.2.1.2. Local transactions only
8.2.2. Drawbacks
8.2.2.1. Lack of encapsulation
8.2.2.2. Single DB might not satisfy data reqs of multiple services
8.3. DB per service
8.3.1. Schema updates
8.3.2. Multi data center, distributed DB
8.3.3. Scalable
8.3.4. Approaches
8.3.4.1. Private tables
8.3.4.2. Private schema
8.3.4.3. Private DB server
8.3.5. Benefits
8.3.5.1. Loosely coupled
8.3.5.2. Scale DB per service needs
8.3.6. Drawbacks
8.3.6.1. Transactions and queries through multiple services
8.3.6.2. Complexity to operate
8.4. Problems
8.4.1. Eventually consistent business logic?
8.4.2. Atomically update database and publish an event?
8.5. Options
8.5.1. Update and publish using 2PC
8.5.2. Transaction log tailing
8.5.2.1. Benefits
8.5.2.1.1. No 2PC
8.5.2.1.2. No application changes needed
8.5.2.1.3. Guaranteed to be accured
8.5.2.2. Drawbacks
8.5.2.2.1. DB specific
8.5.2.2.2. Immature
8.5.2.2.3. Low level DB changes
8.5.3. Application created events
8.5.3.1. Benefits
8.5.3.1.1. High level domain events
8.5.3.1.2. No 2PC
8.5.3.2. Drawbacks
8.5.3.2.1. Requires changes to the application
8.5.3.2.2. Only works for SQL and some NoSQL DBs
8.5.3.2.3. Error prone
8.5.4. Event sourcing
8.5.4.1. Identify domain events
8.5.4.2. Define Event classes
8.5.4.3. Persists events NOT current state
8.5.4.4. Replay events to recreate state
8.5.4.5. Benefits
8.5.4.6. Drawbacks
9. Migrate from monolith
9.1. A Big Bang rewrite
9.2. Incremental rewrite
9.2.1. Stop digging
9.2.1.1. New functionality as standalone service
9.2.2. Split front-end and back-end
9.2.3. Extract services