TechTalks With Tom Smith: Migrating to Microservices, Additional Considerations
It's complicated, there are many issues to consider.
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 have I failed to ask you that you think we need to consider with regards to migrating to microservices?" Here’s what we learned:
You may also like: TechTalks With Tom Smith: Issues in Migrating to Microservices
- Developer happiness is critical to this movement. Organizations should look at this as a way to recruit developers.
- Even though not directly related, security is becoming part of the microservices design. There's greater chance there will be a breach. Thinking security first is a good practice. Also, think about the potential for failure.
- Perhaps a specific question around misconceptions of microservices would be interesting. I’ve seen blog posts where developers assert that microservices are “more complex” or are “hard to integrate.” The claim around complexity is mostly based on the fact that there are more distinct applications to deploy and manage, but since each microservice is simple and easy to manage, the overall system becomes less complex to deploy and maintain than a legacy app.
- The claim around integration difficulty is reminiscent of the challenges of SOA and suggests that developers are using SOA as a model for microservices, which is not a good plan of attack. Developers need to understand that each microservice only serves data to a limited range of other microservices, so the communications protocols should necessarily be compact and simple.
- The migration of legacy apps to microservices needs even more careful consideration than an initial foray into net-new app development. An enterprise should already be on that organizational and cultural journey before refactoring existing applications and should have a compelling technical requirement – restrictive dependencies, inability to scale, high rate of change, etc. So, the first step should be to consider WHY you have decided to migrate your legacy applications to microservices.
- I think one of the areas missing is around a multi-cloud and hybrid environment. Many of the customers I have spoken with initially plan to move to just one cloud platform but quickly realize that it is not practical. Take a look at all the microservices available and who offers them — it’s about best of breed for your needs. Trying to make everything fit as a one size fits all is not a realistic approach.
- It's important teams maintaining exiting business while another team is transitioning to make sure one is not more important than the other. They are all significant to achieve the same goals. Set goals and discuss the cultural aspects. Will change how teams are organized. How does it impact the developers and the culture?
- In scale-out architectures, there are multiple instances of the container. For stateful containers, it’s important that clients are able to connect to any instance of the container and receive a consistent view of the data. Different scale-out databases have different consistency models. It’s important for application developers to understand the consistency model supported by the database they are using.
- For some applications, eventual consistency works. Some databases are able to achieve high availability in distributed environments using eventual consistency. With this consistency model, the application must be able to handle consistency conflicts. This may require significant application changes to support that ability. Many applications being migrated to the cloud and containers require a stricter consistency model, particularly applications handling business-critical data.
- Are microservices and cloud the ultimate model or is a hybrid model a stable alternative? This is all about legacy systems but not about all of the on-premises. Many applications will stay on-premise but need to interact with the cloud economy. You need to discuss how those can be part of the microservices architecture going forward. Should this eventually be broadened to more than just microservices but also other cloud-native options like serverless, etc.?
- I would like to highlight the importance of having a business case. What are the business justifications for the microservices migration? What are the drivers and expectations? We might get too excited about the new technologies and forget to look at the business aspects of these projects.
- Delivering rich applications as on-prem deployments is a world apart from delivering similar applications in a SaaS model. The solution needs to be portable. It needs to fit many different types of customer requirements. It cannot take advantage of managed solutions. It needs to operate reliably with almost no real-time visibility for the development team. It needs to be delivered in a cadence that fits the customers’ willingness to upgrade their production environments.
- That invariably means it packs a huge amount of changes in each deliverable. That requires a very high degree of confidence for each release since there are very few opportunities for introducing fixes and the risks are higher. That leads to a different approach to testing. That also requires a more conservative and deliberate approach to backward compatibility. In short, almost every aspect of migrating software to microservices is impacted by that property. In addition to the questions you’ve asked, a closer examination of how that takes place can be interesting.
- I can think of two points that merit serious consideration when migrating to a microservice architecture. Impact of the migration to upstream and downstream applications – e.g., an external application may have been connecting to one endpoint on the legacy app that orchestrates all the necessary operations and returns information synchronously.
- With a microservice architecture, you need to create wrappers that orchestrate different microservices in a sequence and supply that information. Application performance, especially when SLAs and corresponding penalties exist (they do). The legacy app has been providing a baseline SLA, but there is no guarantee that during the migration and even once re-architected, the application will continue to maintain or improve the SLA performance.
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.