Building Microservices by decreasing Entropy and increasing Negentropy - Series Part 5

Microservice’s journey is all about gradually overhaul, every time you make a change you need to keep the system in a better state or the state that it was before.

Moving out of Services can happen either Vertically or Horizontally. Clearly nail down those horizontal services that need to be common overall. Try to identify those vertical services and the best way typically are to migrate them by first moving the data, then the business logic and later the front end.

Always try to target the first step as is to create a macro service until the core services are demarcated. Once the demarcations are clear it is easy to further split into microservices.

In the beginning, the teams have less operational maturity, during this phase minimize the number of microservices and reduce the cognitive load.

The simplest of services, to begin with, in my experience are read-only applications. Especially, the ones that are business-centric and that change very often. This allowed us getting the business team’s confidence that the teams can move faster and deliver those features rapidly.

The team that I was part of initially were depending a lot on the monolith application. The services were deployed multiple times a day, whereas the monolith application was deployed once a week. The services should never wait for the monolith to be deployed.

Also, every time changes went into the monolith, it was always ensured that there were feature flags. This gave the developers the leeway to revert and test changes if in case hell broke loose.

Do not add a dependency to the monolithic platform. Ensure that the new services do not call the monolithic application directly and always access it via the anti-corruption layer.

Concluding Thoughts

A microservice journey is complex and seldom have organizations been successful. And if you have gone ahead and started that journey, do take intermittent checks on where you stand and correlate to where you started from.

• If after building services you are in a situation where all developers congregate to fix production issues
• if teams require several developers and take umpteen number of days to fix issues
• If your applications have several hours of downtime
• If your services cannot be tested as a single entity
• If the teams fear to make changes to the code when adding new features
• If you are reverting code and releases instead of failing fast or failing forward
• If you are building services that access the same database
• If the services and functionality is spread across multiple services and teams
• If your applications take multiple teams and several people to deploy changes to production
• If there are too many services depending on each other
• If your teams are still writing and performing manual tests
• If you are building services with hundred of Classes having hundreds of lines of code
• If you have several services that have not been modified for several months

Maybe, you have ended up building another monolith.