How much work do you do that doesn’t really require your full attention? How much is repetitive?
Let’s start with a small example. When you check your email, there will invariably be some messages in there that you do not care about. We have built machines, in the form of spam filters, to help filter out messages like that. They are not perfect; sometimes they filter out messages we do actually care about, and sometimes things still slip through that they should have caught. But they do help you in your task of checking email. You can give your focus to things that are most likely to need it, and ignore or cleanup the others.
Developer Maintenance
What kind of maintenance tasks do you have to handle in your daily development work? We have a hard time with our microservices, keeping them all up-to-date with base images. Many of our microservices are now older, and are not updated as often as they were in the past. Many go months, or even a year or more without being touched at all. This obviously presents a problem; how do you keep these non-touched services up to date?
We do have the “soft” practice in place of updating a service to the current standards when it is touched. Of course, this does not help much. Developers are already super busy and often under time crunches when making changes. So asking them to make extra changes on top of the product work is a hard sell. And who nows how much the standards have changed since the last time we touched this service? Plus, this doesn’t help at all with the services that are not touched.
Instead of requiring developers to make these changes, and to hold all the needed changes from the past year in their heads, it is much better to teach a machine how to do this. Teach a Jenkins job how to find the services that need to be updated, how to update them, and even how to validate the changes. Especially with microservices, this should be a relatively safe process. Each service should be self contained, independently deployable, and have sufficient tests to prove the updates don’t break anything.
Relieve the Burden
It of course is harder on somebody to have to build an automated process to make these kind of changes. But in the long run, it will probably save the company as a whole time and money. The process is more predictable and repeatable. Best of all, the updates will actually happen. You don’t have to devote a couple of teams for an entire quarter to maintenance efforts and away from product development.
After the first automated process like this is built, other, similar ones will become easier. The lessons you learn when building one can directly apply to a second one. These processes can also give nice bits of documentation for any developers that are unfamiliar with your services. They can show the devs how to find services of type x. Or how your base images are layered. Or even which files matter in a deployment.