Ask HN: How does your team maintain a high level overview of its microservices?

The question could be - How do you design&#x2F;develop&#x2F;maintain dependency hell of your micro services?<p>Service discovery is one solution. Dependency graph is always behind built tools (SBT, Ant, Maven, NPM, PIP,..etc) unless you standardize them.<p>If it is environment specific, It could be part of your configuration management tools like Ansible, Chef. I like it here because it is pretty much codified in terms of DSL scripts. Config management sitting in front of Linux package manager like YUM, APT, etc.,<p>In Docker world, It could be part of application profiles, Pod, Pod groups. Sidecar dockers, System service dockers should be captured as dependencies in pod groups as part of infra&#x2F;environment setup.<p><a href="https:&#x2F;&#x2F;kubernetes.io&#x2F;docs&#x2F;concepts&#x2F;workloads&#x2F;pods&#x2F;pod&#x2F;" rel="nofollow">https:&#x2F;&#x2F;kubernetes.io&#x2F;docs&#x2F;concepts&#x2F;workloads&#x2F;pods&#x2F;pod&#x2F;</a> <a href="https:&#x2F;&#x2F;mesosphere.github.io&#x2F;marathon&#x2F;docs&#x2F;application-groups.html" rel="nofollow">https:&#x2F;&#x2F;mesosphere.github.io&#x2F;marathon&#x2F;docs&#x2F;application-group...</a><p>I guess there is very good market to solve this dependency complexity issues. Micro services leads lot different type of tech stacks and addressing the complexity is niche in demand. This could be very good idea for startup.

From a technical perspective, a tracing system like opentracing is essential. Jaeger is a very user-friendly and great standard to do it. I prefer it over Zipkin.<p>If you want to maintain an &quot;index&quot; you can use a service-discovery service like <a href="https:&#x2F;&#x2F;www.consul.io&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.consul.io&#x2F;</a> and build tools on it.<p>Here you can see an example how to manage it with hemera in the node.js world <a href="https:&#x2F;&#x2F;github.com&#x2F;hemerajs&#x2F;aither" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;hemerajs&#x2F;aither</a>. We use a production-grade messaging system called <a href="https:&#x2F;&#x2F;nats.io" rel="nofollow">https:&#x2F;&#x2F;nats.io</a> as service-discovery and transport layer and have a very transparent and maintainable landscape of our services.

Are you referring to just internal documentation about your own architecture?<p>If you are struggling with the runtime dependency and debugging, make sure you have a distributing opentracing stack like Jaeger running.<p>If it’s internal docs and wikis and knowledge, make this part of what you build. Writing code and shipping to servers isn’t where our job as engineers ends. Document it. Training your coworkers. Make sure you are building maintainable software, and that means that building software isn’t just about writing code.

This is one advantage of having client libraries, if you publish them to a local package feed the dependencies become easily enumerable.<p>You could dynamically infer this by adding origin info to your service locator query (&quot;<i>I&#x27;m Profile service</i> looking for User service&quot;).