Refactoring a monolith to microservices: understanding your AS-IS state
The first step of any architecture modernization effort is to understand what problems need to be solved. It’s especially important to do so when adopting microservices in order to avoid the Microservices are a magic pixie dust anti-pattern. This all to common anti-pattern occurs when an organizations thinks that microservices are the cure all for all software development problems. It is possible, for example, that software delivery is slowed down by process and organization problems - not architecture issues. It’s essential, therefore, to understand the problems and current architecture in order to determine what needs to be done.
Moreover, while you might expect that the AS-IS architecture is well understood, this is often not the case. When an application is very large or very old, the situation is reminiscent of the parable of the blind men and the elephant. Each team only understands their part of the application. There’s not a shared understanding of the overall architecture. As a result, we often need to engage in software archaeology to understand the AS-IS architecture.
Let’s first look at how to understand and document the AS-IS architecture. After that I’ll describe how to identify the problems that need to be solved.