Takeaway Containers
Docker containers and McDonalds are interchangeable when it comes to the pursuit of consistency.
There is a comforting familiarity that pervades the moment one steps into a fast food venue. The burger combo with the lot, the secret sauce, that crispy, salty, mouth-watering deep-fried goodness. We know immediately what to expect though we’ve never been. Barring natural variance, we can roughly expect the same from the different, yet same, outlets.
As such, franchises are very good examples of containerisation. It is no coincidence, but rather a conscious, borderline obsessive effort of branding. A franchise as per its contract seeks to replicate its primary system where preparation, presentation, and procedures are by the handbook.
In much of the same way (or even more obsessively) we containerise. A well-contained software has what’s considered as everything that’s part of the app within one container: the product, of course, and the external products that it needs to operate. In this way we know to expect that it will run the same way, and be assured that it will run. Doing so allows us to do away with reconfiguring everytime we establish a new instance: it is now a pre-set system, contained with all its dangling bits, ready to be replicated — a prerequisite to scalability.
It was at this point that it occurred to me that perhaps it is more appropriate to equate containerisation to the idea of the business operations of a franchise, since the setup of the physical space itself requires reconfiguration as it’s very likely that the space will be different, just shaped to be somewhat the same.
In software and in the formulation of a franchise there are trials and errors to find the just-right mix. The difference is that in the digital, installation of an unsuitable module has an immediate effect; be it that nothing works, or more dangerously: the ever-present, subtler bugs. Although in retrospect… the analog experiences that immediate effect too, as any customers angered over the change in sauce formulations can attest to. Submitting a fix to the analog system, however, includes a major lag, as it can’t be almost instantaneous as the system we are used to.
If that is what we’re used to, small wonder that we’re becoming increasingly impatient, forgetting that the analog demands allowance for delay as operating time runs more slowly there, and there is where we live.
Perhaps even more problematic is that for all its goodness, this speed of testing for a winning combination alludes to the superiority of the throwaway method in leading us to the valley of minima, teaching us that attachment is detrimental. It is beneficial; very much so, but one should take precautions to not take it to the extreme, like a pragmatic on pure logic.
That in turn for the worst, we value things less because they are increasingly replaceable.
Of franchises and software containers, the good product becomes bad without proper setups due to the simple fact that nobody’s able to use it.
Conversely no matter how smooth the software runs or how continuous the deployment is, if the product itself is no good, it still won’t survive.