Ops/Dev or DevOps?
Ops/Dev or DevOps?
The co-founder of a configuration automation company talks about promoting collaboration between all the sectors that exist between development and operations.
Join the DZone community and get the full member experience.Join For Free
Great talking with Kristy McDougal, Product and Sales Engineer and Co-Founder of Orca, a configuration automation company that optimizes application ecosystems for Fortune 100 companies.
Kristy was a member of the VaraLogix team that was acquired by BMC. While working at VaraLogix, the founders of Orca saw the need for a new approach to configuration management since they spent a significant amount of time writing scripts to make deployment changes. Seventy to eighty percent of the application deployment process in DevOps is integration. However, without visibility into the process and the friction, you frequently end up doing configuration steps versus application deployment.
Q: What do you see as the most important elements of DevOps?
A: We’re more of an ops/dev than DevOps promoter. DevOps requires massive changes in collaboration, processes, and problem-solving. We help operations start implementing DevOps and seeing the value. Our software promotes collaboration between developers, operations, middleware, DBA’s, and release – all the sectors that exist between development and operations.
Q: Where do you clients find the greatest value?
While most people in DevOps say collaboration and speed to market, our clients see the greatest value in having visibility into the people, processes, and technology. The unfortunate reality for so many IT operations teams is that they are flying blind. For instance, it is a challenge for them to even know which databases are related to which applications and which middleware. And with that shaky foundation, it is understandable that teams have a tough time knowing which of their changes were deployed successfully and which weren’t. Even knowing who made changes and who approved them is a mystery in many environments. So, by enabling visibility into the entire DevOps process we help clients change and collaborate.
Q: What are a couple of ways your clients are benefitting from DevOps?
A: We have a financial services client that’s just getting started with DevOps and was having an infrastructure configuration issue. They had a farm of application servers all of which were supposed to be running under the same production specifications. When we put our automation software in place, we found someone was using one of the production servers as a developer sandbox thus opening a huge security vulnerability. People think they know what their infrastructure configuration looks like but then they see there’s much more going on than they were aware of.
We also have an industrial supplier refreshing their database every 30 to 60 days. They thought their databases were perfectly aligned until we found 44,000 differences that were slowing performance. We found these discrepancies in two minutes versus two months.
Q: What are the most common obstacles to success you see at clients attempting to implement DevOps?
A: People and culture. People are entrenched in their way of doing things and protecting their fiefdoms. There are processes just for their team that need to be scrapped for DevOps to be effective. And frankly it is easy for people to imagine incremental process improvements, but it is more difficult for people to imagine a modern approach that error-proofs and automates and takes so much of the guesswork out of what was previously just part of their daily hassle.
Q: What’s the future of DevOps from your perspective?
A: People, processes, and technology will continue to be the trifecta but each will mature as companies see more value in the methodology. The future of DevOps is seeing the people, process, and technology all mature to span all the way from Dev to Operations. Currently, DevOps is very Dev heavy, but the future also includes Operations. There will be seamless integration between on-prem, hybrid, and cloud with more emphasis on containers and microservices. Tool sets will scale to handle development and operations past QA friction points through deployment.
Q: What advice do you have for developers with regards to DevOps?
A: Use the right tool for the job. We frequently see clients becoming familiar with one automation framework that works well for one application but then they will try to use the same framework for everything. For instance, people will use CI tools for application release rather than finding the best application release automation tool. And people will use application release automation tools when in fact they need ongoing configuration management. Similarly, people use provisioning tools when they need ongoing config management.
Q: How are developers supposed to know which is the right tool for the job?
A: Use analyst relationships and reviews, keep up with Gartner, and articles on DZone. Talk to companies that have already done what you are trying to accomplish and ask them what they use and why. And don’t just assume that a vendor’s product does everything you need. Make them demonstrate that to you in an environment that mirrors your own.
Q: What have I failed to ask you that you think we need to consider with regards to DevOps?
A: When looking at the handoff between the different members of the DevOps team, configuration management is often an afterthought, yet many times this is the first place something goes wrong. Keep configuration management top-of-mind throughout the process.
Opinions expressed by DZone contributors are their own.