Chapter 6. Source Code Observability

Achieving safe delivery via pipelines or some other repeatable process is a step forward. It helps, though, to look forward to how you can observe the state of the running system beginning with deployed assets. Too much of a focus on just the pipeline itself could leave you without a means to inventory your suite of deployed assets later.

Source code is just as important to monitor as live processes. In an organization’s source code, dependencies between internal components and third-party libraries are specified. Small changes in dependencies can render an application unusable. Patterns are found to repeat across an organization as developers emulate the work they see done elsewhere. Even patterns that expose attack vectors into your organization are emulated until an awareness of a vulnerability is developed. In codebases of a significant enough size, even the smallest API change can seem like an insurmountable task.

In the Netflix codebase, we found Guava version drift across deep dependency trees to be almost crippling at times. An attempt to make a shift from one logging library to another across the whole codebase had taken years and was still not achieved until an organization-wide refactoring solution was developed.

Another significant challenge is identifying what code is actually deployed where across a myriad of environments. As your organization makes advances in continuous delivery, for example, the possibility of rollbacks means ...

Get SRE with Java Microservices now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.