As two of the many engineers responsible for LeanIX’s microservice environment, we've developed clear opinions on how to succeed with this technology — or, at the very least, learn faster from mistakes. Our job is to ensure that the speed and efficiency of cloud-native software development is matched by a culture of ownership and responsibility: two qualities that can only be measured within a business context.
To better understand our working environment, this is LeanIX’s current technology landscape:
Back-end languages: Java, Nodejs, Golang, Python
Database technologies: Postgres, Elasticsearch, Influxdb, Redis
65+ engineers and product managers
15+ development teams spread across 4 tribes in two locations (Bonn, Germany + Hyderabad, India)
10 Kubernetes clusters across four regions
As LeanIX continues scaling, this list will grow and the two of us will have more difficulty giving our engineering colleagues an up-to-date overview of our landscape and the complexity within. This information is essential for performing quick incident responses and onboarding new teammates. It is also necessary for keeping developers engaged with value-generating tasks rather than documentation and fact-finding.
But despite the advantages of shorter deployment cycles, easier implementation of CI/CD pipelines, and better fault tolerance of single services for IT departments, microservices create numerous problems for managers — the majority of which, in our shared view, stem from a systemic lack of transparency.
Specifically, developers need to know who owns which service in a microservice landscape to identify which dependencies exist and which technology is being used. Software licenses need to be apparent throughout this whole process to set the parameters of what can and should not be implemented, and the lifecycles and vulnerabilities of code libraries need to be evaluated to ensure compliance with specific environments and regions.
Both of us collaborate every day with teammates across LeanIX’s ever-expanding IT and business landscape to analyze whether products are reliable and where optimization is possible and needed. The better visibility our development organization has over our microservice landscape, the more informed decisions we can make when deciding, for example, to improve or build new features. This allows us to see the full picture while understanding the root causes and implications of an incident. Proper insights and documentation help us avoid repeating mistakes — thereby helping us build more resilient software for our customers.
How LeanIX Microservice Intelligence helps
Not many engineers get to build a product that solves the very problems of their job. With LeanIX Microservice Intelligence, we've helped create a platform that automates the discovering and cataloging of microservices. The product functions as a central repository for microservice documentation (including owner/description metadata, deployments, library usage, runtime information, dependencies, and violations) and offers various reports and matrices to manage relationships between microservices, libraries, violations, APIs, and teams.
LeanIX Microservice Intelligence comes with an out-of-the-box adaptor for Jenkins, Kubernetes, and GitLab to reconcile all services with runtime information and dependencies (e.g., NPM, Maven, Gradle) on an organization's CI/CD pipeline. As well, dashboards are at the front and center of the platform to display KPIs such as deployment frequency, change failure rate, mean time to resolution (MTTR), and lead time.
As others have already shared, LeanIX truly does run LeanIX. The visibility provided by LeanIX Microservice Intelligence saves our teammates time when identifying microservices and automating documentation. We can also track the success (and ongoing risks) of deployments via clear metrics and allocate more resources to the actual development of our SaaS-based products.
If you’d like to know more about LeanIX Microservice Intelligence or our company’s shift to a microservice architecture, reach out here.