TechTalks With Tom Smith: Concerns When Migrating to Microservices
TechTalks With Tom Smith: Concerns When Migrating to Microservices
The business problems that need to be solved, the ease of doing so, trying to use them for everything, and management.
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, "Do you have any concerns regarding the migration of legacy apps to microservices?" Here’s what we learned:
You may also like: Microservices Migration Use Cases
- One word of caution, don’t do it for the sake of doing it. Know the business problem you are trying to solve — manage scale, develop features quickly, manage the geographic distribution of data.
- The main concern around migration to microservices is the risk of limited planning. The popularity of microservices implies the many benefits, but you don’t get them unless you’ve defined your goals and planned an architecture that aims for those goals. Simply trying to map a legacy app’s functionality into a microservices architecture on a one-to-one basis can lead to technical debt that makes the migration a huge challenge.
- Microservices stay true to your needs. Don’t over-engineer to be too small. Focus on what you are trying to solve so you are not introducing more complexity. Strive for easy to build, deploy, and update.
- Sprawl. Anytime your virtualize something the more sprawl there is. The original intent about what each service is supposed to do and not allowed to do. Security is huge around microservices. Change monitoring becomes important. How to maintain, own, manage, and sunset. Key management, learn IM versus machine access, driving minimal access control. Create your own services platform capable of maintaining security.
- Enterprise IT has spent decades building monolithic applications, and most organizations and technology stacks are tuned for that style of implementation and deployment. Microservices architectures are far more complex and have many moving parts. Scaling, orchestration, dependency management, operational visibility — all of these become exponentially more difficult. Without the appropriate skills, culture, and tooling, these initiatives can be doomed to failure.
- 1) There are lots of moving pieces, technologies don’t expect to be the expert in everything. Leverage technologies, frameworks, and products that are out there.
2) Make sure there isn’t any downtime or data loss as part of the process.
3) Keep extraneous expenses to a minimum.
4) Don’t include ESB/SOA middleware as the cost of doing business.
5) Factor in the long-term cost of putting all of your resources in the cloud.
- This transition may not be appropriate for everything in the portfolio. The more economical thing may be keeping the brownfield app alive.
- Don’t do it because it’s cool. Identify specific business concerns you are trying to address. Have the foundation right — understand the business objectives of the software you are building, organize teams around business concerns, get the infrastructure (K8s, DevOps, cloud), then decide on the services you are going to create. Logging, monitoring, exception handling, fault tolerance... All of these surrounding infrastructure issues need to be thought through.
- Since we’re delivering our software as an on-prem deployment, the footprint is a major factor. Adding runtime components in the form of more service processes, database schemas, connection pools increases the minimum resources required to run a full environment. This doesn’t necessarily mean that an increased scale would linearly require more resources, but the overhead is a concern for some of our customers.
- Adopting a microservices approach also means that even though each component can be made a lot simpler, we’re increasing the complexity of the overall system. There are a lot more components to monitor and track, and more chances of local failures. The system needs to be designed to handle failure at every interaction point.
- That also compels us to provide greater visibility into all aspects of a production runtime. We are concerned and are investing a great deal in mitigating any disruption to the existing public API. By not only reimplementing existing designs but redesigning significant parts of our software it’s almost inevitable not to introduce a new public set of API endpoints, often replacing the existing one. We’re investing in a backward compatibility layer to minimize disruption.
- The difficulty of hiring people with the skillset. Setting expectations. It's hard to find the right developers.
- Managing costs is a concern of migration to microservices, as IT will be spending money on the migration process and managing the cost of cloud services. This is also where a monitoring solution can help IT keep tabs on costs in relation to application use.
- The CIO and executive leadership will want to see early if your costs are in line with the increase in revenue you anticipate with the newly designed application. Also, leveraging a product like Turbonomics helps IT manage workloads, so you properly expand and collapse your cloud environment in alignment with your expense.
- Highly-regulated industries and those that use waterfall development methodologies and have less frequent software releases, such as healthcare, government, oil and gas, and manufacturing, may not benefit from a move to microservices architectures.
- Unless everyone involved truly understands why the migration would benefit the organization and there is a clear path, migration is a risky effort. If done correctly, moving a legacy app to modern architecture would improve IT Response times and therefore the top-line growth of the business greatly.
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.