DevOps: role or culture? An Interview with Israel Gayoso

Like so many technology terms, DevOps has become popular but its meaning is often misunderstood. It means a lot of different things to different people. That's a challenge when you are trying to understand what DevOps means or defining DevOps clearly. At Sngular, DevOps is a critical success driver of our key projects.

We spoke with Israel Gayoso, one of our top experts on the subject, to share his views on what DevOps means and how it can be best applied.

How do you define DevOps?

I understand DevOps as a development methodology where system administrators and developers integrate. Developers focus on development and they don’t have to “waste” time in deploying their code or whatever type of automation.

Getting a little more into the weeds, DevOps implies the evolution of the system administrator. The role moves away from controlling systems in a way that is mostly manual and trivial towards full-blown automation when it comes to deploying code, updates, and system maintenance.

This figure emerged after companies began managing an ever-growing number of servers. In the beginning, things were done almost manually and without any type of automation. Now, with the range of tools that exist in the market, one single system administrator can be in charge of hundreds of machines.

Would you say there’s a general misconception about what DevOps is?

Yes. I think the biggest misconception is that DevOps is more of a specific role within a company or team than a culture. It started off as a culture but over time it’s pivoted into more of a role, bringing with it many misunderstandings and debates within the world of system administrators.

Although DevOps is now totally accepted in most companies, I think that the trend towards thinking of DevOps as just a direct role should change. Instead, it should be within the description of a role, the work methodology of a systems team or part of a company’s larger culture.

If DevOps is a methodology rather than a "role," what’s the difference between DevOps and Agile?

They’re two different things that can complement each other nicely. DevOps aims to promote a culture of automation as much as possible to free up time for the developer to concentrate on more important things. Agile, on the other hand, is more about the ability to adapt to changing requirements and coordinating teamwork.

Uniting the two methodologies, companies can develop and implement technology more quickly, but there are some drawbacks. One of the most inconvenient things in the world of DevOps is that there are often last-minute tasks or changes, which can sometimes be tricky to fit into the Agile model. That’s why it’s sometimes best to use a hybrid model or ensure you can adapt to the last-minute curveballs coming from a team or a client.

We keep hearing about the "three ways" of DevOps. Could you explain it to us?

Even though the ‘three ways’ are from years ago, from when the hype around the term DevOps first started, I’ll explain them in my own way.

The first way is based on Continuous Deployment. Traditionally, companies would refuse to deploy on Friday afternoons. Why? Because the deployment of new code can cause a lot of headaches. That’s why the figure of DevOps came in, to help the deployment become more controlled and less problematic. With that, it also gives the developer space to focus on development, fixing bugs, or improving the code.

The second way is about Feedback. If you want to understand how systems work or what a client needs, you need to control metrics and KPIs. This allows you to anticipate problems before they start. So, in the case of disaster, we can keep clients constantly up-to-date, provide recovery times, and a thorough post-mortem after a failure. Employing this principle, we are always updated, whether that’s with the team or with the client.

The third way is Experimentation. Things change fast. Technology advances rapidly and every day there are more tools, uses, options, and companies entering the market. We need to experiment continuously and keep our minds open to trying new things to be able to keep up. We sometimes test things that are unconventional or experimental to improve our platforms or prevent possible errors. A popular example is Netflix’s “Chaos Monkey,” which is a tool that randomly disables production instances and brings general chaos to the platform so that the company can ensure the platform is strong and stable in the face of attacks.

What is SRE and what are your thoughts on it?

Another one of these figures that are garnering attention from businesses is the Site Reliability Engineers. Although it’s a term used and invented by Google, companies are increasingly favoring the role and concept over that of DevOps. Actually, SRE has been around longer than DevOps. Google started talking about the role back in 2003.

At the end of the day, SREs use the DevOps philosophy to carry out their work. One of the biggest differences between SRE and DevOps is that the latter is more about the “what,” while SRE goes further with the “how.” They both share the “Three Ways” principles and a few more: reducing silos in companies, accepting failures as normal, implementing gradual change, automating everything possible, and measuring everything (metrics.)

Israel Gayoso is from Spain and relocated to Singapore from Pittsburgh last year with his wife and two kids. He’s been working in system administration for more than 15 years and is currently one of Sngular’s most experienced DevOps Managers. His work is client-oriented and he focuses on helping define and implement large cloud-based infrastructures. He’s so passionate that in his free time, you may find him working pro-bono with small start-ups and friends in infrastructure migration or sharing his knowledge as an advisor on new technologies.