Cloud Native Go, 2nd Edition

Chapter 10. Manageability

Everyone knows that debugging is twice as hard as writing a program in the first place. So if you’re as clever as you can be when you write it, how will you ever debug it?¹

Brian Kernighan, The Elements of Programming Style (1978)

In a perfect world, you’d never have to deploy a new version of your service or (heaven forbid!) shut down your entire system to fix or modify it to meet new requirements.

Then again, in a perfect world, unicorns would exist and four out of five dentists would recommend we eat pie for breakfast.²

Clearly, we don’t live in a perfect world. But while unicorns might never exist,³ you don’t have to resign yourself to a world where you have to update your code whenever you need to alter your system’s behavior.

While you’ll probably always have to make code changes to update core logic, it is possible to build your systems so that you—or, critically, somebody else—can change a surprising variety of behaviors without having to recode and redeploy.

You may recall that we introduced this important attribute of cloud native systems back in “Manageability”, where we defined it as the ease with which a system’s behavior can be modified to keep it secure, running smoothly, and compliant with changing requirements.

While this sounds straightforward, there’s actually quite a bit more to manageability than you might think. It goes far beyond configuration files (though that’s certainly part of it). In this chapter, we’ll discuss what it means ...