DevOps initiatives shouldn't just touch the new stuff

Although I feel as if it’s been dispelled to a significant degree, there lingers the misperception that DevOps [1] is mostly for companies that sport ping-pong tables and have free sushi for lunch. Firms that manufacture construction equipment and have large swaths of legacy computer code? Not so much.

It’s not particularly surprising that this misperception exists. A traditional IT organization glances at a company like Netflix and they may see a unicorn wholly unlike themselves. They’re not even entirely wrong. More extreme implementations of approaches such as microservices or near-continuous production releases likely won’t become the norm—especially in the “classic IT” (aka Mode 1) parts of their infrastructure. However, that doesn’t mean DevOps principles can’t also benefit the conservative IT of conservative firms.

It’s about the software

The first reason that DevOps practices apply outside of greenfield, cloud-native (aka Mode 2) IT is that the rules are changing. The “software is eating the world” meme has become something of a cliche but it’s no less true for that. As my colleague James Labocki wrote in a recent post, "Bank of America is not just a bank, they are a transaction processing company. Exxon Mobil, is not only an oil and gas company, they are a GIS company. With each passing day Walgreens business is more reliant on electronic health records.” Furthermore, as James also noted in that post, these shifts in technology and how business is transacted are creating new competitors that come at you from non-obvious directions and places. 

Therefore, while the priorities for classic IT may be different from those of cloud-native, it still needs to change. I’ll go so far as to say that calling this “legacy” is a potentially dangerous turn of phrase as it implies static and in need of wholesale replacement. In fact, to quote James one last time:

In mode-1 they [IT] are looking to increase relevance and reduce complexity. In order to increase relevance they need to deliver environments for developers in minutes instead of days or weeks. In order to reduce complexity they need to implement policy driven automation to reduce the need for manual tasks.

 Getting there requires DevOps tools and approaches (together with policy-based hybrid cloud management).

DevOps thinking is proven to work in traditional industries

I thought DevOps was pretty new, you cry! In some ways, DevOps as we usually talk about it today is indeed the child of pervasive open source, continuous integration technologies, platform-as-a-service (PaaS), software-defined infrastructures, and a host of other relatively modern technologies. However, as Gartner points out in “DevOps is the Bimodal Bridge” (paywall):

Mode 1 organizations can use systems thinking for incremental improvements, such as reductions in waste and improved risk mitigation. While DevOps has embraced these methodologies, the concepts have, in fact, decades of real-world application in manufacturing and other industries.

