Why we built a new network

A few weeks back we announced the name of our new Allograph network at our regular monthly Delivery Brief livestream. Internally we had been referring to the development effort as HPOSv2 and externally we were calling it the ‘next-gen network’ and we sought to choose a unique name with a little more color. What is Allograph then? Why is it important to us and our stakeholders?

Allograph is the name we have given to refer to the latest instantiated Holo network. In other words, it’s a subset of HoloPorts using a new network infrastructure architecture. At the same time, we still use the Legacy Holo network for paying customers. A network in this context is simply a collection of globally distributed computers (HoloPorts) that can be managed for various intents and purposes using the same layer of networking infrastructure. Holo currently sells hosting services on both Allograph and the Legacy network, but regardless, all HoloPorts can be said to be under the larger umbrella of the Holo Hosting network. In the future there will just be Allograph as we eventually phase out the Legacy network.

The Legacy Network was purpose-built for the fully integrated peer-to-peer solution as detailed in the Holo Green Paper.

As such, we set ourselves up to build something of a monolithic system. As monoliths age and add features, they experience challenges with fragility, degraded performance, and slow development cycles. The Legacy architecture also had the assumption built-in that every application would always be running the same major version of Holochain. That would be less problematic if the version updates were infrequent.

In software development iteration is a fact of life, an unavoidable necessity that is part of improving the code. When Holo needs new Holochain features to progress forward on its roadmap, it often requires a bump to a new Holochain version. The same could be said of fixes. Sometimes fixes could be backported into previous Holochain versions, but in general, incorporation of fixes usually precipitated a cascading development effort for Holo that entailed managing a complex web of downstream dependencies in Holo’s Legacy tech stack. In hindsight, we spent much of our engineering time and resources on the handling of Holochain version bumps.

Additionally, because the Legacy architecture had the assumption that everyone would be on the same major version of Holochain, it put Holo in the uncomfortable position of enforcing Holochain version consensus with its users. Anyone who wanted to host on Holo needed to align their development timetable and needs to ours. We dictated which Holochain version needed to be used, and projects would have to upgrade when we asked them to, or delay upgrades according to our readiness.

Holo’s new Allograph Network turns all of the above on its head. We’ve decoupled everywhere we can to resolve monolith issues. Following systems engineering best practices, our new architecture allows us to offer customers exactly what they want. We can provide each customer with exactly the version of Holochain they need, including their own custom versions. Soon, we’ll be able to provide customers with hosting for any workload that can be Nix-containerized, not just Holochain application hosting. We can also develop our own infrastructure at a much more rapid pace as we have drastically simplified our own Holochain dependency tree while still being ready for future Holochain and HoloFuel integration.