The buzz around microservices, according to a quote cited by Red Hat’s senior manager John Frizelle, is much like teen dating. You don’t know what you’re getting into, but you know you want to do it anyway.

Microservices and the requisite architecture offer many benefits to organizations in terms of application flexibility and maintenance. But if you go into it blindly, you risk adding complexity to your IT organization that will create more challenges than microservices can spare you from.

Frizelle spoke yesterday at the second day of the Red Hat Summit in Boston, and listed eight challenges organizations face when moving to a microservices architecture.

The first is building a microservice. When one service goes through a build, it may need to trigger other builds. So it’s important, he said, to identify dependencies between services. From a broader business perspective, it’s important to know what versions of which services constitutes a release, so you’re continuously providing value to your customers.

The next challenge is testing, he said.  For unit testing, there is no change between testing a microservice and testing a monolithic application. Again, dependencies need to be considered. But for testing a microservice, boundaries must be drawn around that service; otherwise you could be drawn into testing more of the application than you need to just to confirm the service does what it is built to do. Frizelle said to stand up the service before and the service after the service you’re testing, and you can mock the rest of it. For testing the end-to-end system, it’s important to stand up the entire system, so you can identify the root cause of problems. “A fail in service D could be caused by a change in a service several hops away,” he explained.

The next challenge is versioning. Frizelle suggested versioning public APIs and the APIs of the internal microservices. When versioning is in place, it’s important to think about updating. “If you update a service with dependencies, you have to figure out how to maintain backwards compatibility,” he said. One way to skirt that issue is to create multiple versions of services for different clients, but that can create management problems, he said. If you have, say 250 services with three versions of each service to accommodate different clients, you’re actually managing 750 services. He suggested that organizations find consensus on the approach to take.

Then comes deployment. In systems with big numbers of services, the complexity requires automation. “Humans will introduce human error in systems that are too complex,” Frizelle said. The administrator, he said, “would quickly go mad.”

With microservices, it’s important to determine how and when to roll out the services, and in what order, based on their dependencies. He suggested trying blue-green deployments, where 10 percent of users get the new version and 90 percent get the old. “Then,” he said,  “you can see what worked, and decide when to roll back or roll out.”

Logging, monitoring, debugging and connectivity present more issues, Frizelle continued. Logging, he pointed out,  “is impossible to manage without centralization. You need to bring the logs of all services together to get a consolidated view of what’s happening.” One way of doing this is to use global request IDs. The ID travels with the request across all the hops of various services. An admin can simply put the request ID into a console to what happened with that service across its activity.

For monitoring, Frizelle said to consider distributed request tracing. “If a service is slow, or not responding, you need a visual view of the system to understand” what is bottlenecking, where it’s occurring , and why.

In large systems with hundreds of services, remote debugging is not an option, because you can’t connect to hundreds of services at once, though Frizelle did say the tooling is evolving in this space. Organizations should look at which particular services are most critical, and use remote debugging on those.

One of underlying tenets of microservices is that each service runs in its own isolated process. If that is the case, how do they find each other to connect? Frizelle said that a form of service discovery is required, because “you don’t want to hard code URLs” to find services. Instead, he suggested using etcd, a centralized service discovery solution.

Another way of ensuring applications work as they should is to employ a circuit breaker, which will end a request if the response is taking too long, opening up that thread and reporting it to the log for remediation.

Frizelle urged organizations to not get caught up in the microservices hype. “Make sure you understand why you’re doing microservices, and make sure you’re doing it for the right reasons.” A move to microservices, he said, will likely require an agile transformation. “Micro teams build microservices,” he said.

Microservices don’t eliminate complexity, he said. The eight challenges he listed are elements of the hidden complexities of creating a microservices architecture. To get the benefits of microservices, you need to take those challenges into account, and plan for them up front.