This content is part of the Essential Guide: A DevOps tutorial on migrating to microservices
News Stay informed about the latest enterprise technology news and product updates.

How to avoid common challenges when migrating to microservices

Hear advice from API World 2017 speakers and an IT analyst about avoiding the most common technology-related microservices migration mistakes.

SAN JOSE, Calif. -- Migrating to microservices calls for a significant technology transformation, according to speakers at this week's API World 2017. In this article, two microservices experts -- Irakli Nadareishvili and Chris Tozzi -- expose and offer advice about two common technical microservices challenges.

"Understanding how to build a microservice architecture can be painful, just like any other significant transformation can," said Nadareishvili, senior director of technology at Capital One, based in McLean, Va., in a preconference interview. He elaborated during his API World 2017 session, "Implementing microservices at Capital One."

Nadareishvilli and Tozzi offer alternatives for the two most common technical mistakes in migrating to microservices: not properly decoupling a distributed system and not resizing microservices. Tozzi is a DevOps analyst for Fixate IO in Livermore, Calif.

Technical challenge No. 1: Not loosely coupling

Irakli Nadareishvili, Capital One senior director of technologyIrakli Nadareishvili

Rather than building a microservices architecture, Nadareishvili has seen companies creating a distributed monolith, in which the organization can't change one service without affecting another. This goes against the grain of the microservices architecture, which should reduce coordination between systems.

In this worst-case scenario, Tozzi noted, the organization must run and manage applications that are deployed as distinct services, but in which those services remain interdependent. "For example, you might have a front-end service that only works if it can connect to a database that is configured in a certain way," he explained. That database, in turn, expects the front-end service to be configured in a particular way. "If you're not distributing apps into independent services, you might as well still be running a monolith."

Chris Tozzi, DevOps analyst for Fixate IOChris Tozzi

Nadareishvili recommended using his Rule of Twos to avoid coupling in certain scenarios as one way to avoid creating distributed monoliths. This practice calls for making sure the infrastructure supports at least two alternatives for a critical component.

Always think "loose coupling" when migrating to microservices, and don't cling to the SOA model, Tozzi said. "The best way to avoid the distributed monolith anti-pattern is to ensure that each microservice in your application can start and run independently of others," he said. "The configuration for each service should also be self-contained and able to be modified without affecting other services or apps."

Microservices challenge No. 2: Right-sizing

In his work with DevOps teams, Nadareishvili said he sees them struggling with how to right-size microservices. They're often not sure of how micro a microservice should be.

One option, Nadareishvili said, is using the domain-driven design (DDD) bounded contexts as the sizing guide. There are, however, two major problems with this approach:

  • Sizing microservices with DDD only works at early stages. This means the perfect size of a microservice doesn't exist. The right size of a microservice is a function of time; the size decreases over time. "As teams mature in their practice of microservices and the understanding of their problem domain, larger microservices usually split and overall granularity increases," Nadareishvili explained.
  • Even at the early stages, using formal DDD is hard. It requires some expertise and experience. "I've met many more teams that were aware of DDD than teams that were actually practicing it," Nadareishvili said. "And I believe the reason is complexity of formal [and] conventional DDD analysis."
If you're not distributing apps into independent services, you might as well still be running a monolith.
Chris TozziDevOps analyst, Fixate IO

Nadareishvili recommended using bounded contexts for the initial sizing of microservices. Beyond that, he said, use a group modeling technique, event storming, for discovering them instead of more traditional DDD approaches. "I am a big fan of event storming both for microservices, as well as in general for understanding a domain," Nadareishvili said. He recommended it for any style of architecture. "It brings unparalleled understanding of the problem domain shared between product owners and tech teams."

One tricky part of using event storming is the final artifact is impossible to capture in any reasonable way. The final artifact, Nadareishvili said, is very long strips of paper with hundreds of "stickies" on them. When his team goes through an event-storming exercise, he uses the Microservices Design Canvas from API Academy for capturing the final design. This tool is used to identify the desired attributes of a service before it is developed. "These two tools in combination work really well for us," he said.

Microservices challenges bottom line: Reduce coordination

Always pay attention to what causes coordination in your system, the experts said. Finding and removing those couplings will speed the migration to microservices. "Microservice architecture is primarily about reducing coordination needs," Nadareishvili concluded. "Everything else is largely secondary."

Next Steps

Right-sizing is just one microservices challenge

Learn more about microservices mistakes that developers may miss

Discover some of the most common technology challenges in microservices

Dig Deeper on Application performance management and testing

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

Which technical issues are your biggest challenges when migrating to microservices?
I think the principles of SOA laid out by Thomas Erl (SOA books) and subsequently the additional principles of deployability, domain-driven-functional autonomy, high-availability, and continuous integration for each deployable microservices are well documented by multiple authors. Tools are also available. What I see challenging is the team's ability to quickly grasp the concepts and come up with the right design in short time. Adopting microservices leads the larger efforts, but time to market is reducing. This has led to speedy design that is often governed less and results in not-so-good microservice design.
Unfortunately, channukambalyal, your information is incorrect. The concept and principles of SOA where defined in 1995/96, not by T. Earl. He articulated them in his first wrong book, where he insisted that Web Services = Services (wile all know that Web Service were just an adaptation of CORBA IDL - interface language). He wrote a cople more books in the same way and finally started to right more books to fix that totall mess he caused, but it was too late. In 2009, his "services" or Technology SOA was proclaimed dead. The real SOA Principles, free from technology marketing, may be found in "Updated Principles of Service Orientation" at .
channukambalyal, the major problem staying with Microservices (in contrast to real Services by the OASIS SOA RAF specification) is that developers still do not understand that the Service (Microservice?) provider has no liability to the consumer id this provider belongs to another deprtment or even another company. The Microservice consumer is totally safeless and helpless in front of the provider who can do whatever it is pleased with the information sent to it via
Microservice's interface.

Thus, until this problem is not resolved, Microservices are usefull (can be approved by business) only for the internal household usage. The same relates to the popular API - both of them are the trap for your business organisation and you do it only becuase your CEO does not know about this.
Reaging this article about Microservices I  have found with a pleasire that nothing has changes , nothing was learnt in Web/Microservices since 2001 JavaOne when WS were first introduced. I do like this becuase I still pompetent and competitive. SInce I participated in OASIS SOA RAF standard 5 years, I know even more than modern Microservice Experts. Developers have proved they think by hands while the rest of people think by heads. This is the problem with IT.
- Michael Poulin
  Head of EA, Clingstone Ltd.