One large depth-of-field domain I spend a great deal of time in is the study of #Observability.
As with any large depth-of-field domain, it's important to understand its taxonomy, ontology, and orthogonal attributes to truly appreciate its potential in an organization (I may break down these areas in a subsequent post), but sufficed to say that this is a field that can catalyze a number of areas such as resilience engineering (itself a fascinating field), chaos engineering and Testing in Production (TiP), software regression & performance management, and of course supporting the efforts of SREs.
When progressive Platform Engineering teams focus on workflows vs products some pretty powerful things happen. These focused teams are able to facilitate the propagation of context at the service edge, introduce the use of exemplars and log linking, and provide full-fidelity data to perform activities such as distributed traces - and this, coupled with other functions, delivers a supercharging effect for SRE teams.
InfoQ recently published an article (https://lnkd.in/dyn2Nyxm) which among other topics, describes an API tax whereby a recommendation emerges to wrap API calls into workflows to reduce investment time and accumulated tech debt. This is an area I advocate heavily for and agree with completely, and in the case of observability, we can use these ideas to extend and integrate value into the SRE workspace.
Reach out and let's explore how we can use an OpsService Layer along with #chatops to create workflows that SREs and Developers care about!
