TechTalks With Tom Smith: Issues in Migrating to Microservices

DZone 's Guide to

TechTalks With Tom Smith: Issues in Migrating to Microservices

People, determining service size, identifying dependencies, monitoring, and data.

· Microservices Zone ·
Free Resource

Image title

We have issues (with migrating to microservices).

To understand the current state of migrating legacy apps to microservices, we spoke to IT executives from 18 different companies. We asked, "What are the most common issues you see migrating legacy apps to microservices?" Here’s what we learned: 

You may also like: Migrating to Microservices? Here's How to Have Reliable APIs From Day One


  • You are going from an army of sysadmins to spinning up and managing infrastructure not directly under your control. There's an evolution of the sysadmin role. Get data in the right format in the right places. This is why infrastructure as code is gaining popularity. Make it declarative in nature to make it easier. 
  • People either try to rewrite and fail miserably or just do greenfield with no plan for integration. The new team doing microservices ends up extending the monolithic application because management gives up on the integration and ends up telling everyone to keep working on the monolithic app. Twitter and Lyft were successful because they made the transformation gradually.
  • During the analysis phase, you learn a lot of legacy apps were designed and assembled by people who have left the organization. The way applications are stitched together is poorly documented and people have trouble understanding the anatomy of their legacy apps. Another challenge in understanding microservices is there’s a lot of hype. People attempt to just convert legacy apps without understanding the need to rethink how an application is structured and designed. They expect an easy transition without understanding the principles. There’s a huge learning curve. 
  • Lack of pragmatism about the problems you are trying to solve. Lack of documentation. Microservices are all about trust. What’s available in the enterprise. Poor documentation results in no trust. You are unable to leverage each other’s work. Documentation becomes a trusted authority within the enterprise. We help developers keep documentation up to date. Use machine learning (ML) to learn and update documentation by listening to traffic and creating the documentation. Documentation is not seen as valuable. Documentation is not a “nice to have,” it’s part of the product — what it does, how to consume, and how to use it. If systems are not performant and fast, slow is the new “down.” Outstanding application performance is key to great user experience.

