Check out my review of the DevOps Handbook and Start and Scaling DevOps in the Enterprise over on The New Stack. Unsurprisingly, I liked both of them, esp. the second: What I find so helpful, and even thrilling, about Gruver’s book, is that it’s exacting in its instructions and walks through several what-if scenarios for addressing common problems that come up when applying agile and DevOps at scale. Plus, it’s the perfect size for a book of this type: about 90 pages that’ll take you about 90 minutes to read.

Check out my review of the DevOps Handbook and Start and Scaling DevOps in the Enterprise over on The New Stack. Unsurprisingly, I liked both of them, esp. the second: What I find so helpful, and even thrilling, about Gruver’s book, is that it’s exacting in its instructions and walks through several what-if scenarios for addressing common problems that come up when applying agile and DevOps at scale. Plus, it’s the perfect size for a book of this type: about 90 pages that’ll take you about 90 minutes to read.

A round-up of all sorts of container stacks, and some advice on what to do: Therefore, the key lessons learned from this event (from developer’s perspective): Do not focus on developing code for the container under the hood. Care instead about the business logic. Implement your microservices in a vendor agnostic way. Do not make the same fault as we all did with J2EE / Java EE where all vendors used the same standard specifications, but still offered many vendor-dependent features and “added value” in their specific “standard implementation”.

This post is pretty old and possibly out of date. There’s updates on this topic and more in my book, Monolithic Transformation. Every journey begins with a single step, they say. What they don’t tell you is that you need to pick your step wisely. And there’s also step two, and three, and then all the n + 1 steps. Picking your initial project is important because you’ll be learning the ropes of a new way of developing and running software, and hopefully of running your business.

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.

I get all ants-in-pants about this whole bi-modal discussion because I feel like it’s a lot of energy spent talking about the wrong things. This came up recently when I was asked about “MVP”, in a way that basically was saying “our stuff is dangerous [oil drilling], so ‘minimal’ sounds like it’d be less safe.” I tried to focus them on the “V” and figure out what “viable” was for their situation.

While HPE is getting $2.5bn in cash, the whole deal value is more like $8.8bn, the non-cash being stock. More details: The Numbers “Under the deal, HP Enterprise shareholders are expected to end up with Micro Focus shares currently valued at about $6.3 billion. Micro Focus will pay HP Enterprise $2.5 billion in cash.” (WSJ) There’s about 12,000 people in HPE Software. (WSJ) HPE Software revenue: “HPE’s software unit generated $3.

The Docker forking hoopla is providing an interesting example, in realtime, of how open communities figure out monetization. #RealTalk: Open communities are not immune to C.R.E.A.M. One of the most important decisions an open source community makes is where and how it will make money. I always liked Eclipse’s take because they’re mega clear on this topic; the ASF plays this goofy game where they try really hard to pretend they don’t need to answer the question, which itself is an answer, resulting in only the occasional quagmire; Linux has a weird situation where RedHat figured out This One Cool Trick to circumvent the anti-commercial leanings of the GPL; MySQL has a weird dual licensing model that I still don’t fully grasp the strategic implications of; RIP Sun.

I have a larger piece on common objections to “cloud native” that I’ve encountered over the last year. Put more positive, “how to get your digital transformation started with a agile, DevOps, and cloud native” or some such platitudinal title like that. Here’s a draft of the dread-ROI section. The most annoying buzzkill for changing how IT operates (doing agile, DevOps, taking “the cloud native journey,” or whatever you think is the opposite of “waterfall”) is the ROI counter-measure.

Elisabeth Greenbaum Kasson asked me recently for advice on working with legacy applications. Check out her piece on it. Here’s the full reply I sent to her in email: Her topics: - The steps someone could take to get themselves up to speed on their employer’s legacy software. - How this knowledge can make them indispensable (I know that term is relative) - Why this type of expertise is so necessary, especially when it comes to integrating said software with new and/or evolving products.