At the start of 2015, Gartner predicted that DevOps adoption would evolve from a niche to mainstream enterprise strategy, resulting in 25% of Global 2000 companies drinking its Kool-Aid by 2016. And while the hype—tempered by the realities of implementation—has more or less died down as of late, the methodology's value to enterprises is no longer a debatable matter. Here are some highlights from 2016 detailing how the year panned out for DevOps and its practitioners.
Last month, around 1.3 million records belonging to over half a million blood donor applicants were breached when the Australian Red Cross' web development agency Precedent left a database backup exposed on a public website. The venerable non-profit has since taken responsibility and apologized for the incident, despite being the fault of a third party agency. If anything, the mishap serves to illustrate that resilience—not stronger cybersecurity—is the key enabler of safe healthcare digitization.
Government/politics, and cybersecurity—these topics may seem plucked from recent U.S. election headlines, but they're actually themes that have persisted over the last decade, reaching a pinnacle with the massive OPM data breach that resulted in the theft of over 22 million records—fingerprints, social security numbers, personnel information, security-clearance files, and more. Last month, a key government oversight panel issued a scathing 241 page analysis blaming the agency for jeopardizing U.S. national security for generations. The main culprit? Lack of visibility.
This is not an opener for a sex-ed public service announcement, but in fact the million-dollar question for today's enterprise CISOs and CROs: which vendor in the supply chain will prove to be the riskiest bedfellow? With 63% of all data breaches caused directly or indirectly by third party vendors, enterprise measures to bolster cyber resilience must now include the evaluation of partners' security as part of a broader cyber risk management strategy. Easier said than done: most third parties are unlikely to admit to their security shortcomings, and—as it turns out—even if they did, most firms wouldn't believe them anyway.
DevOps has proven to be more than just an industry buzzword, but as the term starts to gain widespread use in modern software development parlance, an emerging successor has begun to take hold: Rugged DevOps, also known as SecDevOps/DevSecOps. RSA Conference (RSAC) 2016 dedicated a track to the emerging practice earlier this year, so it's likely to become as prevalent as its predecessor by next year's end—especially since RSAC plans to highlight the methodology again in 2017.
As it has been said many times: DevOps is not a technical problem, it is a business problem. The struggle for a large, entrenched Enterprise IT shops can't be underestimated and the legacy factor has to be dealt with (aka. why fix something that isn't broken). However, there is mounting evidence to suggest that independent, discrete teams are in fact becoming more common in these large Enterprises. While the fully-embedded model (sometimes called NoOps because there is no visible/distinct Ops team) that the unicorns have deployed work for them, a more discrete team to learn how to 'do DevOps' makes a lot of sense for the larger Enterprise.
I recently had the opportunity to sit down with Mike Kavis (@madgreek65), VP/Principal Architect at Cloud Technology Partners, in preparation for a webcast we’re hosting next week and asked him a few questions. He was kind enough to entertain my line of questioning and provide some of his thoughts. If you don’t know Mike, you should, but here is what you need to know...
There has been plenty of discussion as of late regarding whether the DevOps movement has left the “enterprise” behind, plus where automation and the cloud fits in DevOps. There is more and more evidence that automation creates less collaboration and shows signs of a turf war between the chasm of tools that are needed to ‘do DevOps’. In the spirit of trying to address and debunk some of these myths, we asked Kevin Behr, the co-author of The Phoenix Project: A Novel and the VisibleOps Handbook to join us in a discussion about some of the trends plaguing enterprise IT as they struggling to align legacy IT infrastructure to business goals while becoming more agile.
Automation. If you're somewhere on the DevOps spectrum then it's surely good for what ails ya. The answer to all your problems. For many it defines their DevOps journey, its destination representing the promised land of stable environments, consistent builds and silent pagers.
When I attended the DevOpsDays event in Mountain View (well, Santa Clara really) a couple of months ago I started writing a blog post on my impressions. I was a bit distracted at the time though after having had a minor twitter spat with a well known DevOps proponent on the first morning. I won't go into any detail here other than to say that it was sparked after I made a comment that I felt "DevOps" vendors need to be doing more to ease the transition for large Enterprises.
Designing and building a race car using the typical lifecycle process used within an Enterprise IT department. Sounds like a good idea, no? No. It's a terrible idea, but it's fun to paint a picture of how it may work out to illustrate what goes wrong today in so many Enterprises. For this exercise I'm going to assume that there are four main groups. The design team (analogous to IT Architects), the manufacturing team (development), the safety team (security) and the mechanics (operations). Here is how things may turn out.
Those of us who haven't worked in the Enterprise probably don't know a lot about ITIL (Information Technology Infrastructure Library). ITIL may even be a source of amusement for them. C'mon, they would say, how much practical use can you get from a methodology that is defined through a set of books that is actually referred to as a "library"?
OK, so I was supposed to be blogging this weekend but I was bored of blogging so I instead decided to combine two things I'm terrible at, illustration and comedy, and do a comic instead. I deserve to be punished for this so please, flame away :)
Cyber resilience is a fundamental change in understanding and accepting the true relationship between technology and risk. IT risk (or cyber risk, if you prefer) is actually business risk, and always has been. And the cybersecurity industry, for what it's worth, has generally avoided this concept because it goes against the narrative that their respective offerings—whether it's a firewall, IDS, monitoring tool, or otherwise—would be the one-size-fits-all silver bullet that can keep businesses safe. But reality tells a different story.