I’ve long fascinated over how best to perceive the behavior of software machines that for the most part appear as black boxes; consuming input we feed them and producing output we consume, directly or indirectly. I cannot help feeling there is a lost beauty in the motion of action that needs to be rediscovered in order to acquire a far greater understanding of what it is that software and hardware machines do and how in the course of action(s) and state changes (encompassing the environment) such a system changes behavior in ways not observed, or accurately predicted nor fully understood.
A proposal for a different approach to application performance monitoring that is far more efficient, effective, extensible and eventual than traditional legacy approaches based on metrics and event logging. Instead of seeing logging and metrics as primary datasources for monitoring solutions we should instead see them as a form of human inquiry over some software execution behavior that is happening or has happened. With this is mind it becomes clear that logging and metrics do not serve as a complete, contextual and comprehensive representation of software execution behavior.
Software memories allow us to employ multiple techniques of discovery and they are not limited to what we know today and what tools and techniques are available to us at this time. If software machine (behavioral) memories can always be simulated with the ability to augment each playback of a simulation then there are no limits to what questions can be asked of the past in the present and future.
The following is a graphic I’ve used in the past to frame various software performance optimization techniques. It is not a comprehensive inventory of all software performance optimization techniques (or concerns) but I’ve found it serves a purpose in managing the amount of effort that, in general, should be spent on each technique outside of extreme cases such as trading platforms (or profilers). The left side is your typical localized bottom up approach to speeding up code execution steps. Most developers involved in performance improvement efforts start on the left side because it feels less abstract and much more tangible than system dynamics or software adaptation, both of which require a much higher level of understanding of exactly what does happen outside of the code editor.
The Good Regulator Theorem states “every good regulator of a system must be a model of that system”. But what exactly would such a model look like? What elements should the model contain and how might they be related and reasoned about? The theorem itself does not address this so in this article I present my own research findings covering dramatism, observational learning, experiential learning, activity theory, simulation theory and mirror neurons as well as software activity metering and software performance measurement.
Essentially we need a model of human and software understanding based on activities actioned by actors within an environment supporting observation and perception of such acts including the situational context surrounding them, both before and after. An actor, not in the sense of the actor programming model, produces, begins and ends, an action in response to, or in anticipation of, some stimulus (action, signal or event), which could very well be mapped to a service, thread, process, system or human (by proxy).
“They [autoletics] are more autonomous and independent because they cannot be as easily manipulated with threats or rewards from the outside. At the same time, they are more involved with everything around them because they are fully immersed in the current of life.”
FLOW: THE PSYCHOLOGY OF HAPPINESS
To fight current levels of complexity in IT systems we must look to imbue software with the ability to sense, perceive, reason and act locally with immediacy.
Software must adapt not simply react. Feedback signals need to flow freely across machine boundaries as well as man-and-machine interfaces.
MIRRORED SOFTWARE SIMULATION
In projecting software execution behavior and contextual state across space and time software engineers have the capability to develop new and augmented systems that bridge the past, present and future, allowing software machines to transcend structures formed in the early stages of design and over the course of extemporaneous reactive change.
SOFTWARE MACHINE MEMORIES
Your hardware has memory but your software has no memories.
What if software could recall past memories for the purpose of learning?
What if we could observe machine memories to more effectively reason about complex software execution behavior?
SOFTWARE SYSTEM ENGINEERING
INTELLIGENT ADAPTIVE MONITORING
Using self-adaptive instrumentation and measurement tooling, performance and scalability problem identification is all but guaranteed. Within a matter of minutes, measuring a representative workload, various potential bottlenecks and optimization calls sites will be accurately identified.
SOFTWARE PERFORMANCE VISUALIZED
Efficient data collection coupled with unique software execution visualizations ensures that all parties involved in a performance investigation will gain an unprecedented insight into the execution nature and resource consumption patterns of applications and more importantly, a high degree of confidence in report findings.
POST EXECUTION ANALYSIS
Through distributed software recording and simulated playback the time spent in performance measuring an application under observation and analysis is greatly reduced. This allows much of the investigative work to be moved outside of business critical operating windows.