Observability hierarchy of needs: Introduction

Welcome to part 1 in a series of blogs on Observability’s Hierarchy of Needs!

It is not a long shot to say we live in a world where data is paramount. The past decade has witnessed an exponential increase in cloud native workloads. As organizations begin to embrace the simplicity and rapid scale out provided by the cloud, it is important to be mindful of the challenges it introduces:

• Data generation: Since the cloud is someone else’s infrastructure, it is extremely simple to deploy workloads. CI/CD pipelines can be deployed, torn down, and redeployed again in a matter of minutes.  Be careful! The cloud’s simplicity can be a double-edged sword, generating gigabytes of event data (and big bills)!
• Data analysis: It is important to periodically revisit processes and draw meaningful inferences that lead to improved productivity/performance.

What are some technological advancements modern day engineers have adopted?

First there was bare metal. Traditional workloads were designed to be monoliths that ran on bare metal instances (AKA physical servers). An entire physical server would be dedicated to a given workload. This prompted engineers to look for more resource-efficient ways.

Then came Virtual Machines. As part of a continuing quest to optimize resource utilization and parallelize development, engineering teams have been tasked with migrating/re-architecturing workloads. 

Running workloads on Virtual Machines, as opposed to bare metal servers offered portability (move workloads b/w VMs), flexibility (spin/destroy VMs with ease), cost efficiency (VMs can be smaller and are created with resource utilization in mind), and much more. Virtualization teams became responsible for converting bare metal physical servers they owned into hypervisors, making it possible to run hundreds of VMs on a single physical machine.

Consume on-demand: Enter the cloud. The advent of cloud computing changed the way organizations looked at infrastructure management. There was now a convenient way to NOT pay costs upfront to own physical hardware and instead adopt a pay-as-you-go model.

Cloud computing kicked off conversations on paradigm shifts. Engineers appreciated the flexibility the cloud provided (consume resources when you need them, destroy them when you are done!). Multi Tenancy became easier to implement. Cloud Service Providers (CSPs) began embarking on building ecosystems; all three major CSPs have a self-service catalog today.

Teams soon started realizing that consuming resources on the cloud tended to be expensive. In addition, it became apparent that VMs were not as “efficient” as they could be. 

This resulted in the shift from VMs to containers. Arguably more challenging, containers offered many advantages:

• Smaller resource footprint than VMs: Containers took resource optimization one step further. Package your workload and the binaries it requires, and you are all set!
• Build once, run anywhere: Container images are easy to create. Storing images on a cloud provider is just as simple. Moreover, the immutable nature of container images allows one to spin up a container across multiple environments (deploying containers does not change significantly no matter where they run, whether it be a Rancher cluster on-prem, or a GKE cluster) without requiring a complete overhaul of process.

Amidst all the conversations on resource optimization and agility, a need was identified for making systems administration easier. Source code management with Git popularized the declarative approach for software development. Why could the same not be a reality for infrastructure management?

Enter GitOps! Defined as an approach that takes “DevOps best practices (such as version control and CI/CD) and applies them for infrastructure automation”, GitOps extended declarative management to infrastructure.

Starring reusable templates (YAMLs, .TFs, and much more), GitOps revolutionized infrastructure automation; teams could now build, deploy, tear down, and upgrade entire environments with reusable manifests.

With GitOps, Kubernetes clusters can be managed declaratively, using manifests placed in a Git repository. Moreover, manifests are commits in a Git repository, making rollbacks a piece of cake. Change management is simpler than ever before; kicking off a Flux run/ArgoCD run is all that needs to be done to apply changes!

As this blog shows, there have been several technological advancements in the past couple of decades. There is an undeniable corollary in this story: data is king. Embarking on a journey of digital transformation generates a ton of data and requires periodic analysis to understand how well it works. Concerns WILL be identified on cost, resource utilization, and velocity.

Fear not! Observability is key to a productive organization. Feedback makes the world go around! To increase productivity is to necessitate change, and periodically examine what said change to process looks like.

Unsure where to begin? Do not worry! We’re going to introduce you to the Observability Hierarchy of Needs as shown in the figure below.

The five layers shown in the pyramid represent key areas of focus when it comes to building a winning observability strategy. Part 2 in this blog series will talk about the Data layer (data collection, standardization, access). Part 3 will take a closer look at Alerts and notifications, and how they can help ensure high availability. Dashboards are great to visualize data and draw insights! Part 4 will touch on Dashboards and trend analysis. With growth comes scale-out! Part 5 will look at ways to ensure high availability and reliability for large scale workloads. Finally, part 6 is all about Control, the hardest need to attain.

Stay tuned to read part 2 of this blog series, where we will cover the “Data” layer.