I got Sam Newman’s new book ‘Monolith to Microservices’ in my handy and scribbled down a few notes that I found worth extracting. This is by no means a full book summary - which indeed is difficult to a book that already is a summary on the topic.

Handy definitions

I like Sam’s microservice definition: “Microservices are independently deployable services modeled around a business domain. The desire for loosely coupled services with stable interfaces guides our thinking about how we find service boundaries in the first place. We want to think of our services as end-to-end slices of business functionality, that where appropriate encapsulate the UI, application logic, and data storage.” Their interface should be as small as possible.

Why to decompose the Monolith after all?

Sam highlights the importance to have a very good reason to trade-in the complexity of a monolith against the complexity of a distributed system.

A few of the advantages that microservices can deliver are said to be: - they play well together with poly-skilled teams and reduce to bust silos and reduce hand-offs - the help to scale and build robust software - mixing and matching technologies becomes easier - they help if a bigger number of developers needs to work on the code - microservices can be easier to understand (although I have my doubts on that argument) - they allow for a great degree of flexibility

Typical reasons for adoption of Microservices

Typically people expect one or more of these good things to happen: - Improvement of team autonomy - Reduced time-to-market - Cost-effective scaling of parts of the system for a certain load pattern - Improved robustness - Scaling up the number of developers working on the code base at high productivity - An easier introduction of new technologies that help the business

When to avoid Microservices

When you’re working in an unclear domain or in an early startup phase: that’s definitely not the time to use microservices.

It’s also worth noting that many organizations are just off very well by using a structured monolith and avoid the complexity of microservices.

How to introduce microservices?

Sam refers to “Dr. John Kotter’s eight step process for organizational change” as a framework for microservice introduction in bigger companies. The process steps consist of:

1. Establish a sense of urgency
2. Creating the guiding coalition
3. Developing a vision and strategy
4. Communicating the change vision
5. Empowering employees for brad-based action
6. Generating short-term wins
7. Consolidating gains and producing more change
8. Anchoring new approaches in the culture

Practical steps / Practical tips for getting started

• Coming up with a domain model is near-essential
• The domain model just needs to be good enough to make reasonable first decisions about decomposition
• Aligning the architecture and organization can be key to getting the most out of a microservice architecture
• Have regular checkpoints on whether you’re moving towards the original goals and try to make things measurable
• Be prepared that introducing a change to how things are done usually affects productivity in a negative way first before things speed up working in the new way. That’s another strong argument for doing small steps
• It makes sense to first restructure and refactor the monolith internally. The key is to ensure you’re rewriting only small pieces of functionality at a time
• In general, try to avoid to change architecture and functionality at the same time if the ability to roll back sounds important to you

Migration patterns

The bigger chunk of the book is about specific migration patterns an techniques. I don’t want to go in any detail here and just list them as they are presented in the book:

Migration patterns:

• Strangler pattern
• UI Composition
• Branch by abstraction
• Parallel run
• Decorating Collaborator
• Change data capture

Decomposing the database patterns:

• The shared database
• Database view
• Database-as-a-Service interface
• Aggregate exposing monolith
• Change data ownership
• Synchronize data in application
• Tracer Write

Splitting the database first is unlikely to yield much short-term benefits and thus might not be an ideal strategy.