Bulletin 21 September 2018. The first law of commoditisation
Technology is still blooming hard.
Most careers, for better or worse, start in actually doing things, progress through telling people to do them, and end with deciding how they should be done. I know a few people who, having followed such a course, decided management wasn’t for them and went back to a hands-on role, a move which is either called a mid-life crisis or common sense, depending on your perspective.
For a techie, it can be easy to lose touch, to forget the whys and wherefores of what makes all that clever digital stuff work. We are told it is simple, and very often it is: the world of RESTful interfaces (a.k.a. exchanging information between programs in neatly formatted plain text), cloud-based services and so on have taken away a great deal of the pain.
When things go wrong however, they can be just as awful as ever. Why? Largely because there’s too many possible options. Older operating system versions. Deprecated interfaces. Ancient libraries to retain compatibility with.
We can talk about a lack of skills, but the smarts required to understand such a morass are based more on some Sherlockian attention to detail than specific expertise. Problem solving is detective work, with root causes sometimes a long way from symptoms.
Case in point: today I managed to get a small PHP package running on my web site. Why wasn’t it working, I hear you ask: well, I say. First, after much hair-pulling and message passing with the help desk, I email to say how it seems strange that the PHP version isn’t changing when I flick the option in the control panel.
Ah, they say, that’s because you are pointing at the wrong server. We migrated you a while back, but (and this part was silent) neglected to tell you. Suddenly I have an explanation as to why nothing I did (about getting a certain library installed) made any difference.
This wasn’t the end of the story (I won’t bore you with the extra security features that broke everything, nor the absence of a directory for session information) but, well, it was interesting reminder of what we might call the first law of commoditisation: nothing is actually commoditised, all that we’ve done is stuck a layer over the top, a facade if you will.
So, work above this layer and all will be well. But woe betide should you delve beneath, either deliberately or because you fall down some technological fissure. Far from everything becoming simpler, it continues to become more complex. It’s enough to drive a systems engineer to drink, and speaking of which:
Smart Shift: There is truth in wine
As mentioned last week, I shall be uploading my book to the web, section by section. This week, a story of sensors, drones and data articulated through the medium of wine. I’ve also added the foreword. Any and all feedback welcome: either this will become a living document or (more likely) I will learn from it and move on. Which is already a good thing.
Oh and yes, it was this very same PHP package I was tussling with.
Strategy & Technical Considerations for Successful Enterprise DevOps
Finally, finally, finally, my report on enterprise DevOps has been released. I have learned a great deal, not least that we are still at the starting blocks — not least because of all the complexity mentioned above. If you don’t want to read the words, I recommend that you check out the picture. Meanwhile, here are some of the articles I wrote along the way.
Is Enterprise DevOps an Oxymoron?
The Five Cs of DevOps at Scale
Seven lessons from writing the report, Scaling DevOps in the Enterprise
Five steps to delivering DevOps at scale
Could DevOps exist without cloud models?
Extra-curricular: The Day of Gloaming
While the manuscript of my novel is with a reader, I thought I’d write a short story. The tendril-laced premise literally came to me in a dream. Enjoy.
Every week I get feedback from a number of people, positive and observational, which I look to feed into my thinking. Thank you for reading and sending, and keep it coming!
Jon
