At any given point in time our apps are the sum of a whole series of choices that we’ve made – design choices, implementation choices, even choices about implementing good build tests to ensure quality, about implementing sound operational practices to ensure that the app can be relied upon … or not.
Since every development team is finite, and the needs for new features and functionality essentially unlimited, something has to give.
Very often the finite resources are spent mostly on the most pressing needs … that next new feature, that new capbility that will help sales close the next deal, that bug which absolutely has to be fixed or <fill in the blank> is dropping us, the feature needed to gain support within the organization.
So what gives are the unglamorous parts, the type of tooling and hidden work that ensures that your app will be resilient, that it will survive the unexpected hardware failure, that it will scale gracefully as usage increases. Nobody ever really sets out to skip this hidden stuff, but most of us end up there at one time or another.
However, do you really want to wait until the databases are lost to make sure that backups are solid? Do you really want to wait until a customer drops before ensuring that regularly scheduled parts of the app run accoording to schedule? Do you want to wait until you’re overrun with folks using the app before knowing precisely how to add capacity effectively?
We gently propose that there’s no need set aside many of the hidden tasks, even unintentionally. That’s precisely where our standardized tooling, patterns, and procedures can be very handy … the dev team is now able to focus on the high priority, visible parts of the app, and the devops.center team can efficiently focus on the hidden stuff.