Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

TechTalks With Tom Smith: Concerns When Migrating to Microservices

DZone 's Guide to

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.

· Microservices Zone ·
Free Resource

Tom Smith

Interviewer to the stars.


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

Business Problems

  • 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.

Complexity

  • 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. 
  • Related to increasing management overhead and the need to instrument each service separately. People tend to jump to microservices too early and make things too complex. Wait until you see bottlenecks and fund the pathways to help. 
  • 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. 
  • Not understanding what you're getting into and the complexity of the ecosystem. Microservices are a buzzword and people assume certain things will happen with migration and they won’t. 
  • 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.

Silver Bullet

  • This transition may not be appropriate for everything in the portfolio. The more economical thing may be keeping the brownfield app alive. 
  • It is important to understand the challenges above, and also do a business case calculation. Is there a positive ROI associated with the migration? Some legacy applications work just fine and there is no need to “fix them if they are not broken”.

Infrastructure/Management

  • 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.

Other 

  • 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.
  • Lack of documentation. A critical component to make microservices in place. Create automatically by monitoring traffic. Documentation is a product.
  • 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:


Further Reading

TechTalks With Tom Smith: Search + AI = Connection

TechTalks With Tom Smith: The Future of Microservices Migration

Topics:
microservices ,business problems ,complexity ,silver bullet ,infrastructure ,tom smith

Opinions expressed by DZone contributors are their own.

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

{{ parent.tldr }}

{{ parent.urlSource.name }}