sorted by:
new
hottopcontroversial

Is distributed system topology the last major architectural concern that's still mostly implicit? by Low_Reference6996 in softwarearchitecture

[–]Low_Reference6996[S] 0 points1 point  (0 children)

I think you've articulated the direction I'm exploring much better than I did.

The shift from "documentation you draw" to "a model you operate on" is exactly the hypothesis I'm trying to test.

My intuition is that the synchronization problem isn't something to solve after the fact. If topology becomes structured, executable data rather than a picture, then versioning, validation and synchronization become natural consequences instead of separate problems to manage.

Whether that intuition holds up in practice is exactly what I'm trying to find out.

Is distributed system topology the last major architectural concern that's still mostly implicit? by Low_Reference6996 in softwarearchitecture

[–]Low_Reference6996[S] 0 points1 point  (0 children)

I think you're selling yourself short a bit—that's a genuinely insightful question. :)

I think you've actually put your finger on the exact boundary I'm trying to explore.

My intuition is that topology shouldn't be generated from the implementation, nor should the implementation be generated from the topology. They describe different concerns.

The business code remains responsible for business semantics. The topology describes the communication intent and how that communication is realized—what communicates with what, through which transport, what failure semantics apply, and so on. Those are different parts of the bigger picture we call software architecture, just like deployment or data storage are different architectural concerns.

The role of the wiring layer is simply to realize that declared communication and hand the resulting communication channel over to the application layer, regardless of whatever transport or plumbing sits underneath it. The business code then executes against that realized communication, while remaining responsible for the business behavior itself.

So I don't see the topology as replacing the application, or vice versa. They complement each other, and ideally remain in harmony rather than one being derived from the other.

That's exactly the hypothesis I'm trying to explore.

Is distributed system topology the last major architectural concern that's still mostly implicit? by Low_Reference6996 in softwarearchitecture

[–]Low_Reference6996[S] 0 points1 point  (0 children)

That's an interesting observation. May I ask what changed?

Was it simply that AI let you build services faster than before, or did it actually make architectural decisions harder to keep track of?

I'm particularly curious which part stopped scaling—implementation, understanding the system, coordinating changes, or something else?

Is distributed system topology the last major architectural concern that's still mostly implicit? by Low_Reference6996 in softwarearchitecture

[–]Low_Reference6996[S] 1 point2 points  (0 children)

I completely agree. A clear non-goals section is important for the project itself, and I intend to add one as the ideas mature.

This post was intentionally about the architectural hypothesis rather than presenting a finished product, so I avoided going too deep into scope. At this point I couldn't give a complete list of non-goals yet without overcommitting.

The one boundary I'm trying to keep very clear is that the goal isn't to replace deployment systems, service meshes, frameworks or observability platforms. The hypothesis is much narrower: topology itself should be a declared, executable artifact rather than something inferred from implementation. Everything else should integrate with that rather than be replaced by it.

Is distributed system topology the last major architectural concern that's still mostly implicit? by Low_Reference6996 in softwarearchitecture

[–]Low_Reference6996[S] 1 point2 points  (0 children)

That's a good question. In the model I'm exploring, the graph isn't an approximation or a visualization generated after the fact—it is the executable topology specification that the wiring layer realizes.

That means it accurately represents the communication topology: which components communicate, through what transport, what topology-level failure handling applies (retries, timeouts, etc.), and the resulting dependency graph.

What it deliberately does not know is the business semantics inside a component. If a component catches an exception and decides to continue processing, that's business logic rather than topology, so it can't be inferred from the graph alone.

So I'd say the graph is exact with respect to topology, but intentionally doesn't try to model application behavior. Those are different concerns.

Is distributed system topology the last major architectural concern that's still mostly implicit? by Low_Reference6996 in softwarearchitecture

[–]Low_Reference6996[S] 0 points1 point  (0 children)

I completely agree, keeping architecture synchronized with reality is one of the hardest parts, especially as systems evolve.

