The increasing complexity of containerized software libraries means the author consumer divide has never been wider.
You probably started with the README to get an idea of what the thing is, installed it via your favorite package manager, and then did some combination of the following:
With time, you wanted more from the library and started to expand your knowledge of it. The rationale behind initially confusing functions became apparent. Eventually, you might have even become a power user.
When you first started, there was a knowledge divide between the library's author, who knows where everything is and how it works, and you, the consumer. You needed to bridge some of that divide to start with the library. As time passed and you wanted more from the library, you closed that gap further. Let’s call this gap the author-consumer divide.
The author-consumer divide is unavoidable, as it must be crossed by anyone looking to use any piece of software. I assert that the author-consumer divide is much harder to cross today than it was 10 years ago, and this is significantly hampering modern software delivery.
To see why, let’s first consider how to cross the divide in the world of software libraries.
With many software libraries, it's quite feasible to learn a library simply by importing it and exploring the public API.
Now consider the modern world of containerized services. A containerized service can be thought of as the cloud-native equivalent of a software library: it is instantiated, it has functions (endpoints) that are callable, the functions have arguments and return values which have a structure to them, and its API is likely versioned.
Yet you (the consumer) have to work much harder to accomplish the same outcome on a containerized service.
From the size of the rightmost column alone, it’s no wonder that many developers prefer to work with raw binaries over containers.
Fortunately, these problems largely result from the recency of containerization relative to regular software libraries and the corresponding gap in tooling development. For example, the package managers that are now ubiquitous in programming language ecosystems were only developed in the 1990s, the first documentation generators were developed around the same time, and modern IDE debuggers are more recent still. The containerized world has yet to catch up, and the pain of crossing the author-consumer divide is but one symptom.
We’re building the Kurtosis tooling to solve this pain and make building distributed applications as easy as building single-server apps. The next post in this series will discuss the principles we're designing around as we build.
Until then, check out our github to learn more.
We're in build mode at Kurtosis. Follow along for the latest.