(Here's one version of a presentation I give from time to time about the lessons from manufacturing for DevOps on Slideshare.)

Gartner also maintains that: "there are many elements in DevOps that may, in fact, apply across the modal spectrum. It is our firm belief that by 2020, at least 80% of the practices identified with DevOps and Mode 2 will be adopted by traditional Mode 1 groups for the overall benefit of the organization."

The need to work across IT

One number from a recent IDC InfoBrief sponsored by Red Hat “DevOps, Open Source and Business Agility: Lessons Learned from Early Adopters” (June 2015) popped out for me even in the context of multi-modal IT.

A majority of organizations (51 percent) don’t plan to have a dedicated DevOps organization. (36 percent do and 13 percent were unsure.) From my perspective, this is mostly a positive result. While dedicated organizations may suggest commitment and focus, they can equally mean stovepiped projects that don’t address the needs of or solve problems for the mainstream IT organization. As a result, their scope may be limited and fail to integrate with core IT systems. 

As Cameron Haight notes in another Gartner research note: "Initial DevOps toolchains are often focused on tactical integration scenarios, thereby restricting the ability to develop more flexible, general-purpose architectures."

Even when it makes sense to initiate DevOps as a pilot project, it’s important to keep attention (of both management and the DevOps folks doing the hands-on work) focused on the end business benefits, which should be the ultimate drivers. In the aforementioned IDC InfoBrief, employee productivity and business revenues were seen as important DevOps business impacts. But the #1 impact? Increase customer satisfaction and engagement. You’re not going to achieve that with a project touching a small portion of your IT. 

[1] Here’s how we define DevOps at Red Hat. 

DevOps is an approach to culture, automation, and platform design for delivering increased business value and responsiveness through rapid, iterative, and high-quality IT service delivery. It applies open source principles and practices with: 

• Culture of collaboration valuing openness and transparency
• Automation that accelerates and improves the consistency of application delivery
• Dynamic software-defined and programmable platform

My fave carry-on luggage

I travel a lot. Sometimes too much. And I get asked by a lot of friends and acquaintances about gear and other preferences. I’ve been meaning to write some of this down for a while. Here’s my start.

Let’s start with my biases. I avoid checking luggage whenever possible, which is mostly any week-long business trip to start with and many other cases as well. I consider roll-aboards to be the instrument of the devil for anyone who is otherwise physically able to carry a shoulder bag or doesn’t have another specific need. They hog overhead space and trip you up on concourses. You should require a handicapped sticker to use one. 

So soft luggage. Carry-on. What are my preferred options?

My go-to for business travel is the Patagonia MLC. (MLC = Maximum Legal Carryon) It’s got a nice shoulder strap as well as some thin backpack straps. Bomber zippers. A couple of outside compartments suitable for typical travel gear like pens, earphones, Kleenex, etc. My friend and former colleague Stephen O’Grady has called it the perfect luggage. 

I don’t go that far. A couple demerits:

The primary thing that I find sub-optimal about the MLC is that it divides the main compartment vertically. I find that this makes it difficult to pack rectangular or square-ish shapes or even bulky shoes. I get the desire to create separate zones in luggage but generally I’d just as soon use stuff-sacks, laundry bags, Eagle Creek cubes, or even a supermarket plastic bag within a larger space to separate dirty clothes and the like.

The zippers are also wrap-around. This makes it somewhat easier to squeeze in tight loads but it also makes it easier for casually closed zippers to shed contents in the middle of an airport. 

I’d also note that the thin backpack straps are intended for carrying modest loads for modest distances. But the MLC isn’t really intended as a “travel backpack.” It’s a reasonable tradeoff given that the backpack straps are not the focus of the luggage.

An alternative that I also use regularly is the Osprey Porter 46, which is much more explicitly in the vein of a travel backpack without silly distractions like the wheels or rigid hunks of material that many products in the category sport. While I wouldn’t want to carry it on my shoulders were it filled with lead weights, the shoulder straps are reasonably padded and it also includes a hip belt. Like the Patagonia bag the zippers and general quality are all solid.

While not rigid, the Osprey pack does loosely hold its shape. It’s primarily one large compartment although there’s a zipper at the top to a small compartment that basically takes its volume from the main compartment. As noted with the Patagonia, I’m generally good with the flexibility of this approach.

The Osprey is very much a travel backpack. It has a well-made padded handle but there’s no shoulder strap and it’s not really designed to be carried other than as a backpack. I generally take the Osprey when I know I’m going to be schlepping my luggage around a lot on foot, while I take the Patagonia on a more typical business trip.

There’s also an Osprey Porter 65, which has a 65L volume rather than a 46L volume but is otherwise identical to the smaller model. This bag is not airline carryon compliant but is typically fine for trains. Now, I’m certainly not going to encourage people to take oversized bags on planes, but I would note that this is a relatively soft compressible bag so it can generally be put in an overhead if it’s only partially filled. I’ve done this at times when I’ve wanted the extra space at my destination to consolidate my laptop etc. bag in my luggage for walking around cities or traveling on trains or when I’ve wanted some extra space for purchases that I can then check for the trip home. 

Links for 11-20-2015

• 13 miles of typography on Broadway, from A to Z — Hopes&Fears
• What Would the Father of American Football Make of the Modern Game? - The New Yorker
• Official Google for Work Blog: Investing in our business for the future - So Diane Greene has headed over to Google
• Critic Rating of Bestsellers: Non-Fiction Bestsellers books for week of Nov 15 2015 | iDreamBooks
• The 20 Most Extreme Cases Of ‘The Book Was Better Than The Movie’ | FiveThirtyEight
• Does cloud-native have to mean all-in? | Red Hat Stack - 1st of series of posts over at Red Hat Stack expanding on an @IDC Analyst Connection about moving to cloud-native.
• In defense of a photographer Patrick Schneider
• Stock Photos No License-Alana | Free Stock Photos
• The rebirth of the HP-12C: How one man reimagined a calculator from 1981 | Alphr
• www.nycsubway.org: NXSYS, Signalling and Interlocking Simulator
• You Can't Understand ISIS If You Don't Know the History of Wahhabism in Saudi Arabia | Alastair Crooke
• Chipotle Serves Up Chips, Guac & HR Email — Krebs on Security - Yep. Just dig your security mess-up hole deeper. Go ahead.
• IK Multimedia | iRig Mic Lav - Lavalier microphone for iPhone, iPod touch, iPad and Android devices
• The Math Behind the Rolling Shutter Phenomenon
• How Walter Murch Perfectly Merged Apocalypse Now and “Ride of the Valkyries”
• How the Mad Men lost the plot - FT.com
• The Tacoma Narrows Bridge collapse
• Woman Fights Off 800-Pound Alligator In Mall Parking Lot | GOOD - As if we needed another reason to avoid Texas
• 4 Ways to Upgrade Your Trail Mix | SAVEUR
• Actor-inventor Hedy Lamarr: Is today’s stunning animation the greatest Google Doodle yet? - The Washington Post - Hedy Lamar Google doodle

Survey says: Who owns DevOps strategy?

I’ve previously written about the overall results from IDC’s “DevOps, Open Source and Business Agility: Lessons Learned from Early Adopters” InfoBrief study sponsored by Red Hat. I encourage you to take a look as there’s a lot of interesting data about enabling technologies, Platform-as-a-Service (PaaS), open source, and desired software support models.[1] This post though dives into a specific result that ended up on the cutting room floor when the final InfoBrief was edited.

"Of the following stakeholder groups, which has the primary responsibility for driving your organization's DevOps strategy?"

The plurality but not the majority (38 percent) said that traditional application development teams had the responsibility. Other common answers included traditional IT operations teams (19 percent), dedicated DevOps teams (17 percent), and corporate C-level executive teams (13 percent).

I don’t find those overall numbers particularly surprising. DevOps tends to be thought of as being more about accelerating application development and release cycles than streamlining infrastructure operations.[2] So it’s pretty natural that devs would be seen as driving an initiative that most directly impacts them. (That said, in another survey question, 47 percent said that IT operations staff efficiency/productivity improvement was a primary DevOps goal so there are absolutely both dev and ops benefits.)

I might have expected to see more dedicated DevOps organizations driving strategy, at least in today’s early going. [3] However, our internal experience at Red Hat is that dedicated organizations can end up operating independently of the existing IT organization—making it hard to tie into existing apps and infrastructure. Therefore, I find the fact that early adopters are mostly viewing DevOps as something to be driven as part of mainstream IT rather than as an off-to-the-side project a good thing.

Slice the data based on how app devs answered and how IT ops answered though and things get interesting (if still not wholly unexpected).

It’s apparently quite obvious to your average developer who is or ought to be running the DevOps show. They should (76 percent) with another 10 percent allowing for the possibility of a dedicated organization driving the strategy. A mere 3 percent have IT ops driving things.

How did IT Ops answer? Well, they’re even more certain than devs that their counterparts shouldn’t be running DevOps with only 2 percent saying that traditional application development organizations have the primary responsibility for driving DevOps strategy. Beyond that near-unanimity though, they’re pretty divided. Only 34 percent said the traditional IT operations team should be in charge. Other responses were split between a dedicated team (24 percent), a corporate C-level executive team (21 percent), line of business decision makers (7 percent), or even a service provider like a system integrator (9 percent).

Pretty much anyone except their own developers I guess.

[1] Survey respondents were 220 IT decision makers in the US and UK who were either currently using DevOps in production or evaluating/testing DevOps.

[2] I’d argue that this dev-centric view isn’t the best way to think about DevOps, but it’s common.

[3] Note, however, that this question was specifically about who is driving or will drive strategy. A materially higher number (35 percent) have or plan to have a dedicated DevOps organization. That organization apparently just won’t drive strategy in many cases.