The "Truth" about DevOps? - A startup perspective

Now here is an interesting topic; one that very few have any understanding or idea what it actually means. What exactly is DevOps?

Ask any modern technology based company if they have a DevOps team, and they will probably say yes. Ask that company to describe DevOps and you will be amazed by how varied the answers are.

Why is it then, that everyone says they have DevOps, but the answers vary so widely? Well, the most simple answer that I could provide, as a “DevOps Lead” is that there is no definition in the first place. It is a phrase that has been adopted, but it was never given a strict definition that is adhered to across the board.

As a DevOps person, here are the things that I personally find and consider when I use the term DevOps.

• Is the person from a development background

• Do they understand development principles?

  • Structured Code

  • Debugging — Lets start with the most basic, log tracing

  • Tracing through a Stack — Ever used a debugger?

• Is the person an active “scripter”

  • What languages are in their toolbox?

  • How often do they use those languages?

• Has the person ever dealt with automation?

• Has the person dealt with networking?

• What is the person’s familiarity with monitoring?

• Has the person dealt with storage, and disk optimization?

• Has the person dealt with security

  • policy

  • implementation

  • maintainence

  • audits

• Is the person familiar with IT principles?

  • OS Familiarities

  • Image Creation

  • Asset Management

  • Security

Man, that’s a lot to consider, right? Yeah, it is. In the end, it sounds much like a very well rounded System Administrator. In today’s industry, SysAdmins are no longer “Silo Engineers” like they were in the traditional 9-5 workforce days. Now, especially with startups, an Operations person is often times required, and often times capable of far more than what you see on their resume, or in the job profile that you hired them for.

DevOps (from my own perspective) is about all of these things. We adhere to “multitasking” logistics. You give us a task, often times, we are required to interrupt that task, keeping it in the queue and active in memory, but frozen while we work another process, then we switch back. Constant interrupts, constant resumes, and constant queuing.

Now granted, big companies may treat this very differently. Big companies have the luxury/(dis)advantage of having multiple engineers per group, and multiple groups.

I’ll be posting more thoughts on startup perspectives later… let’s see what we uncover as we move forward.

-Villain