BrainBlog for Chronosphere by Jason Bloomberg
Developer toil is the curse of all software development initiatives. All the mundane, repeatable tasks that suck up developers’ time and energy, pulling them away from the value-added work of building great software – all roll up into the definition of toil.
Eliminating (or at least, reducing) toil is therefore one of the primary goals of every software development manager.
Sometimes toil is systemic, and the best approach is to rework the entire system in question. In such cases, the buck stops with the SREs who understand what aspects of operating the software in production are toilsome. They can recommend changes that will be more streamlined, thus reducing toil.
In other cases, the toil is inherent in the day-to-day work of the developer – especially in modern, cloud native environments where teams of developers work in parallel on interdependent microservices.
The complexity of Kubernetes environments coupled with modern infrastructure-as-code DevOps approaches give rise to all manner of busywork, adding to developer toil and slowing down the software effort.
Observability to the rescue?
In less dynamic environments, automation is the go-to solution for reducing toil. The best way to eliminate toil from repetitive tasks is to automate them.
For cloud native environments, however, repetitiveness is less likely to be the root cause of the toil. Instead, the complex interdependencies of the environment — not only the microservices, but the software infrastructure from build to deploy — all tend to create the busywork that slows developers down, reducing their productivity, morale, and enjoyment.
To reduce the toil in such dynamic environments, developers require visibility – visibility not only into the behavior of the software they’re working on, but also how that software interacts with everything else going on in the environment.
Fortunately, there is a type of tooling that is supposed to provide such visibility: observability platforms.
