neduma

I called this phase 2. Discovery, documentation and ongoing maintenance going to be the problem. We need to another jenkins to CI/CD the main tooling Jenkins.

My other though is that there is significant market for this kind of back office tooling clean up and ongoing maintenance. If we could come with a process to clean up and package it. we could sell it. I would definitely buy it cause it gives lot of time saving for day to day toils especially in operational space.

Pls check: Learning resources

Service discovery is one solution. Dependency graph is always behind built tools (SBT, Ant, Maven, NPM, PIP,..etc) unless you standardize them.

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

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/environment setup.

https://kubernetes.io/docs/concepts/workloads/pods/pod/ https://mesosphere.github.io/marathon/docs/application-group...

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.