Service Size

  • Identify the service size. It should be as small as needed but no smaller. You have all the advantages of each team having a tech stack, but you also have complexity from a traffic standpoint across the datacenter. Ensure you have a handle on traffic, which there is a lot, and monitor performance, reliability, caching, and routing to ensure high availability.
  • People, technology, and infrastructure. Microservices is driving the conversation around DevOps and CI/CD. Understanding how much to break off has to match the business problem to solve and the structure of the organization. Size the service to meet the need. 
  • The most common issue we see when migrating legacy apps to microservices is the maintenance challenges that result from the initial plan to minimize the architectural change. For example, if a legacy app consists of five modules, the natural direction for the new architecture is to build five microservices, which is often not the correct design. Following a service-oriented architecture (SOA) also creates challenges, as SOA is ideal when your applications need to communicate with all other applications, versus a microservices architecture where each microservice only needs to serve data to a specific set of consumers. By continuing a monolithic application mindset, you don’t truly take advantage of microservices and often just create more overhead as a result of the inefficient design.


  • 1) Dealing with complex middleware (ESB/SOA) that no longer is required but is part of the current implementation. 2) Understanding the legacy application and deciding which use cases are necessary and which are nice to have.3) Understanding the business logic that goes with the legacy system (regulatory or security concerns, etc.).4) Breaking down the monolithic application into small, distinct pieces for a real microservices architecture.
  • It’s not obvious where to draw the lines separating between potentially independent domains in existing software. Often using a shared model across different areas of the application makes for very tightly coupled design. This can even be dramatically exacerbated when using an ORM system, where the model is sometimes correlated with the database schema. Implicit transactional boundaries, provided by some popular frameworks, often contribute to an entanglement that’s very difficult to clear up.
  • The flow of data in and out of the system is also a major factor in being able to break down legacy apps into independent microservices. Each microservice should be able to store and retrieve its data independently of the rest of the system. For that to take place, the sources of data for each microservice need to be clearly delineated. That’s not an easy thing to do. Propagating and consuming events is often the go-to solution for these issues but it’s not trivial to adopt.


  • Tenacity, you have to see it through to completion when things get scary. Consider the move to microservices as experiments and learning exercises. Someone in middle management and IT pull the ripcord. Monitoring becomes a huge issue because it reduces worry. So companies may not have any monitoring at all. If you can’t provide replacement data and signals from microservices, ops are going to resist. Make sure you provide robust instrumentation inside the application. 
  • One common issue is that migrating to microservices is a bit of a cultural shift, as the legacy applications may have been around for many years and some IT teams can be reluctant to change. Ultimately the shift needs to be made as demand for fast, intuitive, and elegant applications are not slowing down.  Monitoring the application is even more critical as one microservice can cause an issue somewhere else. When you break apart a monolithic application into many microservices you can quickly see how this is a concern, so putting a monitoring solution that covers all aspects of on-prem and cloud is critical to helping IT Operations reduce the time of root cause analysis and understanding all the dependencies.


  • People think the new microservices will behave the same way as the legacy app. Multiple services are interconnected. Unless your app and workload are consistent you can have misaligned expectations. Scaling databases requires storing data for microservices in a single node. Think through what the database recovery will be.


  • Figure how to communicate between services to ensure they synch and deploy automatically, have the right code at the right time. There is a lot of complexity required to manage a suite of services. Management overhead is the biggest issue that comes from moving from one to multiple services and how to communicate between services that do not share memory.
  • Scalability, fault tolerance, and geographic distributions. Day two operations are quite different with microservices than with a traditional application.
  • It’s important to understand the difference between north-south traffic (into and out of the application environment) and east-west traffic (between services within an application) when it comes to security, identity, routing, and service discovery. Last-mile policies enforced by service mesh and other local infrastructure tools are not a substitute for edge-based technologies that manage and secure the application when it’s exposed to broader audiences.
  • Microservices can improve agility, but they aren’t for every organization or application. When starting with microservices, it’s important to remember that they require significant development and delivery skills, including implementing proper security measures, building a mature DevOps environment, and enforcing a high degree of standardization and automation using methods such as CI/CD and technology such as containers and Kubernetes for container orchestration.
  • Don’t migrate everything. It may not be worthwhile to refactor very old applications that are built with old languages and databases. These applications may be worth rebuilding from scratch rather than migrating them.
  • Another challenge is migrating more complex legacy distributed applications that run in an on-prem Data Center-centric infrastructure to a distributed application architecture using cloud-centric technologies deploying K8s applications seamlessly across multi-cluster environments. Moving to the cloud offers many advantages, but there are significant startup costs and learning curves to navigate in order to successfully transform from legacy distributed apps to modern distributed cloud-based microservices apps.
  • 1) In many cases, microservices migration requires architecture and code changes which can lead to long development cycles. 2) Microservice orchestration (deployment, upgrades, rollbacks) require more effort compared to monolithic architecture.3) Operations, diagnostics, debugging require new tooling since a single computation or request can touch multiple isolated microservices. It is harder to follow the request through the infrastructure, compared to the monolithic application. It is important to have proper auditing and tools to get visibility into the computation.
  • The most common issue is applying microservices architecture to every application, just because it is the “in-thing” or because of perceived benefits. Careful evaluation is necessary since the development, operation, and maintenance of a complex microservices-based application can become an expensive white elephant if not designed properly. The second most common issue is how to migrate — do we rewrite the whole app, or do we do it piecemeal? Rewriting from scratch has many issues — the “why” of some of the features may be difficult to reconstruct, the schedule for the new app may be uncertain. But the biggest challenge is that Business may not fund the rewrite — after all, the old one is working fine for now!

Here’s who shared their insights:

Further Reading

The Future of Microservices Migration

Microservices Migration Use Cases

data ,microservices ,migration ,monitoring ,service size

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}