Deployments, Growing The Digital Multiverse

Continuing the story we began in versioning, we will continue to explore the concept of a software project as a digital multiverse. Although it was less explicit, the beginning of this story was really in sources of truth. In sources of truth, I used the example of a mobile app that is offline-first, meaning that it does not require an internet connection in order to facilitate a digital experience, although an internet connection may certainly improve it in one or more ways. In that simplified example the pool of truths were: "hardcoded" truths embedded as part of the app itself, saved files that the app may update over time as it used, and an online service to support the app, e.g. The Cloud.

In real world projects, the total pool of sources of truth can be significantly larger. There are often practical reasons for this - the division of labour in action once again. Application developers would like to remotely toggle features on/off for users, collect information about how users interact with the UI, ask third-party authorities about the weather in the current location, query the device running software for its current operating temperature. Modern software applications query all kinds of services for all kinds of different reasons, resulting in sophisticated supply chains.

To complicate things further still, for ongoing software projects it is common practice to operate multiple parallel tracks. Let's work backwards to why that is the case. When we know that we will release a project to a large audience, one of the things we are generally very interested in is stability, to the fullest extent possible. If we intend to make ongoing changes, we would prefer to do so in an isolated environment, so that when we alter the deal with our former selves, existing users should not bear the burden. So that's at least two environments. Some stop there. More common is at least one more. Often there is another party, perhaps a client of an agency, or other staff at the company developing the project with an interest in previewing the changes before they make it to the general public. For similar reasons relating to stability, as developers continue working while this preview takes place and new features are still being developed (maybe even with more altering the deal) we tend to be interested in insulating those people from instability as well. And so it is that we often end up with three environments.

This is not the end.

The configuration of these environments is often at least in part a manual process, and not everything is duplicated across each instance. Like code, this is an area where tradeoffs happen - data integrity is generally less important than time to set up an environment and the cost of maintaining it. For example, when collecting analytics we care a great deal about the data integrity of public-facing software (often referred to as a production environment), we want to understand the behaviour of users and what they really care about and we make decisions based on that. If it is wildly incorrect that could be disastrous. In any non-production environment, we hardly care at all. At least only to the point of validating that events are recorded in the manner in which we expect. And so what often happens in a situation such as this is that sources of truth are recycled between environments. These parallel tracks in practice are not quite identical.

There are other forces driving non-homogenous environments - depending on technological choices, running multiple environments could be incredibly expensive. To reduce costs, the computing resources allocated to these alternative environments with lower usage than a public-facing app may be much lower, perhaps so low that it no longer reflects the typical user experience once it hits production. This can put quality assurance staff in a difficult position, who will often use one of these alternate environments to perform tests, and will find themselves in the position of being asked to confirm that a particular change has been developed successfully without the opportunity to see it work as intended. Not so different from the position that developers often find themselves in with respect to estimating the work, as mentioned in breaking the work up.

There's still a little more expansion to come for the digital multiverse.

Until next time.