Mindmap with the ideas from the talk Chris Richardson (@crichardson) gave at Jfokus 2016 on 8th of Feb 2016

Get Started. It's Free
or sign up with your email address
Rocket clouds
Microservices by Mind Map: Microservices

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 Benefits Drawbacks Issues to resolve

1.1.7. Related patterns Alternative solutions 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 Goals Separate components with conflicting resource reqs => scale more easily 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 Parallelise development and deployment Partition by noun (Catalog service) Partition by verb (Checkout UI) Partition by subdomain Single responsibility principle (Bob Martin) Do one focussed thing well (unix utilities)

4.2.2. How to enforce consistency without 2PC?

4.2.3. How many services? Too few Drawbacks of monolithic architecture Too many Runtime overhead Risk of excessive network hops Potentially difficult to understand system

4.2.4. Anti-pattern: distributed monolith

4.3. Deployment

4.3.1. Forces Cost-effective Reliable Isolated service instances Independently Building and deploying must be fast Services are written with many techs

4.3.2. Multiple service instances per host Benefits Efficient resource utilization Fast deployment Drawbacks Poor isolation Poor visibility Difficult to limit resource utilization Risk of dependency version conflicts Poor encapsulation of implementation technolgy

4.3.3. Service per VM Benefits Great isolation Great manageability VM encapsulates implementation technology Leverage cloud infra for autoscaling/load balancing Drawbacks Less efficient resource utilization Slow deployment

4.3.4. Service per container Benefits Great isolation Great manageability Container encapsulates implementation tech Efficient resource utilization Fast deployment Drawbacks Immature infra for deploying containers 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 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 Easier operationally Local transactions only

8.2.2. Drawbacks Lack of encapsulation 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 Private tables Private schema Private DB server

8.3.5. Benefits Loosely coupled Scale DB per service needs

8.3.6. Drawbacks Transactions and queries through multiple services 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 Benefits No 2PC No application changes needed Guaranteed to be accured Drawbacks DB specific Immature Low level DB changes

8.5.3. Application created events Benefits High level domain events No 2PC Drawbacks Requires changes to the application Only works for SQL and some NoSQL DBs Error prone

8.5.4. Event sourcing Identify domain events Define Event classes Persists events NOT current state Replay events to recreate state Benefits Drawbacks

9. Migrate from monolith

9.1. A Big Bang rewrite

9.2. Incremental rewrite

9.2.1. Stop digging New functionality as standalone service

9.2.2. Split front-end and back-end

9.2.3. Extract services