kentoh - Fotolia

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