Overcoming Communication Barriers for Microservices

Posted by Tim R on April 22, 2021

legacy2modern-ea@2x

Tracking integrations becomes increasingly difficult as enterprises transition to microservice infrastructures. In these situations, engineering teams require automated solutions to navigate shifting volumes of point-to-point connections and their dependencies. This is particularly important for companies operating hybrid cloud setups and balancing communication between on-premises, public, and private cloud networks.

Implementing purposeful new services in such varied environments can inadvertently lead to further complexity. This can paralyze fact-finding for engineering teams and make over-extended communication networks more fragile than they already are. Unfortunately, many organizations still embark on microservice journeys before introducing tools and processes for dismantling organizational barriers, expediting knowledge exchanges between teams, and generating up-to-date answers to questions like the following:

• Which microservices use vulnerable open source libraries
• Which teams own certain microservices
• Which microservices hold customer data
• Are failure rates being reduced and reliability increasing
• Which microservices overspend their budget

Early roadblocks to microservice journeys

Technology like MuleSoft can only do so much for teams structuring microservices for specific use (e.g., purpose-built experience APIs for consuming applications, composable APIs for orchestrating business processes, system APIs for connecting to back-end systems, etc.). Success during this process is more often than not impeded by the following roadblocks to communication and documentation:

Self-discovery: Not knowing which APIs are available for consumption and what information is provided.

Functional/UAT/QA testing: Spanning across business departments and API categories, necessary information for testing processes (API definitions and criticality, etc.) is lost.

Duplication of work: Transparency is needed to avoid creating APIs with redundant functions and interactions (e..g., message queues, stored procedures, third-party applications).

Production outage impacts: Dependency analysis is necessary to create contingency plans for technical malfunctions.

Technical debt: APIs require constant updating, and dependencies, logging patterns, and standards need to be diligently tracked.


For enterprises facing similar roadblocks, Donovon Simpson from OneMain Financial offers practical solutions in the below recording from the recent Enterprise Cloud Native Summit. Simpson is a software engineer who specializes in automating tools to improve the efficiency of developers. Optimizing CI/CD pipelines, production support tools, and documentation support tools are just some of his tasks.

Simpson's recommendations and insights from the ECN Summit align to LeanIX's own and span the areas of visibility, resource allocation, and trust. 

Visibility: Ensure documentation is automated via shared platforms which connect directly to CI/CD pipelines. Such platforms act as repositories of information on ownership and dependencies for development teams. Having contextualized understandings of product service availability and all corresponding employee responsibilities can shorten incident response times.

Resource allocation: Via multi-dimensional catalogs of microservices, teams can monitor development frequency, mean time to recovery (MTTR), and the failure rates of software services. These insights help balance resource allocations for application improvements or new feature investments.

Trust: Automated tools can help establish trust for teams of users across the entire IT and business landscape. By linking software libraries and their versions to microservices, DevOps teams can faster identify and prioritize patches and reduce open-source library vulnerabilities. 

If you have any questions on the video, please reach out to cloud.native@leanix.net

Subscribe to the LeanIX Blog and never miss a post again!