Microservices from the Trenches – Talk

The book Facilitating Technical Events is for technical trainers, coaches, events organizers who want to have a good event flow and happy attendees.
Support independent publishing: Buy this e-book on Lulu.

Microservices are a hype. It made programmers more aware of methods to modularise large monolithic systems, because of stricter component boundaries.

Microservices from the Trenches

Strategy vs Tactics

While strategy needs to focus on all the high level concerns, tactics are the means of putting in place all the ideas from the strategy. Therefore architecture needs to be about strategy, and tactics about all the rest: coding, testing, operations, etc.

When an strategist (architect) doesn’t connect with the tacticians (product, programmer, tester, devops, security, etc), the strategy doesn’t make any sense and the tacticians lose faith in the strategy, changing it as they see fit. And sometimes the architects find very late that the architecture is not as they thought. We call these ivory tower architects. They are the architects that throw documentation and say “do this”.

In order to have good architecture we need to have a continuous sync between architecture (strategy) and implementation (tactics)

Microservices are a tool

It’s not a silver bullet. There is no recipe.

But it’s ok to have guidelines. It’s good for:

  • Parallel work, with fast time to market
  • Non-homogenous set of programming languages
  • Increase scalability
  • Parallel versioning
  • Self-contained systems
  • Self-healing systems

It’s not good when:

  • The boss wants the new hype
  • There is not need to scale
  • Only one portion of the monolith needs to scale
  • The team is not proficient enough in architecting and domain modelling
  • There is not enough organizational support for a paradigm change

Domain Modelling

My advice is to always start with domain modelling. A Domain Modelling Kata might help you. Most importantly don’t imagine you can do it well from the beginning. Make your first iteration, then delete it and start all over the next day. Delete it again and start over again. Maybe the third version is more or less close to reality.

Don’t do domain modelling only with architects. Invite all the roles: product, testing, ops, programming, security, marketing, etc.

Start with the architecture change that has most impact and then see if you are going in the right direction. Iterate on your domain. Iterate on your strategy. It will never be perfect, or even too good, from the beginning.


You can find the slides from my talk below:

Video (Romanian)

Check the video of my talk at Cloud Native Computing Bucharest , if you know Romanian: https://www.youtube.com/watch?v=k8QZkkWM6Wg

Other resources

My #RemotePairProgramming series here

My Legacy Code series here

Image by David Mark from Pixabay


If you want to receive an email when I write a new article, subscribe here:

Subscribe for new articles

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Subscribe for new articles