Raw notes from Zhamak Dehghanil.

Getting to Microservices is a journey. Looking for scale, get more capabilities, experimenting with improvements to their core business, not just AB testing.

Nice simple image of a journey down the hill through the valley, and up the hill.

Deconstruct the monolith, unlock business capabilities.

Overview of microservices ecosystem.

1. Monolithic, 2. intelligently integrated, 3. layered, web app, 4. centrally integrated, 5. Microservices, 6. Microservices ecosystem on a platform.

This timeline makes me think about step 7. Perhaps when the microservices leave the enterprise and can be sold as standalone services?

Microservices around business capabilities. API as a product, the fabric of integration. Independently releaseable. Teams aligned with services. Built on a self-served platform.

Monolith Evolution: The Battle

1. Identify most constraining

Decouple the most constraining factor early. The Knot. Apply the theory of constraints, as a chain is no stronger than its weakest link. For example. A monolith that makes heavy use of session. Need to find out what is the logical meaning of those things. Use structural analysis tool.

2. Decouple capability, not code

The cost of reusing compared to its value is often underestimated. It might be worth re-writing. Use toxcicity evaluation tool.

3. Decouple what matters

Decouple the capability that is lively, being used... use code analysis tool such as CodeScene for finding lively components.

4. Decouple vertically, release the data early

Apply the first principle of microservices: independence of build and operation. Because each microservice is self contained, including state, you need to extract full stack.

the anti-patterns: only decouple facade, only decouple backend services, never decouple data.

5. Minimize dependency back to monolith

When you extract, don't go back to the monolith. Tool: expose API from monolith. Use anti-corruption layer in service to use monolith.

6. Go Macro first then go Micro

Recognize that operating a large number of small services requires higher maturity. Must walk before running. Give yourself time to acquire those skills. Tool: use hyperlinks to logical resources within or outside the physical service boundary. HATEOAS: The apps can return links that initially point back to oneself, but then can be changed to point to other services, and the clients will not notice the transition.

7. Migrate in atomic steps of architecture evolution, not devolution

Make sure that every step takes you closer to your goal. Sometimes take a small step, sometimes take a large leap. Tool: decouple, redirect, retire.

The climb

Start with a clear outcome in mind. Define a fitness function. Experiment speed, security, throughput. Radar chart.

Hypothesize and measure. Identify metrics. For example, measure number of applications built with the API, how quickly you can create new APIs.

Enable with a self-service platform: Domain API, Data infrastructure, Delivery Infrastructure.

Trade-offs instead of solutions. "There are no solutions only tradeoffs" — Thomas Sowell. See also Reality is Not Optional: Thomas Sowell's Vision of Man and Society. Reuse vs. Build vs. Buy vs. Re-write.

Align organization: How is the funding.