When it comes to solving a puzzle, there are multiple plans of attack. You can start by building the border and working your way in, you can pile similar colors together, or if you’re part of a DevOps team, you might automate a software system to do it for you.
DevOps are responsible for creating communication between software development and IT systems teams so that the two departments can work together to create the bigger business picture.
We asked four engineering leaders about the tactics they use to structure their devops teams to ensure that picture is frame-worthy.
FluentStream
By incorporating cloud-based software, FluentStream Technologies makes client communication easier and more manageable for small businesses. Director of Engineering Justin Davies explains why giving his DevOps team exposure to both voice technology and software automation tooling makes them experts at their jobs.
How have you structured your DevOps team, and why? What's the breakdown of roles and responsibilities?
Our DevOps team is structured to provide underlying infrastructure and service reliability. This involves supporting both our software development team and many of our more sophisticated clients. Additionally, our DevOps team has primary responsibility for our voice and telecommunications technology, so their resources include software automation tooling, and knowledge of how a voice network interconnects with our data and API infrastructure. While engineers specialize differently, everyone gets exposure to both areas of technology and can learn and apply those skills to problems in both domains.
"Our DevOps team is structured to provide underlying infrastructure and service reliability."
Please describe a recent DevOps win that resulted from this team structure.
We have had a number of successes that are built on our ability to operate this shared voice and Linux infrastructure. Unlike many players in our space, we are able to deliver 100 percent of our services on commodity infrastructure as a service, rather than having to invest in and maintain legacy hardware-centric infrastructure. This allows us much greater flexibility and allows us to share common tooling for deploying both API and a heterogeneous cloud environment. And our team gets to write a lot of Golang and Kubernetes deployments for voice services.
Active Oversight
Building a software company that combines wearables, machine learning and blockchain means that there is a never-ending to-do list for Active Oversight’s Director of Engineering Quentin Hartman. He told us how a small DevOps team is an advantage when tackling big responsibility.
How have you structured your DevOps team, and why?
We’re quite small, and so we are an ideal organization for a converged DevOps practice. I lead the infrastructure and automation efforts, but we practice DevOps as a whole organization. One of the greatest examples of this is how we handle analysis of the daily metrics report from our production environment. It summarizes interesting stats from the previous day, including slow requests, request volumes and requests that caused errors. That responsibility rotates through the developers, so they all have a shot at it.
"I lead the infrastructure and automation efforts, but we practice DevOps as a whole organization."
Describe a recent DevOps win that resulted from this team structure.
We had an interesting day last quarter where a developer pointed out an unusual error on the report and was sure it was something we needed to look at more closely. I was skeptical, but he and I looked into it, and while it was weird, we couldn’t think of how it might have occurred or what impact it might have. Later that day, we got a bug report from one of our users that baffled our first-line support people. However, once it came to us, we knew exactly what the problem was because of the digging we had already done. In the end, we used varied perspectives to “pre-diagnose” this bug, and turn around a fix much more quickly than we would have otherwise.
Iodine Software
Iodine Software’s Director of Technical Services Cheng Zhou said the company’s site reliability engineering team is guided by a set of fundamental ideals that keep them hitting goals, like productizing ideas in short windows of time. And time is of the essence when you consider Iodine’s mission of improving hospitals’ clinical documentation.
How have you structured your DevOps team, and why?
Iodine’s site reliability engineering team serves all products and we work closely with engineering throughout. Our team orients toward principles that we think are critical for every successful SRE team, including engineering velocity, making decisions by metrics rather than patterns, focusing on the sustainability of on-call and practicing what you plan to be good at.
Our structure is largely an artifact of size. We started with a single, monolithic service that has exploded quickly. As cardinality increases, we’ll reevaluate whether our structure best supports those principles.
"We launched a brand new product from inception to first live customer within six months..."
What was a recent DevOps win that resulted from your team structure?
Recently, we launched a brand new product from inception to first live customer within six months using a global development team. The product team had an embedded SRE who was supported by the rest of the SRE team at the outset. Because of that structure, deployability was built in from day one and we were able to go live without drama. This would not have been possible if we came into the process any later.
TrustRadius
If certain professional tactics work well, why not use them in as many places as possible? CTO Scott Brittain at TrustRadius said his team injects fundamental DevOps principles like automation and data migration into just about every area of the business.
How have you structured your DevOps team, and why?
When it comes to rolling out new technology, we think of the entire business as “the product.” So in relation to DevOps, we thought broadly about how we could apply that division’s skills across every department, including sales, marketing, research, customer success and product. By doing so, we recognized the company-wide need to implement core principles we find in modern DevOps: keeping systems running, continuous improvement, deploying new technology and automating every job function.
Our ops organization features a director of DevOps, a director of revenue operations, an operations manager, an operations engineer and several outside contractors.
"We recognized the company-wide need to implement core principles we find in modern DevOps."
What was a recent DevOps win that resulted from your team structure?
We’ve seen many wins from applying this cross-functional group, but a recent one had us snapshotting our production product-data into Salesforce, where sales and customer success teams would have greater access to run their workflows. Transforming and streaming production data into external systems — which is the expertise of traditional DevOps — combined perfectly with the business operations skills of schema design, reporting and business analysis. The combined team was able to anticipate the user’s needs more effectively without normal departmental silos, resulting in very little rework and rapid project completion.
