BT

InfoQ Homepage News Reasons for Cancelling a Move to Microservices

Reasons for Cancelling a Move to Microservices

Leia em português

Bookmarks

During a period in which Steven Lemon and his team had less features to implement, the technical leadership at the company he was working for decided to move their existing monolith into a microservices architecture. After a month of preparation, they realized that microservices would be hurting their development process without bringing any benefits. This surprised them but they decided to stay with the monolith, and Lemon recently wrote a case study of their findings.

Their application was working on top of an external third-party product with a set of back end services in between handling transformations between the two parts. An important reason for their difficulties in moving to microservices was that there was a mismatch between the domains in their own application and the domains in the external product. This mismatch had an impact on how their domain could be split into microservices. Letting their microservices follow the domains in the external product would cause duplication of logic across the microservices. With the microservices following their own domains, they would have to communicate with two or more domains in the third-party product. Both ways seemed for the team as a violation of microservices guidelines and leading to an increased coupling.

When they started looking into ways of splitting the monolith, they couldn’t find any obvious microservice candidates. They therefore started to arbitrarily split their domain models, which created a list of potential microservices but also a lot of shared business logic and coupling. They tried to mitigate this by dividing their services into even smaller parts, but that just increased the problems.

Lemon notes though that the main reason for failing to divide the monolith was that it only dealt with one single business concern. It was from the beginning designed to bring together disparate concepts from the external product, something they had been working on for years. They had underestimated the importance of finding the right boundaries, with the result that each feature in the application would be touching more than one microservice. In the end, this prevented any microservice from being owned by one team.

Another problem was that they didn’t have a platform ready for running microservices, and this complicated the communication between services. Their solution was to duplicate shared logic and common reads from storage, which removed the need for communication but created a significant amount of duplication.

They were also facing frequent requirement changes, making it hard to find the proper domain separations. What was fine one day could be overthrown a few months later, requiring another set of microservices. They also had a fairly short time frame, preventing them from reflecting over the design choices made, and the team lacked experience from previous work implementing a microservices architecture.

As the problems piled up, they started to realize that they didn’t know why they were trying to migrate to microservices. They lacked a list of pain points and didn’t understand how all the work would mitigate the pain points they did know about. Realizing this, they paused and looked into what benefits microservices commonly provide and which of these that would actually be beneficial to them.

With the architecture they already had and because of the compromises they would have to make in a move to microservices, they would end up with a pool of microservices shared by all teams and features spread over multiple microservices. This was a major disadvantage which prevented many of the common benefits with microservices.

Lemon also points out that there were a lot of infrastructure concerns already solved in their monolith that would have to be addressed again. When looking at their monolith, he notes that they had very few issues. It was straightforward to work with and had a CI/CD setup simplifying deploy and rollback. Their branching and testing strategies ensured that very few issues made it into production.

In the end, they realized that a monolith isn’t automatically something bad and microservices always something good. The move to microservices was cancelled, and they instead started to look at ways they could improve the monolith. They refactored the structure which made the domain models clearer and indicated areas where coupling and duplication existed. In the end, this also meant in the future they could more easily find candidates for microservices if the need arised.

A discussion emerged on reddit after Lemon’s blog post with currently over 300 comments about monoliths versus microservices; when each is a good fit, how team sizes can affect the choice, size of microservices, and ways of scaling a monolith to mitigate some of the problems that otherwise would point towards a microservices architecture.

Rate this Article

Adoption
Style

Educational Content

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • Moving to microservices

    by Armen Arzumanyan /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Architectural changes are not easy task. You should have business needs, time, team and Chief architect. No any architect will approve product changes if no any platform, experienced dev team, senior devops. Also you should note what technologies stack must be the similar which has your monolith application(java-to java). And in reality it is new application development....

  • Discussion on reddit after Lemon's blog post

    by Jan Stenberg /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I've added a short summary and a link to a discussion on reddit that followed Lemon's blog post.

  • Upfront architectural vision with a reasoning behind

    by Patrick P. /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I was wondering when I read this part of the article:

    ‚they didn’t know why they were trying to migrate to microservices. They lacked a list of pain points and didn’t understand how all the work would mitigate the pain points they did know about. Realizing this, they paused and looked into what benefits microservices commonly provide‘

    This suggests that instead of making an architectural decision with a reasoning, the people in charge have just followed a trend / buzzword.

  • Re: Upfront architectural vision with a reasoning behind

    by Jan Stenberg /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Yes, and in my experience that is quite common among all involved in system development. I've met developers in small teams with small systems that still want to use microservices. One argument is that they want to learn and get experience from implementing them.
    No so surprising really, looking at all fuzz about how bad monoliths are and how fantastic microservices are. Fortunately more and more voices argues for a monolith in most cases, and microservices only when there is a clear need for a distributed system. In InfoQ's Architecture and Design InfoQ Trends Report - January 2019 we have "Correctly built distributed systems" for early adopters.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT

Is your profile up-to-date? Please take a moment to review and update.

Note: If updating/changing your email, a validation request will be sent

Company name:
Company role:
Company size:
Country/Zone:
State/Province/Region:
You will be sent an email to validate the new email address. This pop-up will close itself in a few moments.