IT innovation maze.

Finding my way out without AI.

Where are we?

I don't want the title to confuse you. This article, unlike most of them today, is not about AI. I hope it will be useful to engineers who often spend too much time in the trenches and may feel that they're falling behind rapidly changing industry trends.

I want to talk about evolution. We tend to visualize it as having a linear upward trajectory, where the new is always better than the past. And it is so tempting to jump on the bandwagon and go along with the "next big thing" without questioning how and why it turned big in the first place. What if we are just taking a mental shortcut to presume that a new idea is better, yet in fact, it is not?

Let me explain. Take software development, the industry in which I have spent 16 years working. The Cloud Native Computing Foundation (CNCF) is a trend today. However, many of us developers find it overwhelming to keep up with the pace of new development tools that are constantly being mass-produced. We have a dilemma. While staying current is important, it is impossible to follow every trend blindly. So, what is our best strategy as a technology practitioner or an executive?

The common sense, narrated by the ChatGPT, says it is important to stay up-to-date with industry trends in software development, but not at the expense of practicality. By waiting until a trend has proven its worth before investing resources, businesses can avoid wasting time and money on tools that may be quickly outdated.

It is reasonable, but it raises another question, how do I know that technology has proven its worth? When I asked to provide supporting evidence to its previous claim, AI gave me this:

"To illustrate this point, consider the example of Kubernetes, a popular container orchestration tool that is part of the CNCF ecosystem. While Kubernetes has become a staple in modern cloud computing, many businesses invested in earlier container orchestration solutions that Kubernetes quickly eclipsed. By waiting until Kubernetes had proven its value, these businesses could have saved themselves the time, effort, and expense of adopting and later abandoning a tool that was quickly becoming obsolete."

And that's where it gets interesting. Clearly, it forces me to take a mental shortcut and reiterates the frequently popped-up idea on the web with which I simply cannot agree. I am not the only one. I am going to indulge in two different opinions from two accomplished people in our industry, each explaining why businesses could be discouraged from investing in K8s.

Cloud providers aside, it is not at all clear to me that K8s, and containers in general, have already become the standard. It is even less clear that they will be the standard in the future. The argument I will defend is that many companies prematurely embraced this new norm, and there are better strategies than this one.

Though K8s was at the center of discussion up to this point, the further conversation will focus on the larger topic — the Cloud and CNCF as a foundation that promotes it. Kubernetes, a flagship of CNCF, is still just one project of many.

It did not fulfill its promise, so we're out.

Everything is a trade-off. When you look at software development from the management perspective, this trade-off is usually pictured as a triangle of "cost — speed — quality." Improvement in one or two always comes at the cost of the third. The first thing that Cloud provides is the speed of infrastructure provisioning and, to a lesser extent, the quality because Cloud companies have deeper expertise. According to project management rules, we pay the price for it. And now the price is way too high.

A known critic of this fact is David Heinemeier Hanson, the Ruby on Rails creator and CTO of Basecamp. His company is leaving the Cloud, and he is constantly hammering Cloud pricing, hyper-marketed ideas, and the rest of the venture capital-driven craze.

If I distill his writing, it can be summarized in a few sentences. The Cloud is too expensive, and Kubernetes is too complex. While the Cloud is marketed as the universal solution, only certain businesses can benefit from it:

• If a company is an early-stage startup that needs to develop and test hypotheses fast.
• Applications with very irregular load that require unlimited on-demand infrastructure scaling up and down.

For the rest, the convenience of infrastructure provisioning comes at a huge price. We expected a reduced infrastructure team headcount from K8s, instead, we kept hiring DevOps engineers, and the team only grew from the times of System Administrators and their pets.

Hanson's argument is strong. As an executive, he is looking for ways to optimize the business asap. For a medium-sized company with predictable infrastructure and hardware requirements, paying a premium for renting servers is inefficient. Investing in their own computers is a more cost-effective way. As an engineer, I find it compelling too.

