In part 5 of our series, we shift gears and look at what else we can learn from our Automated Discovery and Understanding tools (ADU), to speed remediation of production issues to minimize downtime and maximize availability.
This week we’re looking at:
- A picture paints a thousand words – using application visualization to get rapid understanding
- No application is an island – understanding application ecosystems at runtime
Graphical presentation of information has always been more efficient in communicating the structure and interdependency of ideas. What we see in modern applications, through exploitation of reuse, SOA and similar design constructs, is massive simplification of individual components but an exponential growth in the volume and complexity of applications. We are far past the point today where we can comprehend the impact of a change to one component because it may be reused many times over, and not just in our application but, perhaps, as a remote service.
My patent “Approach for proactive notification of contract changes in a software service” (Number 7,934,221) addresses this issue reactively, by making the contract between caller and callee include a handshake of version information. This deals with the issue that dynamically called services may not be aware if the contract between them has changed and enables the calling program to take corrective action if the change is not benign. What we need is to manage this proactively: when the program is deployed in production it is too late.
Being able to visualize all the calling programs and their relationship to called routines is at the heart of this.
Now extend this idea to the next logical step. Not just programs but the documents that refer to them, the requirements that define them, projects that enhance them, the scripts that invoke them, the triggers that initiate them, the data sources and message queues that feed them, the containers and operating systems run them, and the hardware that sustain them. Now we can see the connections in Dev, in Ops and even in the Business.
Uptime and availability
Appropriately, we need to make sure we don’t miss the Ops in DevOps. This week we look at how application understanding can improve Ops’ ability predict and prevent bad things happening, and, if they do, how they can be analyzed quickly and fixes found fast.
When I was an on-call “trouble-shooter” *, the first thing I would ask, at 3:00 am as I entered the data center was “What changed?” In those days a good operator would know everything and would suggest the most probable starting point. Today, with separation of duties (SoD), n-tier applications, automated application monitoring, and myriad ways of connecting to, and interacting with corporate systems, the number and variety of sources that contain change-information is dizzying. Those sources all have different access methods, tools and formats.
Being able to collect together all those sources in the form of metadata, link those data logically, and make them available for real-time interrogation means that one can quickly discover:
- Prior state – the state of the configuration prior to the change
- Current state
- The delta between the prior and current state
- Timeline – the order in which the changes were made
- Audit trail – who, what, why, where, when and how
Because the data are linked, in the right tool, rapid and automated analysis of what happened can be achieved. Moreover, the automation allows for continuous reporting on status changes and enables trending reports. Through this mechanism we can start to inform proactively the Dev and Ops teams about the current state of out applications. Offering insights about the changing parameters of our application in real-time.
*As a new programmer, fresh from college, I was a “trouble-maker” according to my boss. A few years later I was happy to graduate to “trouble-shooter” and receive a call-out bonus and the glory of diagnosing and fixing production problems. Looking back, the midnight ride of the trouble-shooter, the “hero culture”, was the wrong answer to the problem. Not letting the application fail in the first place should have been the focus, not fixing it afterwards.
The application in time and space
When we think about our application, we see it as a productive set of processes delivering value to the user and the customer. Over time it exists in many variants and executes upon one or more platforms. To transform from one version to another it undergoes design, development and test cycles. This means that the application is in a constant state of change (in development) and snapshots of the application execute (in production) and these are happening simultaneously.
We have seen how we can interrogate the application metadata to help inform us about the impact of the changes we are about to make. We can also monitor the cumulative effect of change over time and see the increase in application volume (lines of code), complexity, defect density, complexity and many other vectors.
If we can extend this idea to Dev, Test, Deployment, Release and Delivery - to all the stages of the DevOps process - we can create a practice whereby we are reporting insights as they happen to the teams responsible for application development. We can set thresholds that cause alarms and alert the project and portfolio management teams.
Similarly, we can provide advance notice to the Ops teams when new data sources, security requirements and other operations changes are being made in the application during its development phase so that preparation can be made to accommodate them.
As we shall see in the next post, feedback is important but feed-forward is essential.
Next time we’ll bring it all together:
- Look at the central role of application discovery and understanding (ADU) tools in DevOps
- Make the case for automated application discovery, understanding and monitoring (ADU-M)
- Introduce the idea of feedforward loops
All this content will be available shortly in an eBook on the IN-COM website. We’ll also provide additional content that you can use immediately to learn more about why Application Understanding is essential for modern application developers.