Learn about the need for a unified application networking platform for distributed application development.
Microservices applications are the most common and complex type of distributed application being built today...We are all now building distributed systems!
— Christopher Meiklejohn
Delivering innovative customer experiences today requires the real-time networked connection of people, process, data and things (devices).
But creating those connections has become shockingly complicated due to the sheer number of infrastructure components, associated protocols, APIs and client libraries involved in most modern application development.
If you are using a microservices architectural style or if you are integrating multiple different customer/user touchpoints across Web, Mobile (and possibly IoT devices) you are developing a distributed application.
Distributed applications are very hard to design, develop and maintain. They require multiple application communication patterns such as Remote Procedure Call (RPC) for point-to-point synchronous request-response and Publish/Subscribe for many-to-many asynchronous communications. Unfortunately, this is where things get really complicated, because typically each pattern requires separate frameworks and infrastructure components e.g. HTTP Gateway, Authentication and Authorization services, gRPC, service mesh, message brokers (a.k.a. event mesh).
Moreover, most of these frameworks and infrastructre components were designed for the 3-tier application monoliths of a not so distant past but not really for the integration of 100s and in some cases even 1000s of microservices deployed on a cloud-native infrastructure.
The decomposition of the monolithic applications allowed us to scale the social aspects of development, enabling us to tackle the increasing number of requirements―essential complexity―but due to the tools we are using we have now created a massive wave of accidental complexity.
The result in a complex technology solution prone to inefficiencies, delays and fatigue hindering the success of business initiatives as developers have to cope with too many protocols, client libraries, cloud services and infrastructure components.
But, why are we doing this? Because most protocols where designed as silos, covering a very specific application use case or requirement.
Bondy is our contribution to solve the problem and it was born out of our own necessity. We have used Bondy in production for several years achieving a reduction in accidental complexity leading to a reduction in time-to-market.
Bondy brings back the joy to distributed application development.
Christopher Meiklejohn, Strangeloop 2022 Resilient Microservices without the Chaos ↩︎
Stephen O'Grady, The Developer Experience Gap ↩︎
In No Silver Bullet — Essence and Accident in Software Engineering, Fred Brooks distinguishes between two different types of complexity: accidental complexity and essential complexity. Essential complexity is caused by the problem to be solved, and nothing can remove it. Accidental complexity relates to problems which engineers create and can fix; for example, the details of writing and optimizing assembly code or the delays caused by batch processing. ↩︎