Transcending Code, Containers, and Cloud

This article was first published in 2014.


There is always tension between adaptability and structural stability in engineering and possibly life. We want our designs to be highly adaptable. With adaptation, our designs attempt to respond to change, sensed within the environment, intelligently with more change, though far more confined and possibly transient, at least initially.


But there are limits to how far we can accelerate adaptation without putting incredible stress on the environment and the very system contained within. These restrictions apply to structural and behavioral adaptation as it is challenging to decouple the two due to system memory.


Structure is necessary not because we need rigidity but because such structure is the basis for a system’s memory.

There is structure in code and software architecture as a formation of system memory. Sometimes, the memory is formed and tainted in the early development of software in defining modules, classes, and methods. Bones.

Other times, we create these memory structures in composing code and data flows. Blood.


If change were accelerated beyond limits, there would be insufficient time for memory to form around structures, leading ultimately to a breakdown in the system as prediction, in response to change, becomes chaotic. Not only is predictability impacted, but the ability to respond is also impacted because structure is the means for response.

Just imagine the cells in your body were constantly re-organizing in response to stimulus. You would not be able to effect change in the world because you might not have an arm to do so, and we have not even discussed the effectiveness of this in an environment with many other participants undergoing their own set of changes.

The structure of our body is a kind of memory of evolution, but it is also how our memories form after birth.

So structural stability is vital in forming a system’s memory but also leads to limits, which many will eventually find far too restrictive. Who does not want to be a superhuman or X-men character with powers beyond humanly capable? This applies equally to software and the systems that embed and employ such software.


Memory structures are built within and around software throughout development, deployment, and maintenance. They harden and start to inhibit the adaptability in other parts of the system, even as we attempt to create lubricating workarounds. Eventually, any change moves from adaptive to forced structural breakage. At this point, no one wants to take the pain, especially as the risk is even more significant for the system’s overall integrity.


But there is some light at the end of the tunnel for software, as humans have already discovered and applied a solution to overcoming structural limitations or injuries to such structures. Simulation.

In our dreams, we can perform at a level limited only by our imagination, assuming reasoning does not prevail too much in the simulation. Gaming is another form of simulation in which we leave aside our structure and the behavioral patterns and capabilities that form around them. We have extended our physical environments to sense and invariably simulate behavior that assists us.


Why not add similar “super” capabilities to software by having the essence of the software, its behavior, projected to a simulation? Within the simulation, with many running in parallel, we extend the lifetime and reach of the software adaptation, which in an enterprise setting is how integrated the software is with other newer services.

We can imbue the software within the simulation with new system-wide behaviors that would be hard to achieve within the source (reality) software. We have tried this in the past with Aspect Oriented Programming (AOP), but there, we still needed to operate within the structure of the software and in the same space and time.


With simulation, structure need not be present, only the coded adapted response to the simulated behavior.

The simulation can replicate across time and space, and with each incarnation of the simulation, different laws and rules can be applied, allowing newer structures to form. Even in gaming, there is memory formation around skills.

So, if we want to extend the lifetime of software, we must extend the observability and reach of the execution flow contained within it. By projecting such behavior across space and time, we allow ourselves the chance to form new systems that bridge the past, present, and future. Effectively, we move the reaction and response to the simulation, which can be enhanced with newer capabilities, more comprehensive connectivity, and greater resource capacity.