Microservice Substrate
The substrate is the production-grade microservice fabric on which every Microbus solution runs - and what makes the agentic pitch true. Workflows, coding agents, and LLM tooling all sit on top of this substrate; their security, scale, observability and reliability properties come from it, not from above.
A Microbus solution comprises 5 layers:
- OSS - At the bottom of the stack is a curated selection of OSS technologies that are utilized and abstracted by the next layer, the
Connector - Connector - The
Connectoris the base construct from which all microservices are derived. It provides a consistent API to most of the building blocks that are required for a microservice to operate and mesh with other microservices. Quite often these building blocks rely on the OSS under the hood - Coding Agents - Coding agents build on top of the
Connectorand generate code that is specific to the semantics of each individual microservice - Microservices - The core microservices and the solution microservices are built using the coding agent
- Applications - Microservices are co-located inside applications according to the desired topology
Uniform Runtime
All microservices running on Microbus comply with the same set of rules for unicast or multicast communications, configuration, observability, and more. This consistent behavior makes it easier to reason about the accuracy of the system, guaranteeing smooth interoperability, straightforward maintainability and verifiable stability.
Performant
Benchmarks indicate Microbus is capable of processing upward of 94,500 req/sec on a 10-core MacBook Pro M1 CPU, connected to a messaging bus on localhost.
Reliable
Reliable communication is an imperative quality of any distributed system. In Microbus, microservices communicate with each other over a messaging bus. Each microservice connects to the bus over a persistent multiplexed connection that is monitored constantly and kept alive with automatic reconnects if required. Locality-aware routing, ack or fail fast and graceful shutdowns further enhance the reliability of communications.
It is also imperative that a distributed system remain online at all times. Microbus achieves that by capturing all errors and panics so that malfunctioning microservices do not crash.
As a framework, Microbus is expected to run business-critical solutions. It is thoroughly tested by hundreds of unit tests.
Horizontally Scalable
Components at all layers of Microbus are horizontally scalable. There are no single points of failure or bottlenecks. At the transport layer, the messaging bus forms a full mesh so that any message traverses no more than two nodes regardless of the size of the cluster. At the application layer, dynamic service discovery makes it trivial to add replicas of microservices and scale the solution.
Standards-conformant
Microbus conforms to industry standards.
- Communication over the bus conforms to the HTTP protocol
- Observability data is pushed to OpenTelemetry collectors
- OpenAPI documents are automatically created for each microservice
Interoperable
Because Microbus conforms to the familiar HTTP protocol for service-to-service communications, it is a snap to process incoming HTTP requests from non-Microbus services or from JavaScript clients, or conversely make an outbound call to non-Microbus microservices or third-party web services.
Microbus is easily deployable as containers running on a Kubernetes cluster.