The DevOps Philosophy: An interview with the RBA DevOps team

Let’s talk about our newest search for a DevOps engineer for our technology team. We’ve seen an increase in the adoption of a DevOps mindset in our clients and their teams. So, what is it exactly that we’re looking for? We talked with our DevOps team to get a sense of what helps them succeed, the mindset they have, and the adoption they drive in clients.  

We started out the conversation with making a giant assumption. Our engineers that practice DevOps are philosophers. It’s a logical and rational assumption, right? When you consider that DevOps is a mindset made up of values, principles, methods, practices, and tools. It’s a philosophic approach to delivering software in a better way. It’s bigger than just a role – and those who embrace DevOps are philosophers. 

Are you all philosophers?  

HA! No, but the mindset and culture of DevOps lends itself to that description. It’s an adoption of an approach – not just a set of tasks.  

Fine, but since DevOps is a philosophy – you’re all pretty much philosophers in my mind. How would you explain your role?  

We’re the glue between the development and operations team. We help the teams work better together and make software deployment smoother. In order to do that effectively, we understand the big picture.  

On the development side you have to understand the software solution as a whole. On the operations side you have to know what the infrastructure architecture looks like – and how it works. Being able to understand both sides of the table – and how to communicate it between the teams – is what makes someone successful in this role.  

OK, so people who embrace DevOps have a unique skill set. What else is important in what you do?  

We also can build software on our own. It’s vital to understand how the different pieces of the software fits together. You know the intricacies of the application’s performance, what quality code should look like to prevent issues, and how to quickly find the root cause of errors and exceptions.  

On top of that, you understand how to move that software from a single person’s machine to this scaled out infrastructure. You’re hyper-aware of application availability, uptime, and SLA’s.  

We’re melding the application metrics with infrastructure metrics to solve problems. All of it adds up to the understanding of increasing the performance of an application.  

It’s so important that we communicate well with both teams. We need to understand what the development team is doing and how it translates into the scaled infrastructure environment.  

It’s awesome that you understand both sides of the table – helping them communicate more efficiently is great, too. I know automation in DevOps is a huge part of what you do, right?  

Definitely. Scripting is a big part of the job. It’s using the glue we have and putting all of the pieces together. Writing custom scripts that automate infrastructure, deployments and more.

Automating repetitive tasks. That’s awesome. What about the cloud?  

Right. The cloud is a huge part of our life. You have to be comfortable scripting things for the cloud it’s a big part of what we do. We also do a lot of software-defined networking in the cloud as well.  

We’re also get into infrastructure as code. We write lines of code, run a command against it, and it automatically creates everything as defined in the code. Whatever we’re trying to deploy is done. Automated. We don’t have to sit and click next, next, next, finish. Leveraging infrastructure as code makes it repeatable and consistent. That’s one of the goals.  

Do you deal with security much?  

Absolutely. We deal with it almost daily. People embracing DevOps with a security background is set up for success. We’re actually hiring for our team right now, too. So, someone that brings web application firewalls, any kind of sub-netting, or VLAN-ing in the cloud to the table would fit in well.  

That’s right. We’re recruiting for your team. What does it take for a person to be great in this role?  

Well, they should have some DevOps experience under their belt. We want to see someone who is doing the building, deploying, and configuration management. Some people say they’ve worked in DevOps, but they just copy and paste files around. Or they think being close and sitting next to the dev team is DevOps and it’s not. That’s not the kind of individual that we’re looking to add.

They also need to be collaborative and love to communicate. They’ll talk with our technical teams in addition to the client’s technical and non-technical teams. Feeling comfortable in those environments will set them up for success. They should feel good about talking to anyone.  

What’s one of the most rewarding things about working in DevOps?  

The change you get to implement at the client. A lot of the time you’re educating and teaching them. They may understand the idea, but they don’t know how to implement it. Or they don’t understand the cloud very well. We get to advise them on different strategies and learn their approaches, too.  

It’s demanding but rewarding work. You get to enact change and see tangible results. It’s great.  

My thanks to the DevOps Engineers for sitting down and having this conversation. Even though they don’t say they’re philosophers, the way they talk about changing client’s approaches was philosophical. Plus, saying we have philosophers over here is pretty fun, too.