TechTalks With Tom Smith: What Developers Need to Know About Migrating Microservices
Keep learning, be flexible, think in terms of services.
Join the DZone community and get the full member experience.Join For Free
To understand the current state of migrating legacy apps to microservices, we spoke to IT executives from 18 different companies. We asked, "What do developers need to keep in mind when migrating legacy apps to microservices?" Here’s what we learned:
You may also like: TechTalks With Tom Smith: Tools and Techniques for Migration
- It has less to do with the developer than the business that decides to go on the journey. There’s a steep learning curve. Vendors are still trying to establish their space and offer boot camps and tutorials. Never stop learning. Stay sharp and competitive by taking advantage of this before you have to start paying. Carve out the time to build proficiency have competence with Docker and K8s even with projects at home. Vendors are going out of their way to court developers, leverage that.
- Learn what microservices are, understand orchestration, work on CI/CD a lot of ramping up to do. Understand logs and tools. Educate on microservices and then look at an API gateway to integrate.
- Make sure something needs to be a separate service and that only comes after you have some data on how the monolith is being used and where there are bottlenecks. Don’t prematurely optimize the service stack. Always have a plan to monitor microservices and do so uniformly across all the microservices.
- When taking legacy applications to microservices (or developing new apps), developers need to consider and re-architect their applications to run and take advantage of the highly distributed environment microservices to offer. Many legacy applications and software products were designed to run in a scale-up architecture and are delivered as a single stack of tightly coupled software (i.e. single binary executable).
- In order to leverage the distributed nature and scale-out benefits microservices, containers, and container orchestration tools offer, developers, need to redesign and break part individual components and services so that they can run, scale, and be upgraded independently. Developers and DevOps deployment engineers will also need to consider how best to secure their microservices and containers.
- Containers share an OS kernel and require a root level authorization (in Linux environments) in order to run and perform such tasks as accessing persistent storage. Attackers have the potential to extend their threat beyond the container and into an underlying OS and other containers if container security is not implemented.
- Try to build, start simple, as you start to learn new frameworks and trends get your feet wet. Be active in open source, contribute to projects to hone skills and learn. Understand the complexities involved as you break out different components. Where will your database be? Figure out best practices around the database early on. Be portable, stay flexible.
- Take it on a use case by use case and only migrate what makes sense. You can leverage the legacy system directly from microservices and still have a cloud-native application. Migration is a choice but not the only one.
- You most likely will end up rewriting parts of your legacy application and it is easy to underestimate the number of features, functionality, and undocumented features the legacy application contains. Also, be aware of the Second-System Effect. It is easy to over-engineer the new system.
- Developers need to keep in mind that a microservices architecture is not just a refactoring of legacy apps, but a new way of thinking. They need to continue to plan for modularity and code reuse as before but at a more granular level. Since the workflow in a microservices architecture can be represented by a directed acyclic graph (DAG), developers need to think about how a system can be broken down into smaller components, and lightweight messaging protocols, that allow many different subtasks to be reused in different parts of the workflow. With this new way of thinking, starting a microservices journey is a good time to explore new technologies that can address some of the more difficult requirements around performance, scalability, and reliability.
- Do not reinvent the wheel. Look carefully at how to refactor your application and see how it can be broken apart. Understand the critical components and what is available for you to leverage. We are in a time when you need to be fast and agile, so you cannot afford to create things from scratch.
- Focus on your strengths on what you do best. What gives the most value to the business. Improve productivity or solve business problems. Prepare by setting up clear goals along the journey and how to be accountable for the goals. If it’s not the right thing to do, stop there.
- Data separation has to be given the greatest consideration. When primary keys are discarded in favor of NoSQL DBs and each data set is isolated to its microservice, the # of cross-service calls (getter-setter methods) would increase. Handling this traffic in the face of asynchronous communication is a key challenge for developers. With autoscaling groups in Cloud platforms, developers also need to ensure that multiple instances of the same microservice may exist, so data intended for one should not be consumed by another (which can be achieved through a conflict-free replicated data types (CRDT) enabled database).
Here’s who shared their insights:
- Gregg Ostrowski, Regional CTO, AppDynamics
- Jaime Ryan, Head of Strategy, Layer7 Security and Integration, Broadcom Enterprise Software
- Sanjay Challa, Director of Product Management, Datical
- Dale Kim, Senior Director of Product Marketing, Hazelcast
- Marco Palladino, CTO, Kong
- Karthik Krishnaswamy, Director of Product Marketing, F5
- Joe Leslie, Senior Product Manager, NuoDB
- Zeev Avidan, Chief Product Officer, OpenLegacy
- Matt Yonkovit, Chief Experience Officer, Percona
- Bich Le, Chief Architect, Platform9
- Sridhar Jayaraman, VP of Engineering, Qentelli
- Anurag Goel, CEO, Render
- Patrick Hubbard, Technical Product Marketing Director, SolarWinds
- Idit Levine, Founder and CEO, Solo.io
- Markku Rossi, CTO, SSH.com
- Nick Piette, Director of Product Marketing API Services, Talend
- Ophir Radnitz, Software Architect, Tufin
- Karthik Ranganathan, Co-founder and CTO, YugaByte
Opinions expressed by DZone contributors are their own.