I do agree that K8s is too complex. To cut off all the noise and return to good old times may not be so bad in the short term. Is it, however, a good long-term strategy? Shall I gamble with the idea that K8s never become simple enough and the Cloud never gets cheaper? Or will I be better off joining the growing mainstream, investing in Kubernetes, and locking myself in the Cloud Managed services? What if both of these evolve and become more affordable without losing their original appeal?

The dilemma rests with the engineer more than with anybody else. DHH is doing the right thing as an executive, doing what is best for the business. If the tides change, he can hire modern infrastructure practitioners and move his business back to the Cloud. As an employee, I want to be ahead of the game, or at least in the game, to be relevant in the future job market.

Regardless of the position in the company, everyone is interested in predicting which technologies are here to stay and which will be forgotten. Looking again at the CNCF landscape, I am sitting on the fence.

Is evolution actually coming?

This brings us to the topic of evolution. In biology, a situation when a once-promising branch of evolution turns out to be a dead end is called extinction. I asked myself if extinction ever happened in technology. Imagine if container orchestration solutions replaced one another, all of them never worked as expected, and finally, we've decided that running applications on bare metal is the best option. Examples like Enterprise Application Containers (J2EE) come to mind. For those interested in details, this presentation by Mark Little gives insight into their fast rise and fall (the author also shows how often we promote similar ideas that we as an industry abandoned decades earlier. Which is another interesting topic worth exploring).

And yet the industry is moving somewhere. Maybe the answer to the future of the Cloud is in the past, but I couldn't find it.

So I kept searching and came across Wardley Mapping. The book is full of insights, which I am still in the process of comprehending.

One of them is the visualization of technological evolution as a transition from Genesis to Custom Build, then to the Product, and in the end, to Utility.

Application Containers never jumped from Product to Utility. The Product stage is where the business model is already well-defined, businesses make the highest profits, and competition exists, but there is enough market share for everyone. When the Product transforms into Utility, it attracts more mass customers, accompanied by a significant price drop, thinner margins for business, and no room for growth and innovation.

Wardley explores "climatic patterns" that force the transition to the Utility stage, even though it is met with the opposite force — Inertia, from the businesses whose margins will decline. One of the climatic patterns is called the Red Queen hypothesis, borrowed from biology. It essentially shows two things:

• Transitioning from one stage (Product) to another (Utility) is inevitable, but only if new entrants can compete. The part of established businesses' Inertia is an attempt to establish an economic "moat" so that the entry bar for competitors is high.
• Technologies failed to adapt will be extinct. To conclude the discussion of Application Containers, as per Mark Little's presentation, the key idea was the collocation of different applications in one server (at that time, CPU speeds evolved much faster than the network, so having one big server with multiple applications running on it was a good choice). The solution was too complex and eventually lost to another collocation approach — virtualization and, subsequently, containers.

Cloud computing is certainly at the Product stage of its evolution. Only a few big players exist. But for the most part (which is renting out servers), the entry bar is relatively low, and we already see the competition growing.

Simon Wardley also predicted a long time ago what the Utility stage would look like — it is Serverless. And K8s is just a means to achieve this end and will eventually be abstracted away by Cloud vendors. So companies investing in building their own container orchestration environments are wasting time and money.

According to the Wardley Mapping, we should either expect lower costs from Serverless or higher speed of production and quality. I can't say that development is way easier (support for lambda functions in modern IDEs is just starting to show up). But we already pay the price with poor performance right now (how many times have you seen this article recently?). The Serverless is in the same state that Application Servers were back then. Redundant complexity killed Application Servers. Pricing and performance are the issues that Serverless has to solve to avoid extinction. The only competing approach to Serverless is running your own application stack like Basecamp will do. But that's backward movement, which contradicts the evolution theory.

Indeed, we may have to wait longer.

How many ads are too many?

So, I have described some evolutionary forces. Let's examine what kind of energy these forces create. Technological innovation is driven by a few centers, with Silicon Valley being the most notable. Their funding comes from venture capital. When more money had flown into the market in recent years ("money printing," you know…), a big chunk of it was funneled into venture capital and startups. As a result, we have more startups, and we have more products each one of them is offering.

