Show HN: Itara – Distributed system topology as an explicit, executable layer
github.com
I spent almost a decade designing, building and maintaining distributed systems, and I came to truly understand why a lot of people define software architecture as "the stuff that's hard to change later". Changing service boundaries, communication protocol or serializers is time consuming and risky. The past few months, I've been building Itara, my attempt to ease that pain.
Itara takes the software topology that's currently spread across the codebase and configuration and infrastructure, and concentrates it into a dedicated, executable layer. This dedicated layer describes the topology as a directed graph, where the nodes are the components of the system, and the edges are the connections between them. The edges have all the properties of the connection, like the transport to use, the serializer to use, the failure handling strategy and so on. Colocated components, components running in the same process, are modelled with direct connections.
This gives me an accurate map of my topology, lets me change the topology without changing the business code, and keeps communication logic separate from business logic while still giving me direct control over the configuration, avoiding the network fallacies.
In Itara, each component consists of an API the other components can build against, and an implementation that actually implements the business logic. Event-driven design is supported through dedicated events APIs.
For each deployment unit, a wiring agent runs at startup to prepare the communication channels as specified by the wiring config. These channels implement the component APIs and are used by the application like regular interfaces. There is no runtime overhead, except for the structural observability events, because the wiring agent steps aside after startup.
The project aims to be language agnostic. The current implementation supports Java, with a Rust implementation at proof-of-concept level.
I collected a few common questions and their answers in an FAQ: https://github.com/itara-project/itara/blob/main/docs/FAQ.md
I prepared a demo, an order processing system that consists of 5 components, one of them written in Rust, communicating through HTTP and Kafka events. The demo shows that to change the topology, only the wiring file and the docker compose file need to change, the application code can stay the same. It also includes a deliberately flaky transport to demonstrate failure handling. The traces make the topology changes directly visible. Link to the demo: https://github.com/itara-project/itara/tree/main/demo
I'd appreciate your feedback! Does this solve a problem you've encountered? What parts of the direction resonate with you, and where do you think it falls short?
The spec, manifesto, and architecture docs are in the repo: https://github.com/itara-project/itara