TechTalks With Tom Smith: Executive Insights on Migrating to Microservices
TechTalks With Tom Smith: Executive Insights on Migrating to Microservices
Fix any problems you are having today before you begin migrating to microservices since microservices exacerbate preexisting problems.
Join the DZone community and get the full member experience.Join For Free
To understand the current state of migrating legacy apps to microservices, I spoke to IT executives from 18 different companies. Here’s what I learned:
The keys to migrating legacy apps to microservices are planning, having the right architecture, following a DevOps methodology with automated CI/CD, and alignment across IT with regards to the migration plan. Fix whatever problems you are having today before you start the migration. Microservices will exacerbate a preexisting problem.
You may also like: API Management Executive Insights
Take the time upfront to declare what the standards are. You are managing cattle, not pets. Know what functionality is most important to expose first. Allow access to the legacy systems so other teams can build their applications that will work with the legacy systems while the migration takes place. Think on a large scale about how this will work when you have thousands of microservices.
Properly design your architecture to leverage microservices. This requires a shift in mindset from building legacy apps. Review the application architecture to understand which sub-components could be implemented as microservices.
Initiate plans for a full continuous release environment to automatically update improvements in features and performance. Embed security in DevOps processes, practice continuous delivery and continuous integration, automate core infrastructure and releases, and deploy a Kubernetes (K8s) application management model.
Get all of IT and business leaders on the same page with regard to the purpose of the migration. Ensure all relevant staff in the development, infrastructure, operations, and business have a clear understanding of the baseline metrics that show how each component of the application is performing so you can see increases or decreases in user experience.
The migration of legacy apps to microservices has become more standardized and more familiar with containers and K8s. As the process has gotten easier, developers are able to take advantage of the processes already built and hardened. The increased flexibility of microservices allows development teams to use their own technologies on their own components to build a large, cohesive system.
Many open-source tools are mature enough for enterprise adoption and microservices patterns are well understood and replicable. Most companies are evolving into containers in the cloud. K8s has made it easier to manage and deploy containers and they will work across any cloud.
The most effective tools and techniques for migrating legacy apps to microservices are K8s, Docker, and debugging and tracing tools like Prometheus. Docker and K8s are the clear leaders of the ecosystem.
Application use cases revolve around the modernization of legacy apps, speed, and flexibility. The industries most frequently mentioned in the use cases are financial services and retail.
Microservices enable companies to scale services differently independent of other services. Resilience, reliability, scalability, and fault isolation are all benefits of microservices. Feature velocity is accelerated while transactions are de-risked. Microservices grant an organization, and developers, the flexibility to innovate and try new things.
One financial services client is now deploying twice a month rather than twice a year. Payment processing where several distinct actions are taken is able to occur in either a serial or parallel manner. Modernizing the microservices infrastructure of big-box retailers enables them to provide a better customer experience. A post-purchase company is migrating from AWS to GCP without disrupting operations. Microservices are providing an elastic environment that allows the business to scale during critical events or peak traffic seasons like Black Friday.
The most common issues around the migration to microservices involve a lack of knowledge and skills, right-sizing services, identifying dependencies, monitoring, and data management. If an organization continues with a monolithic application mindset, it does not take full advantage of microservices and often just creates more overhead as a result of inefficient design. Migrating to microservices requires a cultural shift as legacy applications have likely been around for a number of years and IT teams can be reluctant to change.
Size the service to meet the need. It should be as small as needed but no smaller. Multiple services will be interconnected. It’s not obvious where to draw the lines separating independent domains in existing software. Monitoring becomes a huge issue as it reduces worry and one microservice can cause an issue elsewhere.
Concerns regarding migration to microservices include identifying the business problem, complexity, knowing when it’s appropriate, and infrastructure and management requirements. Do not pursue microservices because they’re cool. Identify the specific business concerns you are trying to address, define your goals and plan the architecture to achieve those goals. Strive for easy to build, deploy, and update. Jumping to microservices without thinking through needs tends to result in unnecessary complexity.
Microservices are rarely appropriate for the entire application portfolio. Some legacy applications work just fine and there is no need to “fix them if they are not broken.” Don’t move to microservices without knowing what you are trying to accomplish. Scaling, orchestration, dependency management, and operational visibility all become exponentially more difficult. Without the appropriate skills, culture, and tooling, these initiatives can be doomed to failure.
The future of microservices is faster adoption in the cloud, ease of management, the solution of business problems, and ultimately, serverless. Ultimately, everything is a microservice. The future will not look that different from the past. It will become easier to manage a suite of microservices and have visibility across the entire portfolio. Enterprise will look at changing or end of life for legacy apps as they build new apps for new use cases and make changes to customer-facing applications quickly.
The adoption of the cloud will continue to grow. Organizations and microservices will continue to revolve around the resolution of business problems. The timetable from imagination to delivery to almost real-time. Microservices will be able to incorporate business logic so the business can focus on where its expertise lies.
There is a whole industry popping up around the management of microservices – debug, troubleshoot, monitor, and secure. There are opportunities and problems as environments get bigger with regard to how to manage the complexity and the cattle.
Serverless is maturing and will become an alternate path to microservices architecture. The serverless computation may be a better alternative for some application domains.
To succeed with microservices, developers need to keep learning, think deeply about right-sizing services, be flexible, be knowledgeable about the tools, and participate in the open-source community. There’s a steep learning curve. Learn what microservices are, understand orchestration, and work on CI/CD. Take advantage of vendor bootcamps and tutorials as vendors try to establish themselves in the space. Have competence with Docker and K8s. If you’re not using Docker and K8s at work, explore them with projects at home.
Get the infrastructure ready. Think about the services you want to develop. Don’t forget your microservice should do one thing and one thing only. Think about how the system can be broken down into smaller components and lightweight messaging protocols. Don’t get religious about the size and scope of services, be realistic about the level of granularity that makes sense for your applications, and do not refactor existing apps unless there’s a need and an organizational readiness to do so.
Do it the right way or leave it where it is. Be an archeologist. Learn more about who built the legacy app and why. Write down everything you learn along with the deployment data so those going forward don’t have to start from scratch.
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 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.