In cloud-native environments, such as public cloud offerings like AWS or on-premises infrastructure (e.g., a Kubernetes cluster), one typically deals with many moving parts. These parts range from the infrastructure layer, including compute (e.g., VMs or containers) and databases, to the application code you own.
Depending on your role and the environment, you may be responsible for any number of the pieces in the puzzle. Let’s have a look at a concrete example: consider a serverless Kubernetes environment in a cloud provider. In this case, both the Kubernetes control plane and the data plane (the worker nodes) are managed for you, which means you can focus on your application code in terms of operations.
No matter what part you’re responsible for, you want to know what’s going on so that you can react to and, ideally, even proactively manage situations such as a sudden usage spike (because the marketing department launched a 25%-off campaign without telling you) or due to a third-party integration failing and impacting your application. The scope of components you own or can directly influence determines what you should be focusing on in terms of observability.