I have an extra piece in The Register this month. I was asked to frame the history of software product theory between the Cluetrain, Andrew Clay Shafer’s agile infrastructure talk, DevOps, and the “we’re a software company now” trope.
Last year I wrote several columns for FierceDevOps. Nancy Gohring was the editor there and graciously asked me to do so (she’s moved over to being an analyst at 451 and is doing awesome work over there). The FierceEmpire has shifted their stuff around and now it’s either impossible or impossibly tedious to find those pieces, so I moved them over to Medium. I’ve got to get my URLs to be my overly self-referential self, after all!
Here they are:
I cut the below montage-y overview of the history of enterprise open source from a Register piece I’m working on. Here it is!
For me, the dawn of enterprise open source was somewhere around 2001 when IBM committed billions of dollars to shoring up Linux. Around this same time, the Eclipse Foundation (also launched by IBM) started it’s IDE market re-rigging, and the Apache Web Server was climbing the hill to market dominance piloting the way for the rest of the Apache Software Foundation.
Java’s history is representative of open source’s involvement with most infrastructure software. Java started as closed source, holding onto that model like a waterlogged man hugging floating detritus. Despite this, in the 2000s Java’s course was changed by the influence of open source with the likes of Fleury’s JBoss crew (how I miss their pirate-like antics!), Apache Tomcat, and the Spring Framework. These and so many other open source projects acted as forcing functions for innovation in Java and still do. Eventually, Sun open sourced Java, both JBoss and Spring were gobbled up by larger companies, and open source became the norm in the Java world.
To top this all off, Microsoft open sourced .Net in 2014 and now supports a wide array of open source software in its Azure cloud. Open source is the de facto standard when it comes to new infrastructure software.
I started a new column at The Register, on the topic of DevOps. I used the first column to layout the case that DevOps is a thing, and baseline for how much adoption there currently is (enough, but not a lot – a “glass almost half full” type of situation). I was surprised by how many comments it kicked up!
Next up, I’ll try to pick key concepts and explain them, along with best and worst practices for adoption of those concepts. Or whatever else pops up to fill 800 words. Tell me if you have any ideas!
(You may recall had a brief column at The Register back when I was at 451 Research.)
Questions around audit and compliance always come up in discussions about improving software, and certainly when it comes to introducing things like continuous delivery, DevOps, and esp. something as big and different as Pivotal Cloud Foundry. To that end, I wrote up a way to approach those issues, along with a few tips for dealing with compliance and audit for my FierceDevOps column last month.
The onerous steps auditors want you to do were usually put in there for good reason, but, as I put it:
Unfortunately, the way that three-ring binder wielding ninjas and IT staff battle it out over these and other compliance check-lists often loses sight of the original, good intentions. Instead, it infects everyone with a bad case of table-flipping madness. Thanks to cloud technologies and the empathy over table-flipping approaches in DevOps, we’ve been finding ways to get over compliance hurdles and even, in some cases, make compliance projects easier and better.
(Binders picture from tookapic)
Here’s a summary/excerpt of the three ways of thinking through it:
1.) Bottoms-up ROI: We know everything and have put it in this spreadsheet
…if you have a good handle on the costs during some period of time where you were doing DevOps, and the gain that resulted from that period of time, you could come up with a bottoms-up ROI analysis. I think it’ll be somewhat dicey since it’s so hard to attribute costs and gains directly to DevOps but hey, it’s better than either telling people they’re asking the wrong question or its mute cousin: nothing.
2.) Were the efforts to change worth it? That is, DevOps is all cost
…if you want to run the numbers on something like “they tell me it will take three months and $50,000 in training and consultants to ‘do the DevOps'” this might satisfy your ROI craving. Again, you’ll need to have a pre-existing ROI at hand to simply plug your DevOps costs into.
3.) Pain avoidance and remediation
In the “DevOps is all cost” ROI scenario, we avoided ascribing gain to changing to DevOps. Again, while this is overly simplified, the deliverables of DevOps are to provide a continuous delivery process for your product and ensure that your product has excellent uptime. How could you account for the gain of those two desirables? You could create a way of assigning value to the knowledge you gain from weekly iterations about how to improve your product. You could also calculate the savings from avoided downtime.
Check it out, and tell me how you’ve been answering that question.