TechTalks With Tom Smith: How Microservices Have Changed the Migration of Legacy Apps

DZone 's Guide to

TechTalks With Tom Smith: How Microservices Have Changed the Migration of Legacy Apps

Standardization, maturation, containers, and Kubernetes are becoming the norm.

· Microservices Zone ·
Free Resource

Image title

Our fearless leader.

To understand the current state of migrating legacy apps to microservices, we spoke to IT executives from 18 different companies. We asked, "How has the migration of legacy apps to microservices changed?"

You may also like: TechTalks With Tom Smith: VMware Courts Developers

Here’s what we learned:


  • Microservices is now the de facto standard for migrating apps. Microservices make creating modular components easier. We're seeing a small tsunami of progress. Once you have components built, you can reuse them. You achieve economies of scale over time. The first one is the scariest and hardest.


  • With the large clients, we work with, we maturation and pragmatism around the hype and buzz. You have to be deliberate in how you proceed. Some apps will be brownfield legacy and others greenfield new. Get comfortable with smaller and newer apps and a multi-year program to build out portfolio and practice. We'll see an evolution from large to small data stores that may be in the cloud and more ephemeral.
  • Companies are becoming more comfortable in the ability to do this. People have seen the success with microservices architecture. They may not be experts in APIs or distributed application development so a prepackaged solution reduces the barriers to entry where you don’t need to use code. Toolsets are solidifying and improving collaboration between the steps.
  • It used to be you’re on your own and good luck. Now there are new tools and standardization around platforms and best practices. A lot of early adopters are having to remodel early implementations to take advantage of new tools and techniques.
  • Earlier migrations of legacy apps were constrained by the perceived limitations of microservices architectures. For example, developers might think an entire architecture required a common technology stack, or required stateless processing, or had to be built entirely by the same team to simplify inter-service handoffs. The recognition of the greater flexibility of microservices allows different development teams to use their own technologies on their own specific components to build a large, cohesive system.
  • For those that have already adopted a microservices-first development approach, the existing infrastructure and culture will make the transition smoother than during the first stages of adoption. Though the landscape of supporting technologies is vast and rapidly evolving, many open source tools are mature enough for enterprise adoption, and microservices patterns are well-understood and replicable.
  • The migration to microservices has become a much easier process as the developer can take advantage of repeatable processes already built and hardened. For example, leveraging Okta for authentication allows you to quickly enable authentication to your applications, freeing up development teams to focus on more business-relevant features. Amazon also helps enable rapid scaling, which takes the guesswork out of capacity planning and sizing. AWS even provides tooling to help with these tasks.


  • We'll see 85% of companies pursuing the "Strangler approach" over the next five years. We're seeing a strong embrace of microservices but a lot of people are just dipping their toe in the water. Containers are lightweight ephemeral infrastructure. Some begin on VMs. Most are evolving into containers in the cloud.


  • Companies moving to the cloud, first try to lift and shift and then realized it increased costs and worsened SLAs. Need to think cloud-native and build the cloud-specified way of rolling out services. Then see people realizing the need to move to different clouds or support hybrid architecture. One client started on AWS but realized they needed to go to GCP since retailers did not want to work with AWS. Over time you acquire companies that have built on a different cloud.
  • Once people see multi-cloud as important, they look for K8s to work across any cloud. Companies operating services in the cloud need to work with hybrid architecture. People want similar deployment across all clouds. The second big change is the CI/CD fast rollout of features. Commit code and send through an automated pipeline with as little manual intervention as possible. K8s enables deployment in any environment. Shift #3 are people building a private cloud for development in conjunction with a framework to speed development like Spring and Cloud Foundry and Spinnaker to make it agile.
  • The container technologies have brought new tools and abstractions into application migration. Before containers, you ended up rebuilding most of the applications, or you had to use multiple virtual machines to host different components, which could have been implemented using different programming languages and components (with possibly conflicting versions). 
  • Utilizing containers allows you to have “lightweight” virtualization and makes it easier to “containerize” your microservice with its dependencies. Container orchestration frameworks (K8s, and hosted K8s platforms on Google, Azure, AWS) have solved the orchestration part. You don’t have to build your own tooling and scripting to manage the microservice lifecycle.
  • The advent of Docker and the Kubernetes has made abstracting the application from the operating system very advantageous. There are plenty of tools that help with testing individual components or full systems. There are tools that make securing access to microservices easier.


  • Moving to microservices the problem is not just writing the code. The other problem is all the infrastructure will change. How to work with K8s. How to work with serverless. How to connect all of the environments together. How to operate once it’s written. Only scale the element of the microservices you need. You will need to learn an all-new set of operations tools and that’s another problem to solve. We help clients see migration, tooling, logins, metrics, and routing in one place.
  • It has not gotten any easier. There are companies with tools that claim to make the process easier but none of them is satisfactory. There is no silver bullet or automated way to do this. It’s a manual process. Some tools may help with initial analysis, identify well-known patterns (3-tier J2EE), libraries, to help you get started by generating a skeleton for microservices but that only helps with the initial part. The devil is in the details.
  • We use Docker-based deploys for everything. Being able to containerize is a benefit to extract services from an existing monolith. K8s has made it easier to manage and deploy. People will start with a service for the front end, then back end, and then scaling. They can deploy each one separately.
  • Microservices are fundamentally a refactoring of systems into something else. Have a good test suite in place so you’ll know if you break something. Know who can be impacted if something goes wrong. Have a rollback policy in place.
  • A lot of organizations haven’t yet begun to take on the migration of legacy applications to microservices. Some take a core monolith and split it into microservices, though they should note that taking on a full re-platforming project can take significant time and the knowledge for how to do it. Microservices' expertise is still hard to find. Another option teams take when it’s hard to maintain the monolith and still add new functionality quickly is to build new features as microservices. The migration of legacy apps to microservices and the path taken will continue to evolve as more organizations adopt them, containers, and container orchestration management tools.
  • The concepts of hybrid integration and phased migration have changed the dynamics, so it no longer is about rip and replace. As you go deeper into the core, the calculus of what to migrate versus what to leverage changes. Which is why you need a flexible hybrid integration strategy to support that. Companies don’t want to call ESB/SOA services inside a container to be called an integration microservice. They expect microservices to contain logic that goes directly to the legacy system and enables them to migrate when ready.

Here’s who shared their insights:

Further Reading

TechTalks With Tom Smith: Kubernetes Use Cases

TechTalks With Tom Smith: Kubernetes Evolution

containers, kubernetes, legacy app, microservices, standardization, techtalks, tom smith

Opinions expressed by DZone contributors are their own.

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

{{ parent.tldr }}

{{ parent.urlSource.name }}