Engineering Velocity

​

One of the tenets of Microbus is to free engineers to do meaningful work and many of the framework's features aim to support that objective, whether during development of the system or while operating it in production.

​

Development Productivity Boosters

​

Local Development

By far the biggest productivity booster is the ability to run and debug an entire solution comprising hundreds of microservices locally. This is made possible by the small memory footprint of Microbus, and its use of a messaging bus for communications.

​

Identical Environments

In Microbus, the development environment is practically identical to the production environment so there are fewer surprises in production and it is easier to reproduce issues when they do occur. "It works on my machine" now means it quite likely works in production.

​

Quick Restart

Microbus applications can be restarted in seconds so engineers can make code changes and iterate quickly.

 

Full Live Integration Tests

Microbus is able to run integration tests comprising both the microservice under test and its downstream dependencies, all inside Go's standard testing framework. In most cases, all microservices are live, not mocked. With such comprehensive testing, fewer bugs make it to production.

​

Code Generated Client Stubs

Client stubs eliminate the need to make requests at the JSON and HTTP level so there's no need to worry about marshaling or request timeouts. In addition to providing type safety, it elevates engineers to spend their time on the business logic rather than the boilerplate mechanics.

​

Code Generated OpenAPI

Every endpoint in Microbus is automatically exposed in an OpenAPI document. Not only does it speed up communication with the frontend team, it also creates a public API that customers can use.

​

Uniform Code Structure

The code generator creates a similar structure for all microservices, which makes every microservice instantly familiar to every engineer.

​

Reduced Communication Overhead

Brooks's law states that adding manpower to a late software project makes it later, mainly because communication overhead increases as the number of people increases. By making engineers more productive, Microbus allows teams to run leaner, thus boosting productivity even more from the elimination of the communication overhead.

​

Short Learning Curve

Microbus is easy to learn. The tech stack is small and features are exposed via a simple API. Ramping up new team members, even junior ones, is a snap.

​

Happy Engineers

Engineers are happier when they produce meaningful work that translates to customer value. Happier engineers are more motivated.

Events

Events are a powerful pattern that is often neglected in microservice architecture because it is rather different than the more familiar HTTP. Microbus brings events into the mainstream by overlaying them with the familiar HTTP semantics.

​

Almost Zero Config

Setting up a working system requires very little configuration.

​

Operational Productivity Boosters

​

Small Tech Stack

Microbus relies on very few third-party systems, with only the messaging bus being a hard dependency. The small tech stack means there are fewer systems to install and maintain (upgrade, patch for CVEs, etc.), which translates to reduced operational workload and cost.

​

Adaptable Topology

Microbus's adaptable topology allow taking on complexity when it is justified, and not sooner. A Microbus application can be deployed as a standalone monolithic executable first, switched to a distributed monolith, then to Kubernetes, as the needs of grow, with no code changes. 

​

Rock Solid Transport

The underlying transport used by Microbus is rock solid and doesn't suffer from finicky networking issues. There is no need to introduce  delicate port mappings, IP routing tables, or external load balancing. All is handled internally by the framework.

​

No Mystery Incidents

The conventional tech stack is a jumble of systems that no one truly fully understands. Quite often it is extremely difficult to identify the root cause of an incident because it can be at the cloud provider, Kubernetes, service mesh, eBPF networking or the interoperation of any of these systems. "Turning it off and on again" is not good engineering.

 

Precision Observability

Observability tools provide visibility into system internals that make it easy to identify and fix bugs with precision.

​

No Crashes

Bugs do happen, but a microservice will not crash. All errors and panics are captured.

​​