2017 Wheel of Fortune
I mentioned last week I’d have 2017 predictions for you… well, last week. But many of us were distracted on Friday it seems, so I saved them for this week.
So, what do I think 2017 will have in store for us?
Prediction #1: DevOps Will Be Declared 1.0-STABLE
This prediction was originally published in a larger TechBeacon piece on 2017 DevOps predictions. One of the pieces of lint the DevOps community loves to navel-gaze at the most is the “definition of DevOps.” The DevOps Handbook was published last year, and I think that will put the question to eternal rest.
Even though there are numerous other books (and opinions, for that matter) on the subject, I believe The DevOps Handbook will become the de facto arbiter of what officially is and is not “DevOps.” This, I believe, is largely due to the credibility of The Handbook’s authors.
Kevin Behr, co-author of The Phoenix Project, used to say “DevOps is emergent,” and that’s the other important part of this prediction: DevOps will no longer be an emergent practice, due to its codification in The DevOps Handbook. Work is already going on to produce recipe books and workbooks, based on the material in The DevOps Handbook, in order to reproduce its results. Furthermore, there’s a large economic reason for graduating DevOps from the emergent phase: it’s difficult to sell and implement moving-target phenomena. To address that, a definition, optimally an unimpeachable one, must be codified. And we now have that.
In the vein of my 2016 prediction that DevOps will continue dis-integrating, I believe that we’ll see a process of “othering” with definitions of DevOps that are not highly aligned with the The Handbook’s definition, along with pressure to rename those ideas to soemthing other than “DevOps.”
As I note in the TechBeacon article, as for what it means for DevOps, ask me in 2018. But we’ll see this mechanism happen in 2017.
For the record: this prediction isn’t about whether this is a good or bad trend — I don’t really have a position on that — but rather that it is a trend.
Prediction #2: Security Will Come Into Its Own Within the DevOps Space
This year, I think we’ll really start to understand on a macro-scale how to sustainably integrate security operations into software delivery practices that are built upon DevOps’ principles.
There’s been a concerted effort to “extend” DevOps on both ends of the software delivery pipeline, out to product management and the general Business™ on the left, and to security (among other destinations) on the right. Companies who have cracked this nut have had great success, because DevOps practices force you to shift as much work left, up the value stream, as you can. And good security practices become even more effective when you’re able to do this.
In many ways, this is somewhat obvious now: security often played a sibling role to operations, in that it was the last wall that we threw bits over on the way to production. Interestingly, because it was so painful, those value streams often found ways to avoid including security entirely, because it was viewed as painful and unnecessary… right until the point that it wasn’t.
Ongoing coverage of high profile attacks and costly losses have re-emphasized security’s importance. So if breaking down walls and integrating operations practices into the development of software worked so well for operations, why not security too?
Additionally, case studies are starting to emerge that make not only the value, but the actual (successful) practices visible for study and porting to other organizations: there now exist existence proofs of how to integrate security into the delivery pipeline.
One of the other reasons we’ll see a continued, focused integration is because Continuous Delivery pipelines have viscerally illustrated the increased ability to react, in a product/market sense. This increased agility is, in many ways, somewhat of a drug; it’s a bit of a no-brainer that once you integrate security practices into a process that increases agility, not only do you get the benefit of being able to react to security problems (such as bugs in your own code, or bugs in third-party libraries you rely on), you get increased ability to react to other attack vectors, including active threats.
Oh, and as part of this, I also think we’ll start to lose the need to call it DevSecOps or SecDevOps or DevOpsSec: security will just be another expected “DevOps practice,” like automation and configuration management.
Prediction #3: We’ll Start to Remember Release Engineering
As colleagues often tell me: release engineering has a negative connotation. And, in part because of this, may be dying. While I agree with the former (and assume my share of responsibility for it), I wholeheartedly disagree with the latter.
To wit, a lot of the ongoing problems facing our industry today are, in fact, traditional release engineering problems:
- Continuous Delivery pipelines are all the rage, yes. But now that developers — with no release engineering experience —have built them and operations engineers — with no release engineering experience — have built them… I think they’re starting to realize: building them is a unique skill. Building them to be reliable and extensible is a unique, valuable skill. Everyone is discovering that throwing Jenkins on someone’s desktop in an afternoon is not the same as “doing Continuous Delivery,” and without some expertise on releasing software (as opposed to developing it or operating infrastructure), it is naive to expect you’ll be successful in the long term. (And also, releasing software, as opposed to developing it or operating infrastructure is, in fact, a distinct, valuable skill.)
- With the Internet-of-Things heating up, being able to build and integrate native binaries once again becomes an important skill. We’ve raised an entire generation of engineers who are used to writing interpreted code, and may have never actually compiled anything. General shifts in both IoT and back towards mobile raise these thorny problems again, and any competent release engineer will have lots of strategies for dealing with this. (I would note: a surprising number of my clients have products that are web-technology heavy, but have some small agent or device component to them that is entirely native. Google and Mozilla are trying to evolve the web as quickly as they can to “fix” this, but for now, sometimes, you still need to compile USB device drivers and package up and ship a bunch of native C/C++.)
- A lot of the really hard (or, minimally, controversial) problems confronting us — versioning, configuration management practices (specifically around source code CM, i.e. version control tools), software packaging, binary distribution — are all well within release engineering’s traditional wheelhouse. Good release engineers have encountered many of these problems everyone else is now encountering… and we often have numerous solutions from that experience to help.
So ultimately, in 2017, Release Engineering will need to (continue?) reinventing itself; but I also think the organizations that are really able to leverage their Continuous Delivery pipelines and deployment practices will realize they were able to do so because of Release Engineering, as a discipline and a skillset, was the force-multiplier brought to bear on that infrastructure and those practices.
Of course, I could be wrong. Only time will tell…
Have a great year, everyone!
