What a DevOps team really does varies based on the engineer you ask. Most will agree, however, that DevOps exist to improve the quality of work, collaboration and communication between IT operations and development teams while upholding ongoing system maintenance. We checked in with three engineering leaders to learn how they define their department and share what DevOps projects they’re currently working on.
Kessiler Rodrigues, chief architect at Tenfold, leads a team of three DevOps/site reliability engineers. Joining Rodrigues on his team is his friend Mateusz Kwiatkowski, a DevOps engineer who helped him launch two previous startups in 2010 and 2015. Rodrigues said working so closely with a friend in DevOps helped him learn the skills required to support a team.
How do you explain to people outside of tech what you do?
Let's think of a building an office building.
Those who provide a sketch of an office are architects. They make sure the building won't collapse due bad characteristics. In software engineering, we call these people software architects.
Those who build the office in software engineering are software developers. Some engineers will specialize in the internals (like walls and floors), while some will work on the features customers use (like cabinets, sinks or A/C).
Once the office has been built, the work isn’t finished. A maintenance team upkeeps the building, makes sure the lawn is mowed and the A/C works, etc. This is the DevOps/SRE Team.
A catch in DevOps/SRE is we're trying to be proactive and preventing the problems from ever happening. In the real world, once the A/C breaks in the office, employees are mad, maintenance is called and the A/C is eventually fixed.
In the DevOps/SRE world, there's a backup A/C system that will automatically kick in the moment the main A/C goes down. Obviously, crap will hit the fan sooner or later, and that's when we're reactive (we have no other choice) but we spend most of our engineering efforts on preventing the problems before they appear.
What project is your team working on? What’s the goal of this project?
Our recent goal has been to make sure every single component at Tenfold has a backup system running. Whenever a component dies, we want its backup to kick in and pick up all the work without affecting customers in any way. Tenfold’s product consists of several hundred different components, each of which needs a proper strategy for that. We're going through all these systems one by one and making sure there's a replacement in place. In DevOps, we call this automated failover and high availability.
Doug Shuffield, Virtuix’s director of engineering, shared how having a DevOps team enables individuals to take ownership and build platforms themselves that ensure long-term customer and organizational success.
How big is your DevOps team?
We have a multinational group — U.S. and China — of around 20 people.
How do you explain to people outside of tech what you do?
I’ll tell them we make a 360-degree virtual reality gaming system that enables the player to walk and run in the virtual world. I’ll usually get a blank stare, so I show them a video of what we make and then tell them we design and develop all the magic behind the curtain that makes it work. At that point, the light comes on. Here is the video I show because it highlights both the product, the Virtuix Omni, and the platform, Omniverse.
How did you get into DevOps?
I graduated from the University of Arkansas with a bachelor’s degree in electrical engineering and moved to Austin to start my career back in 1996 at Symmetrix, an automated test and measurement company. My practical experience quickly grew there to include many disciplines including hardware, software, firmware and mechanical design. The kind of work we did naturally lead to a DevOps model where the development and operations teams were one and the same and were involved in the whole system lifecycle.
I brought that same philosophy when I came to Virtuix. Being a part of a startup magnifies the need for a DevOps model. To some degree, a startup is forced by necessity to employ DevOps methods because it has to develop, deliver and operate applications at high velocity with very limited resources. Why do it with slow, manual processes across siloed teams when you can enable individuals with tools and technology to do it themselves. It really is about empowering people to step outside of the box their title might have them in and do what is necessary to make the business and its customers successful.
What project is your team working on?
Our just-released content delivery and arcade management platform, Omniverse. Omniverse is an excellent example of the DevOps concept. Now that the platform is released, the development team is moving into the operations phase to make sure the platform and the commercial operators using it are successful. When our customers are successful, we are successful.
Blackbaud’s DevOps director John Yeager began as an engineering manager for its operations team. When he realized the operations team had completed projects that they shouldn’t have had to do, he collaborated with management to create a team solely focused on DevOps to do said work.
How big is your DevOps team?
We have 19 DevOps engineers divided into three teams.
How do you explain to people outside of tech what you do?
Challenging. If I am not feeling up to the task, I just tell them we put things into the Cloud. If I want to get into it, then I describe how the team is building the road for our engineering teams to quickly and easily start new projects that focus on business value. We deliver services that allow them to get things like security, backups and monitoring up to complex standards that are easily accessible to them. We also empower them to own these environments and respond to client issues often before clients even know a problem has occurred.
What project is your team working on?
I have multiple teams working on a few projects. Our two biggest focus on delivering our applications in Azure IaaS and Azure PaaS. We are taking a PaaS first approach and have created a self-service pipeline to deliver PaaS environments to internal consumers to own and leverage. The IaaS team is working to deliver IaaS environments for the products we are not moving to a PaaS solution today. Both teams build software-defined environments and process to build quality upfront.
What’s the goal of this project?
We are moving out of our data centers and into Azure while increasing the quality of the product we deliver to clients. We are working on building the paved road for all our current and future applications. We are delivering all new applications in our PaaS pipeline going forward and using the same technologies and tools used to build those products to build our pipeline. We are creating an internally "open source" model where all engineers and teams can contribute to the future of our systems.
