Monolith to Microservices: Background Transformation
Recently, most of the big companies are moving from monolith architecture to microservices architecture. Some of them take this decision as a result of detailed technical analysis in line with their needs, and some of them switch to this structure because it is popular and to attract software developers. In one way or another, although the microservice architecture is the right decision for the infrastructure, the real problem begins after that.
In this article, we will examine the main reasons for transformations that have been converted to microservices architecture for various (right or wrong) reasons and have not completed their transformation or failed.
As you know, 12factorapp is considered as defacto reference for microservices architecture, and it tells what to do and what not to do in 12 steps. Let’s examine what has not been done in companies and, accordingly, why the transformations have not been completed or failed.
Moving to microservices architecture does not mean just separating APIs according to their domains or the work they do(business). In the background, it is also necessary to change company’s behaviors and habits. Many companies technically have no problem separating their services, but they do have a lot of trouble changing their behavior and habits.
These habits and behaviors over time treat the microservices like a monolith and turn the system into a distributed monolith.
Let’s examine them under a few headings;
Devops Concept:
Today, devops has a very important place in the changing and transforming software industry. Transforming companies recruit system admins from old monolith builds as devops engineers/developers to fill this gap. There is no problem with this approach, the problem is that devops engineers/developers approach microservices like monoliths
For example, in monolith structures, the developments are completed, the deployment package itself or reference’ is given to the system admin and the deploment takes place. We should not do the same approach when developing microservices. This directly lowers the continues delivery and goes against clause 5 of the 12factorapp, Build, release, run. According to 12factorapp, deployment can be made at anytime. Or if a software developer is needed to intervene when a problem occurs, this also prolongs the solution of the problem. The source of this and many similar problems are habits and behaviors.
Common approaches in the world as solutions are;
1. devops and software developer to deploy together
2. Deployment by the software development team (engineer or qa + engineer). The principle underlying this approach is the following.
“You build it you run it”
Release Management:
In monolith structures, ITIL or equivalent frameworks are mostly applied. It is very, very wrong to control the deployment of microservices as in monolith structures. This approach both slows down continues delivery and contradicts a few steps of 12factorapp. Especially for a simple deployment, meeting for hours and talking or emailing slows things down. However, the job itself does not take as long as this procedure.
I would like to share with you a situation that I encountered and could not understand. For a few service deployments, I told the release management team (test team, not qa!) that our local tests were not finished and we wanted to deploy the packages tomorrow. The answer I got was: “We can’t do deployment every day. Today is Deployment day.” If you get such an answer when you want to deployment in a company working with microservices architecture, please escape from that company without looking back :)
In a company working with Microservices architecture, there is no such thing as a deployment day, there cannot be, there shouldn’t be.
Standards and Rules:
There is only one standard, one rule in Microservices architecture; whatever the need is, that’s the standard(rule), need = standart(rule). There are generally such approaches/habits in companies. We just use kafka or we just use couchbase. The habit of standardizing/regulating everything in companies is a very dangerous situation to compete in today’s software industry. Therefore, it is necessary to be flexible in the selection of technology according to the needs. In addition, tool addiction or parent pom love also negatively affects companies.
Organization and Culture:
“Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.”
Melvin E. Conway
One of the most important structure and parameters in a company is its organizational culture. If you are a big company (I want to emphasize, not small or medium-sized), vertically structured organization is the source of most problems. What I mean by vertically structured organization is that; is to be divided into teams such as software development, testing, po, etc. In such cases, no one working on the product can fully focus on the product, whether it is a monolith or microservices architecture. In a structure where the software teams consist only of software developers, and the qa and po teams are separate, chaos always prevails. Neither product owners nor testers can have full knowledge of the product that is the output of the software. Especially in companies working with microservices architecture, software developer, qa and po should be in the same team in software teams (the same may not be the case for devops and dba).
In teams that do not have this structure, the po team does not own the product (using user journeys as an excuse), the tester does not know what to test, and the software developer has to make decisions that are not his/her responsibility. Nobody owns the product because there is no team consciousness. Since the features running in the background(for monoliths) in the microservices architecture are now divided into APIs, more information should be obtained. This organizational problem may cause a toxic culture to form in the company over time. To avoid such situations, all components of the team must know all the features of each new API to be created.
Under a few titles, I tried to explain the problems that occur in companies that transform. I hope it was useful.
Have fun..
