Source – techtarget.com
What can go wrong when a business is migrating to microservices? Plenty. Microservices implementations often derail due to poor planning and lack of self-evaluation, said digital transformation expert Eric Roch. And that preparation is just stage one. Implementing microservices calls for new methods of rewarding DevOps and business teams and handling technical areas, like change management and breaking down dependencies.
“I clearly see that a lot of companies aren’t ready for microservices,” said Roch, principal architect and practice director for IT modernization at Perficient, a digital experience consulting firm. “To realize the benefits of microservices, the organization must begin a journey to modernize IT technology and processes.”
In this article, microservices architects and engineers describe common microservices implementation mistakes and how to avoid making them. These experts include Roch and Matt McLarty, software architect at CA Technologies, vice president of API Academy and co-author of the book, Microservice Architecture(O’Reilly Media). Both were speakers at the recent API World 2017 conference. Also contributing insights is JavaOne 2017 speaker Mike Croft, a Java middleware consultant and support engineer for Payara Services Ltd.
What you don’t know about microservices can…
Roch has talked with companies trying to build microservices without first understanding the differences between a simple service, a web service and a microservice. “They’re not really building microservices, because they are not following all the microservice architecture constraints,” he said. For example, they’re sharing databases, or they’re not monitoring or deploying microservices correctly.
CA’s McLarty compared today’s failed microservices projects with early Agile adoption mishaps. “Suddenly, companies were saying, ‘We’re Agile now!’ Peel back what they’re doing, and they’re Agile in name only,” he said. “Tragile was more like it.”
Where’s your microservices migration Q&A?
To succeed with microservices, start with creating a strategy, Roch advised. Create a Q&A that covers everything from proposal and development through implementation and lifecycle management. He suggested some starter questions:
- What is the state of your coding, application development and Agile processes now?
- What is your mix of on-premises and cloud applications?
- What are the business drivers for a microservices transformation project?
- What would the final build look like?
- What are you going to build first, and why?
- What are you going to do with legacy applications? Which ones will be discarded, modernized or replaced?
- What are you going to migrate first, and why?
- How are you going to operationalize microservices and manage the whole lifecycle from planning to deployment?
- What is your architecture choice?
People who need microservices … but don’t know it
McLarty noted that planning must include the people element in implementing microservices. Map out how all players in a microservices migration will benefit and how successes will be rewarded. “Plan out the incentives you build into the organization to do these new things. That’s going to drive adoption more than an enterprise chairman trying to force everybody to do things in a different way,” McLarty said.
Roch agreed, noting that business leaders must make it clear to DevOps people that implementing this type of architecture must align with the business’s vision for digital transformation and DevOps’ quest for automation. Convincing the business people is also challenging, because the benefits of implementing microservices may not show up immediately.
Migrating to microservices can uncover legacy problems
Poor planning and no self-examination before migrating to microservices lead to many technical challenges, our experts said. For example, said McLarty, developers build microservices that are actually old-school monoliths. Dependencies are not broken apart, and the microservice is not an independent service. “Microservices should be loosely coupled components, components that you can test independently,” he said.
Roch agreed, noting that building or operationalizing microservices the wrong way leads to deployment problems, service outages and slow app response times. Often, when these problems happen, they are blamed on other issues, and there’s no recognition that the microservice is flawed.
Know your application lifecycle management (ALM) processes before implementing microservices, our experts said. If the existing ALM setup is not thoroughly modern, there will be multiple barriers to implementing microservices. Croft sees microservices migrations failing because a business’s internal organization is not structured in a way that’s conducive to writing modern and good applications in the first place. “That’s reflected in the code that you create, obviously,” he said. “In microservices development, poor code problems can escalate quickly, because rather than having a single product, you’ve now got maybe five or six that all contribute together to be one main product.”
Roch noted that modern ALM should include API-first development, a must for microservices integration and coordination. “With API-first, you can implement a data management strategy and establish a system that allows [you] to keep track of what’s happening with the various APIs integrating and supporting [the] software architecture,” Roch explained.
Consider also the cloud DevOps skills available in the business, Croft said. “Obviously, you can run microservices on your own data center if you want, but you’re not really getting the benefit of real massive scalability cloud environments provide,” he said. A key route to success is knowing how to apply reactive design to a legacy code base, then proceeding to split it into multiple microservices and, finally, deploying those microservices to the cloud. “That does bring a lot of benefit by adding scalability,” he said. “It’s cloud-dynamic responsiveness that you need to be successful.”
