Devops Asks a Lot

Devops is a mindset and a practice that asks a lot. Engineers must learn a two worlds of ops and dev. This encourages some good things, and needs to be tempered in order to be more realistict.

Ownership is Awesome

Devops encourages ownership of the code, the product, and the environment in production all the time. This ownership engenders a feeling of responsibility, craftsmanship of better quality code, and removes the tendency to make your problems someone else's. This ownership is wonderful.

Where ownership starts to feel overly intense is when it feels like you're out of your element, and you're all on your own -- it's your responsibility after all.

Modern Dev & Ops Fields

Our systems are becoming more and more complex.

In dev terms, gone are the days of starting a repo and writing a single app. Now your app is spread across multiple codebases. You might span languages and paradigms. You have to coordinate the implementation of these systems with a wide array of contributors and stakeholders. You have a wide array of tests to exercise and verify your code. You are focused on long-term viability of your design in its clarity and refactorability. In order to remain relevant in the marketplace, your product is always changing, as is your implementation to support it. There is a lot here.

In ops terms, gone are the days of your app sitting behind a simple webserver. Now a request will hit a load balancer and pinball across the network. A labyrinth of microservices await the request. There are many deployables, performing independent tasks, yet intertwined in larger workflows. They have central logging and monitoring requirements. They are individually tuned for scale. They are controlled through arcane infrastructure configuration. There is a lot here.

Doing it All

To do both dev and ops requires a wide breadth of knowledge. Having considered the state of both dev & ops on the web today, they seem to require a depth of expertise. Now devops seems to be asking us to combine the fields into one. To find such an engineer that embodies the breadth and depth of both fields is rare. To train such an engineer will take time, experience, proper training, be expensive, and put a lot on her shoulders.

Making it More Realistic

As a software creator, I like to say that anything is possible. It usually comes down to how long you want to wait and pay. Perhaps you're frustrated or intimidated by a devops expectation that you know and do all of dev and ops. Perhaps you're feeling that it is possible but that the price is quite high. To mitigate this cost and to encourage realistic devops mindsets and practices, perhaps we can do a few things to help.

We can give development time and space to write quality code. So much depends on us creating stable systems so that dev time is not eaten in ongoing production runtime maintenance costs. The only way to go fast is to go well.

We can welcome specialists into our teams. These fields are deep. We shouldn't be afraid to lean on the deeper understanding of a specialist, whether she be in dev or ops. Likewise, interests are often broad, but they are sometimes focused. We can make it ok to not be interested in one side or the other. This isn't a lack of interest in the principle of responsibility -- just in going deep on expertise. We can form teams around varied strengths and not require people to cultivate interest and expertise in absolutely everything. We can ask for help.

We can provide platform level help. There are complex tasks that can be wrapped up and made more consumer ready. Procurement, build, deployment, logging, and monitoring setup all have great potential to be simplified for users.

Surely these are just a few things that could help. Let's encourage ownership through devops. Let's make devops more workable for everyone.

Have you felt the pressure to know and do all in a devops world? What are some things that you've done to keep your head above water in a sea of tools and practices in these two deep fields? What are some steps that you have made or see we could make to make the good parts of devops shine without being overwhelming?