Observability as code simplifies your life

30,000 years. That's how long it took before someone invented a way to automate the slicing of bread. Otto Frederick Rohwedder invented the first bread slicing machine only relatively recently in 1928. So the phrase "best thing since sliced bread" might not be as old as you imagine. 

With pre-sliced bread, you don’t need to get out a breadboard, find a knife, slice a no-doubt wonky piece of bread, and clear up the crumbs afterward. Sliced bread reduces your MTTT (mean time to toast) and generally improves your breakfast experience.

Double, double toil and trouble

Pre-sliced bread solves a simple problem: toil. 

Toil,  noun—very hard or unpleasant work, especially work that makes you feel physically tired.

Others might call it tedium, labor, exertion, drudgery, and grind.

Whatever you call it, this toil is frustrating. Tedious chores are boring and annoying. Laborious work causes errors and mistakes. Drudgery makes us look out the window at greener grass. Struggle incites lethargy. Difficult and unpleasant work slows us down. Toil is pain. Toil is a part of an evil spell cooked up by witches. Toil is the enemy.

Whether it's slicing bread or configuring alerting thresholds, the more tedious work that's involved, the less we want to do it. Coding might not be physical work, but mental toil drains teams of energy physically. This can seriously hamper those wanting to scale observability tools and practices across their organizations as they navigate the change management “valley of despair.”

The change management valley of despair

Implementing any tool within a system inevitably incurs a certain amount of debt. It's incredibly rare to deploy something that never needs updating or maintaining, and observability tools are no different. As your platform and products evolve, so must your observability tooling. Those alerts and dashboards created when the product went live no longer make sense now the new feature has shipped. How are you going to maintain them?

Here’s a common pattern I see, not just with observability tools but with any new technology adopted. Perhaps it's familiar to you, too?

Rainbows and unicorns

Excitable pioneering teams jump on the new tech like kids in a sweet shop because it's shiny and new with tons of potential, installing and configuring it to realize copious amounts of value and generally make their lives better. Everything is set up and works like a dream. It’s all rainbows and unicorns playing in the sun...

The storm moves in

And then some time passes, the excitement wanes, and the storm clouds gather over the valley of despair. There are so many things to change and update! New teams eagerly looking in from the sidelines, who missed out on green-field exploration and fun, become aware of the dark side. No fun and excitement for them. It's hard work, it's out of date, and it's too much effort. It's toil, the enemy!

Automating observability is the antidote to toil

As we've learned from the bread slicer, we can combat toil with automation. A New Relic-branded bread slicer probably won't help you much, but embracing automation of your New Relic deployment will.

“Observability as code” is a term that shares a lot in common with the more familiar  “infrastructure as code.” It represents a shift of intention: away from a world of manual, toilsome administration to an auditable code-managed solution that drastically reduces the work involved in maintaining and developing a configuration.

Primarily through our graphQL APIs and in tandem with our Terraform provider, you can manage your dashboards, incident workflows, synthetics, and pretty much any other New Relic resource, through code.

The introduction of observability as code can drastically reduce the toil and overhead in managing your New Relic deployment. No longer do skill-siloed individuals need to make changes manually, pointing and clicking through numerous screens leaving a trail of mistakes and errors as they go.

You can simplify settings and configuration then package and release them together. The changes are auditable, historically documented, peer-reviewed, and subject to an approval process just like your own development releases.

Sharing configuration, particularly by packaging it into shareable modules, opens the door to considerably faster adoption by new teams. They can benefit from the well-paved roads, experience, and skills of early adopters, so they can deploy New Relic fast, with ease, and with a much lower bar to entry.

Observability as code reduces operational risk and improves ownership and accountability. Also, if your industry is highly regulated, you might need to leverage an observability as code deployment model to help meet your strict compliance and audit obligations.

With observability as code, you are in a position to treat observability, the development process, and the life cycles involved just like your own product development. Observability becomes embedded into your everyday activities.

Automate everything!

If you want observability to be as ubiquitous as sliced bread, then you need to take a page from our friend Otto’s book and fully embrace automation through observability as code.

Observability as code will help reduce toil, improve maintenance, and accelerate observability adoption across your organization.

Treating your observability tooling like part of your product and ensuring it is easy to maintain, update, and deploy will help you realize the value more widely and improve your return on investment.

I encourage you to automate everything!