rrohn

I guess, whatever works for a dev.

Standalone machines with Jenkins and TF

How do I reach you?

Going on a tangent, this is inspirational. I dont know how you can travel thru Afghanistan, and gain expertise on these subjects. And express it with this clarity of thought.

Coming back, simplifying architecture will never be easy. And if that is the case, how can communication of architectures be made simpler? Is it possible to build abstractions and represent them as such to make it simple for most to understand? Are there any tools have come closest to solving this? In a world full of complex micro services.. someone has to come and solve for this problem.

Wow. Thats some elaborate solutioning. I think the documentaion and cost attribution is pretty sorted at your shop. Does this solution help you save some costs at any point or the primary goal is only documentation?

Thank you. I'm curious, what tool did you use before to track your services based on tags, and how did it work out for you?

I’m targeting startups/corporates that are over 5 years old but haven’t become large corporates. Employee count from 50-500. At this stage, companies often lose track of their deployed infrastructure, leading to significant costs. Typically, around 10% of the infrastructure is underutilized or unused. And beyond this stage, things are either sorted or way too messy. Additionally, documentation struggles are common, with only a few individuals aware of the full architecture. Democratizing this knowledge can be incredibly beneficial.

To your questions:

1 - The assummption is you already have some tags for your infra. Which can include can include service names, environments, resource types, ownership. And you start from there.

2- Resource could be machines, databases, load balancers, even object storage. If you run unmanaged datastores, you'd have an option to identify that infra. You are right, to be useful on an ongoing basis, we'd regularly have to churn up suggestions based on underutilization.

3- I am not sure this can even be done automatically, but plan is to provide tools to easily document all intereractions and business logic. And depend on service owners to create this mesh.

4 - This has been a constant feedback. Yes something like an approval workflow should do, or may be skip this altogether.

UI is quite neat. What I am trying is something similar minus complexities.

Well, fair. Without an open source solution or on prem deployment, lot of companies will be hesistant to use such a tool. Thank you for this input.

Fair to assume this is a bank or a financial institution? IMHO working with excel sheets will not justify the usage of the tool.

You get the idea of what I am trying to build, if you were to do this for your org, how would you solve the problem? What will you do?

On point.

Do you think its possible to simpify architectures for most if not all involved? If so, how?

Curious, why would your architect not approve of it? We are thinking of a freemium model to start with.

Interesting. Re 1: Wasnt planning on doing this, as creating diagrams thru tags will ensure that you have updates in real time. If you had access to such a tool, would you gives access to tag manager? Re 3: Not in first MVP, but will be doing it. Re 4: Fair. I suppose suggestions will be useful by themselves.

The diagram creation will be automated, but you'd still have to give read only access to tag editor and cost manager. Would that be a deal braker?

You'd be the primary target customer. The exisitig tools in market are way too costly and number 4 would always be risky without proper ACLs and integration with your existing deplyment framework.

The challenge lies in making architectural knowledge accessible and comprehensible to the entire team, not just a few.

This tool will aim to bridge that gap by providing clear, visual representations of your deployed infrastructure, which can make the complexities of architecture more transparent and easier to understand. By centralizing this information, you can reduce the reliance on a few key individuals and make it easier for everyone to contribute and stay informed. This way, the plan becomes more than just a set of tasks—it becomes a shared understanding.

Yes, they should. However, I've often seen teams lose track of all the services and components deployed. There is usually a dependency on one or two engineers, and when they leave, it introduces a significant knowledge gap in the team. Organizations are typically focused on growing the business, and it's usually only the cloud provider who benefits the most from the lack of visibility and optimization.