Mayfly wranglers rule ok!!1

I work in business now. The biggest downside of this is that the distance between me and the things I hold dearest professionally seems to grow with alarming rate. I don’t want to complain about this, but instead I want to share something I’ve learned about this, before I return back into doing what I love.

Business lives from fads. Something that creates temporary and often dramatic movement in the market. The idea of DevOps is a good example. Like the idea of Agile, idea of Lean, or for example Pokemon, Hubba Bubba or those godawful UGG boots for that matter. Why I used the word “idea” instead of just writing DevOps, Agile, Lean, etc? That’s because people have an idea of what for example DevOps is without any intentions to study the history of it or how successful companies and teams have actually applied it. It is something involving development and operations, right? Perhaps some containers? Oh, someone said CI/CD? Jenkins? It’s like new Agile, right? Well, no. But that’s the idea business usually has about DevOps and that’s the level business usually talks about it. Business seeks understanding to the extent of economical feasibility and leaves it there. “Can we sell this?” is often asked. ROIs, break even points, pricing adjustments. If it gets any more complicated than that, business loses its interest. DevOps is tolerated by business as long as it brings meat on the table.

My job nowadays should be to follow the fad called DevOps and build business around it. Sell it. The problem is that I see more in DevOps than just fad. According to Wikipedia, a fad is any form of collective behaviour that develops within a culture, a generation or social group in which a group of people enthusiastically follows an impulse for a finite period. It differs from a trend in way that trends tend to be more explainable, and they follow more consistent patterns, they rise more moderately, they are usually based on human needs and desires, and they tend to last longer. You can build something that lasts over trends where as fads just come and go. By gaining proper, under-the-hood understanding about DevOps and how it affects all company functions we can build something sustainable around it, or better yet, around the models and values that have existed way before DevOps, Agile, Lean, etc. were even a thing, but still are deeply rooted in all of them.

Before getting into brass tacks, let’s admit that business is not the only entity that lives from fads. Techies do that too. Even though you can get credibility in DevOps community by building a kick-ass CI/CD pipeline that uses beautiful container orchestration, perhaps come cloud computing, even machine learning to handle those vast data masses, you might still chase fads. The next version control system, build engine or provisioning tool. The next something as a service. It is extremely hard to build sustainable business over rapidly changing technology and even methods. The moment you manage to wrap something into a concept that could be sold, it’s already obsolete. That’s how fast we move now.

So what to do then? Is there a trend here we could follow and possibly benefit from? We could look back few decades. In the 1970’s and 1980’s mainframes ruled the Earth. COBOL, DB2, etc. Projects lasted years and products even decades. Investments on systems ranged from a million USD all the way up to 100 million USD. Risks affected the whole company and failures led to massive layoffs, selling the company or even bankruptsy. Then came the 1990’s and the age of client-servers. C++, Oracle, Solaris, etc. Projects lasted anything from one quarter to full year and products several years. Investments ranged from 100 kUSD to 10 MUSD. Risks affected production lines or service units, and failures led to revenue drops and/or CIO resignation. The more we arrive to modern age the more we can see that the systems and software are turning into commodities, and that they are going into cloud. Java, Ruby, React, NoSQL, serverless, AI, containers, unikernels… Projects or development initiatives are run through withing weeks. There is constant flow of new product features into production. Product lifecycles are measured in months. Investments range from few thousand USD to 1 MUSD. Risks affect individual product features and no one gets the bullet from failure. Quite the contrary: Failure is often welcomed, because it allows us to learn and adapt to constantly changing contexts.

An obvious conclusion: Soon technology is nothing but mayflies. Extremely short lifecycles, no investments, no drama. THAT is a trend we can use to guide our business. So where we get the money then, if we work in technology? From people. From their expertise and capability to wrangle these mayflies. Let’s use Kubernetes to demonstrate how this wrangling works. It’s the latest and greatest in container orchestration solutions with over 80% market share. A fad, but quite an awesome one. Red Hat OpenShift is a solution where different open source tools have been gathered around Kubernetes. Separately they would be quite cheap or even free, but as Red Hat provides version control, support, etc. it is actually quite expensive. Mayflies wrangled together and business built on that. It’s the same with SUSE CaaSP, Pivotal PKS, Azure AKS, Google GKE, etc. Basically the same Kubernetes stew with different incredients and spices. In many ways all this reminds me of CDOs, but that would be another, albeit interesting topic.

“Can we scale this?” is asked almost as often in business tables as “Can we sell this?” Business wants to fight this mayfly phenomenon by giving the products time to scale and produce proper revenue. But even with enterprise software the lifespans are shortening with increasing rate. The bravest are drawing architecture horizons two-three years ahead max, because even they know that things will change. Angry Birds and Pokemon GOs are lottery, new SAPs will be microservices and even Microsoft has started play ball with the open source community, and its mayfly wranglers. These heroes, when treated properly, are the key in building just the right systems to your or your customer’s business needs. Heavy customization over short-lived fads, consultation, support, production use, you name it. People. I know, people won’t scale, but people will ultimately build you something that scales for that microsecond you get to gather revenues in the future.

PS: I could’ve supported my confirmation bias with some research and rock-solid references, but I felt like publishing this rant quickly and getting discussion going. Sorry.

Leave a Reply

Your email address will not be published. Required fields are marked *