Tag: DevOps

As we implement more automation and complexity in our systems, we increase the ability of every worker to accomplish more during their day. In many cases, this is a good thing, as many of us have no shortage of tasks to complete. Being able to do more is good. Some technology workers, and likely some managers, view these changes as opportunities to use less people to do the same work. That can be worrisome for many people, especially those concerned with job security. That’s a difficult situation to find one’s self in.

I’m not sure if this worker was concerned about losing employment or just wanted to get more work, but a contractor put logic bombs in his project that would cause issues at various times. He would then be called to fix issues, getting paid for his efforts. Recently he was sentenced to prison time for his actions.

Most workers make an effort to do good work and provide value for their time and knowledge. They may still make mistakes or cause problems, but it’s often unintentional, not malicious. We also don’t look to create future problems for others, though certainly we may accrue technical debt over time as we make trade-offs in our work.

Whether intentional or accidental, we want to limit mistakes and issues in our code. This is one reason that modern development in a DevOps environment isn’t a wild west, cowboy style of work. We use code reviews and continuous improvement to help other developers learn to write better code. We use automated processes with instrumentation and logging to ensure we know what code is deployed when and by whom.

We may move faster with DevOps, but it’s often safer, more secure, and more accountable than previous methods of building software. It doesn’t prevent mistakes, but every part of the process should be more transparent and auditable, which is good for everyone involved.

Steve Jones

Listen to the podcast at Libsyn, Stitcher or iTunes.

Is infrastructure a product? Should an Ops team start to feel like they are a team involved in building things rather than maintaining them? It’s an interesting idea that is put forth in this blog from Forrester. The piece postulates that the Ops group should be thinking like a product team, just like developers working on an application.

When a development group moves to a DevOps style of building things, and starts to take some responsibility for the support of their work, what does the Ops group do? If we push infrastructure as code into our VCS, is there much for the Ops group to do?

I’d argue there still is. From the DBA side, operational staff can help determine what infrastructure is needed, or what changes need to be made. It’s easy to say that devs should add RAM or CPUs, or even another replica, but do they really know when to add them? Or do they just scale everything up? The latter might be easy on people used to writing code, but it’s not necessarily a good idea for the organizational budget.

Ops staff can still tune systems, add indexes and rewrite code, and give feedback and knowledge to developers to help them understand how to write better code, or infra-as-code code, the first time. There’s also the need to practice and be ready for various DR situations, including the “whoops, I deleted some data”. There are skills that help handle these situations, which are far different from developer skills.

This is in addition to designing new systems and setting templates for that infrastructure as code that the developers keep in their VCS. There’s also the need to build self-service tools, which might be where Ops becomes a product team. I think that will be necessary, as tooling is important everywhere. I think Operations might even develop other things, like reports requirements that developers don’t have time to build. Ultimately, though, there is still a need for some Ops work, albeit work that ought to be closely aligned, and shared, with developers.

Steve Jones

Listen to the podcast at Libsyn, Stitcher or iTunes.