If there's one thing Simon Maple knows, it's DevOps. But actually understanding the topic in depth comes with a price. Maple, the technical evangelist for ZeroTurnaround, feels like he's banging his head against the wall whenever the trend gets co-opted by the clueless. Since that happens pretty much all the time, he's acquired quite a headache. The worst part is that people don't even understand the words that are coming out of their own mouths. "One of the biggest annoyances for me, personally, is the term DevOps. Everyone wants to jump on the bandwagon, so they call whatever they are doing DevOps." So then, what exactly is DevOps?
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
According to Maple, DevOps is three things. First, it's about trying to find the slickest path through the business from the developer over to production. This means looking at developmentand operationsas an entire workflow, not just two separate but consecutive processes. Someone has to be willing to stand back and take in the bigger picture.
Second, it's about making the feedback loops as short and as loud as possible throughout the cycle. Having a short feedback loop means problems are identified as soon as possible and the relevant information gets back to the dev team as quickly as possible. Letting it pile up and figuring it can be dealt with later isn't acceptable. That's one reason the feedback also has to be loud – so it can't be ignored. The feedback loop must be monitored and team members have to be accountable for actually following through and addressing the issues that have been raised.
(For an interesting examination of what this looks like taken to the extreme, check out HCL Technologies with its Employees First philosophy. This company actually extends the feedback loop past operations and to front line employees in a novel way, making developers directly accountable to sales and customer service for how well their solutions work.)
Finally, the company must embrace the fact that the developers and operations teams need to understand each other and the roles they fulfill. According to Simon, "If you don't have this area in and around DevOps, steps one and two aren't going to succeed." In fact, step number three is both the most foundational and the most difficult to achieve since it may entail a full-scale cultural shift.
What DevOps is NOT...
Maple makes it clear that DevOps isn't a title. It doesn't matter how many people on LinkedIn are advertising themselves as DevOps Engineers. It doesn't matter how many recruiters are taken in by this label, thinking they've found the magic person who will fit the bill. DevOps simply isn't a one man job. "It's a way that you structure your team, and a way you allow your team to work.
There are tools available for continuous integration and release management (like the solutions from LiveRebel) that can enable the three steps outlined above. But tooling alone doesn't enable DevOps. "It's a mindset. Companies need to understand that you can't buy DevOps. You understand and invest in DevOps as a team, a process and a lifestyle." That process can happen on purpose with full buy in up front, or gradually by stealth as part of the natural evolution of a company.
Assuming an organization is ready to make the leap to DevOps, LiveRebel is on hand to make that transition successful. These tools help development and operations teams to work in a more automated way, increasing speed and reducing failures associated with manual steps. In simple terms, the product automates and orchestrates application deployment. Orchestration is key here, since simply making everything easy to do with a click of a button can actually be a disaster if you're doing the wrong thing at the wrong time in the wrong way.
To avoid these issues, the LiveRebel solution bundles the config, database, and application code together for a seamless upgrade experience. The Dev team selects the environment and applications to move up to the next level and the upgrade is automatically coordinated and implemented. It's even timed to avoid killing existing http sessions so users don't experience downtime. If there's a problem at any stage, LiveRebel can automatically roll back the whole shebang to the previous working state. You can literally walk away and know that when you come back, you'll be okay—either in the new state or in the previous good state.
Why is giving Dev more visibility into Ops a good thing? When developers can grab hold of automation and understand the early stages of deployment, they start to truly understand the implication of their choices. As Maple points out, "What you choose in development, you support in production." With a deeper understanding of these consequences, Dev can make smarter decisions and fully support the Ops team in doing their job. It's a positive feedback cycle that just keeps making things better.
How do you define DevOps? Let us know.
Follow Simon Maple on Twitter: @sjmaple