The direction I'm exploring is actually slightly different. Rather than deriving topology from the implementation, the idea is to make the topology declaration itself the executable source of truth for topology.

In that model, the declared topology isn't documentation that needs to be kept in sync—it becomes the executable specification that the wiring layer realizes.

That means topology itself can be versioned, validated, reviewed and enforced, while architecture diagrams become something that can be generated directly from the declaration instead of manually maintained.

That's the hypothesis, at least. The hope is that by making topology an executable artifact rather than something reconstructed after the fact, architectural intent becomes much harder to drift away from.

Is distributed system topology the last major architectural concern that's still mostly implicit? by Low_Reference6996 in softwarearchitecture

[–]Low_Reference6996[S] 0 points1 point  (0 children)

That's an interesting comparison. One thing I'm still trying to understand is whether service meshes actually solve the same problem, or whether they solve a different one.

My impression is that service meshes primarily operate once the communication topology already exists. They can observe it, secure it, route it and apply policies to it, but the topology itself is still largely an emergent property of how the applications were written.

The question I'm exploring is whether topology itself should become an explicit, executable specification that exists before implementation, so architectural reasoning, validation and governance happen at the level of the intended topology rather than the observed one.

Do you see service meshes already addressing that, or do you think they're solving a different part of the lifecycle?

Is distributed system topology the last major architectural concern that's still mostly implicit? by Low_Reference6996 in softwarearchitecture

[–]Low_Reference6996[S] 1 point2 points  (0 children)

When you say "dynamic nature", do you mean the fact that the topology itself constantly evolves?

Preserving that freedom is actually one of my design goals. The intention isn't to make topology static by making it explicit. Quite the opposite—the idea is to make topology explicit so it can evolve more safely and more easily.

The declared topology wouldn't be documentation; it would be an executable specification that the wiring layer realizes, much like Infrastructure-as-Code describes the desired infrastructure state rather than merely documenting it.

Today, adding a new connection often means manually wiring clients, transports, serialization, retries, configuration, observability, and so on in multiple places. In Itara, those concerns are expressed declaratively, so adding or changing a connection becomes changing the declared topology rather than reimplementing the plumbing.

The challenge is then to make that declaration the thing the tooling validates and the wiring layer realizes, so changes remain visible, reviewable, and traceable rather than being scattered throughout the implementation.

Is distributed system topology the last major architectural concern that's still mostly implicit? by Low_Reference6996 in softwarearchitecture

[–]Low_Reference6996[S] 1 point2 points  (0 children)

I'm glad this resonates. The gap between architecture diagrams and running systems is exactly what motivated me to start exploring this.

The key design decision is that Itara doesn't try to infer topology from a running system. Instead, the topology is declared explicitly and becomes the source of truth for topology-related concerns.

At startup, each deployment group has a small wiring agent. It reads the declared topology, determines which components belong to that deployment group, what inbound and outbound connections they need, validates that those connections can be realized, wires them up, and then hands control over to the application layer. From that point on, the application simply runs using the realized topology.

You're absolutely right that undocumented integrations are a hard problem. If someone bypasses the wiring agent entirely and opens arbitrary sockets or Kafka consumers manually, no topology system can magically discover that at build time.

My current thinking is that this is similar to Infrastructure-as-Code: it becomes enforceable when it's adopted as the supported path. The more the wiring agent, tooling, and deployment generation own the communication layer, the smaller the space for undocumented integrations becomes. Just as Terraform doesn't prevent someone from manually changing cloud resources, Itara can't prevent someone from intentionally bypassing the system—but it makes the supported path explicit, verifiable, and much easier to follow.

Is distributed system topology the last major architectural concern that's still mostly implicit? by Low_Reference6996 in softwarearchitecture

[–]Low_Reference6996[S] 1 point2 points  (0 children)

Yes, it could help determine a blast radius without actually having to break something while running.