The technical decisions of engineers in microservices migrations

Decision-making is central in designing Microservices-based software, and software engineers have several key choices to make when transitioning to microservices. The key decisions in microservices migrations can be: 1) business-related, 2) technical, and/or 3) organizational. These three dimensions of microservices migrations decision-making process are identified and further described in a study co-authored a while ago, aggregating the microservices migration experiences of 16 organizations of various sizes worldwide. Below i discuss some of the key technical and architectural decisions that engineers make in microservices migrations.

Grand architectural decisions

On the one hand, some of the technical decisions are about the technical governance of the migration. For example, a decision on the migration strategy typically needs to be made. The first alternative of this decision is to migrate on a big bang, after redesigning and redeveloping the software from scratch, on a separate greenfield application, following the principles of delivering a microservices-based architecture. The second alternative is to gradually evolve the architecture, bringing it gradually closer to microservices. This can happen by 1) decomposing parts of the system, 2) maintaining a part of the system as a big, monolithic service and develop as a microservice every new feature, and 3) combine the 2 aforementioned approaches. Naturally, the grand architectural decisions have different consequences and influence all subsequent decisions.

Specific technical design choices

On the other hand, some of the technical decisions are specific technical design choices, that are influenced by the grand architectural decisions. For example, a subsequent decision is to chose how legacy code is reused and what is carried over (libraries, design models, source code). Another technical design choice is how such technical artifacts are carried over: are we allowing shared libraries or do we only create services with end-points and APIs? When services have started to be created, decisions need to be made on the granularity and how small or big the developed services can be.

So, where does this leave us? Grand architectural decisions influence specific technical design choices. Therefore, a dialogue and understanding between the 2 levels of abstraction is needed. Furthermore, even very technical decisions do require strong alignment and drive from the business and organizational side to actually happen.