Table of Contents
Introduction
Monitoring is integral to understanding what is happening in your infrastructure, applications, or other observability projects. However, a common predicament developers can land themselves in is their observability stack becoming unwieldy and unmanageable due to a lack of streamlining and/or over-complicated code.
To simplify your workload, it is important to streamline your monitoring. You may not use all the latest integrations or have every available metric, but you can significantly reduce the time and cost of your observability by being intentional. Prioritizing the key elements of your observability stack can give you everything you need and help you conserve resources for a huge monitoring project you don't need.
The Obsession with Complexity
Lauren - JJ, our lead engineer, said, ”When it comes to computer science, there is an obsession around complexity. But more developers are realizing complexity is actually causing more problems.”
Many developers get satisfaction from writing fancy code. You put time and effort in, and the result is so cool. You might get an “Aha!” moment when you can write something complex. But we think the simpler, the better.
"If you can't explain it to a six-year-old, you don't understand it yourself." - Albert Einstein.
Maybe you don’t have to explain your code to a six-year-old, but if someone less experienced than you can’t update the code you built, you are doing a disservice to your business and your development team.
Complex is good, simple is better
If you are writing code, and you are the only one who can understand it, that isn’t a good thing. Occasionally, there are a few cases where a project may require complicated code. And that is okay! There is nothing wrong with having complex code- many circumstances call for complex code. But when you implement complicated code unnecessarily, it leads to problems.
“Every line of code is a liability for a business, not an asset. You do not want to write code unless you have to. If there is a line of code that you don't have to write, that's not necessary, so you don't need to write it.”
Shorter is not always simpler
Many developers like reducing their line count as short as possible. But often, trying to shorten their code makes it harder to understand. Some developers can take a simple function with 10 lines of code and condense it to 2 lines! That’s cool, but what happens is the code is much more challenging to understand and, therefore, more difficult to maintain.
“In some cases, shortening code to make it shorter doesn't make it easier to understand and actually makes it harder to understand, which makes it more of a liability.”
Here’s an example: A programmer may decide to optimize a function that takes 10 seconds to run down to 5 seconds. That’s pretty cool, but is it worth it? When you consider the amount of time you spent tweaking this and how often this function is called, it may be more trouble than it is worth. Also, when other devs look at the function, it will take them more time to understand what you wrote and how it works.
It's not about line count. It's about understanding what is complex versus what is simple. It’s knowing what necessary code is versus what fancy code is.
“You need to be able to recognize that you don't need to do it this way because it's just going to make it harder on the next person has to do this, or this could be simplified better.”
Apply This Concept to your Monitoring
Simplifying is essential in tech, but it is especially important with observability. Often, developers want to get every possible datapoint whether it is relevant or not. But when you are trying to monitor every possible thing just because you can, you may be wasting time and resources.
Monitoring every combination of possible events is great, but monitoring only critical events that you need to be aware of is much easier, puts your projects in focus, and saves you time. Maybe you don’t need every piece of data thats happening in your stack, but only key metrics to help you monitor performance and drive your decisions about scaling and resource allocation.
Start small. If you have tons of metrics you don’t need, all you’re doing is increasing metric cardinality, which can increase your metric query time.
Too many metrics VS Only the metrics you might want to see:
Try MetricFire
Conclusion
When developers write code, they should remember that anyone can write complicated code. However, the better approach is to make something so simple that a kid could understand it, as this will prevent far fewer issues. By keeping your programming and monitoring in perspective, you can save yourself time, money, and stress and focus on the things that count.