More products cause higher competition, and long gone are those days when free markets decided which product was the best. We live in a world where marketing strategies manufacture demand. Software products are no different, and startups spend enormous amounts of money on marketing. Luckily, extensive funding covers all the costs. Ads and sponsored articles flood the internet, and eventually, "the Cloud is the new default" because the internet keeps saying it.

If you look at the CNCF landscape, funding is everywhere. Attached to every logo is the number of money raised. It's strange that you often have to click away to find the project's goal and sometimes can't even find the information. Sam Newman, the Microservices champion, in his InfoQ podcast, says it is the "sign of success, but it's a bewildering sign of success." Can't agree more. In times like this, success is measured in the money attracted, not in the number of customers or revenue.

The bottom line is to stop trying to "google" what people think about a product. You won't find the truth.

Conclusions.

I still can't tell with certainty which technologies will survive in the long run (if I could, I'd probably do investing, not programming). With an evolutionary approach, I am better now.

We have multiple forces, pulling each development in many directions. On the one hand, marketing promotes products as if they are already a Utility (and everybody uses utility; one can't live without it). At the same time, they are still Products (and their creators are interested in acquiring new customers while the price is still high). On the other hand, evolutionary forces eventually bring the product closer to being a commodity (competition). Refrain from confusing marketing pitches with reality (Serverless is far from being a utility), but do not deny the idea completely (current pushback against Serverless will force it to evolve or leave the stage for a better approach).

The Cloud will be there, but it needs to overcome the Inertia of big players and become more affordable. At the moment, it seems plausible that companies will follow Basecamp and invest in their own infrastructure instead of paying significant rental prices.

Serverless is simple. I'll take it if it becomes mainstream with a practical pricing model. At the moment, it looks like a niche product to me, not every software application fits into a serverless model. That's a topic for another story.

Key takeaways:

• Investing in on-prem hardware makes sense if your application has a predictable pattern and is built from open-source components. Cloud Managed Services, while easier to launch, will keep you hooked on rental prices forever.
• Investing in on-prem hardware makes sense if you have an established business and going through the cost optimization process (Lean, Six Sigma). But keep an eye on the Cloud.
• Running your K8s is too complex. If you are going down this path, consider using managed service from the Cloud (EKS, GKE). But look at what you're gaining from it; maybe taking one leap forward and using Serverless is a better option. The programming model is simpler, and it promises to simplify operations.
• Only a few Cloud services have big moats, so you have virtually no alternatives. Google's Spanner is your only option if your business needs a fast, strongly consistent, globally distributed transactional database. Another example is services like EMR or Dataproc, which allow you to use many hardware servers temporarily.
• If you look at what seems to be technological advancement (solves the problem) but requires investment, try to see if this thing is transitory and if an improved solution is just around the corner (sounds simpler than it is).
• Marketing has become the main approach to creating economic moats. Still, only a few companies have ever built strong brand moats (Coca-Cola, Apple), so look at the technology first and see if it solves some problem you can't solve yourself efficiently (keep in mind that it will evolve).
• Do not take mental shortcuts. Listen to voices of reason. Neither Google nor ChatGPT will give you the way out of the maze. In this article, I referenced people who share their honest perspectives without big claims and marketing pitches.

So what is my strategy? It may sound like trivia, but investing time in understanding the underlying forces is always a winning strategy (first principles). The common sense was right. There are too many options to make a bet with a high probability of success, so only choose from technologies that stand the test of time. Economic tides have changed, budgets are shrinking, and some projects will not survive. Scrutinize those that survive and see if they look like the next step in technological evolution (I'd suggest following Wardley Maps).

I hope the article helps others to navigate the waters a little better, too. For those interested in investing, the latest prediction from Simon Wardley is conversational programming (1 and 2), and with recent AI mania, we seem to be moving in that direction fast.