Comment by parasubvert | Hacker News Reader

Comment by parasubvert | Hacker News Reader

I spent a significant amount of my career working on opinionated software (Cloud Foundry), which still is used by larger companies to give devs a Heroku-like experience on their own clouds, that was steamrolled in the market by unopinionated, rather complicated, “one framework to rule them all” software (Kubernetes), which isn’t even directly targeted at the same problem space, it’s a more of an elegant set of lower level building blocks.

15 years ago, the opposite happened: working on unopinionated, complicated Java Enterprise Edition and app servers, that got partially steamrolled by Ruby On Rails (opinionated). That didn’t quite last in wide popularity but for a moment it was huge, and led to good reactions in the Java community like Spring Boot.

The moral of the story is that the market wants what it wants when it comes to “platform” software, or software that you use to help build other software: sometimes it’s opinionated software (like Apple and iOS), other times it is relatively unopinionated (like Android). It almost always is a fight between camps. There are many factors at play, not only developer desire: what outcomes does this software lead to, and who does it benefit? What new problems does the software create? These all have an impact on the reaction in the broader market.

Well, oppionated software is better software only as much as its opinions are about irrelevant things.

It's also allowed to have weak, overridable opinions on relevant things, but as soon as it can't do some task that you need, its opinions have gone way too far and become a problem instead of a solution.

How does your web framework manage sessions? Who cares? it's not relevant. But what kinds of servers you can provision is quite an important opinion.

This assumes your opinion is “more right” than the software. And that’s often not the case, depending on your deisred outcomes.

For example, companies that want strict ITIL processes and change control boards may not like software that makes some of those processes and ceremonies less relevant by de-risking large classes of change and opening up pre-approvals to a wider category of changes. This arguably saves a ton of time and money through reduced delays, and lowers risk, but it also lessens the power of the ITIL/change management team. So they resist this software. Who is right? It depends.

This is the trouble of opinionated software that tries to change the way people work (enforcing a new discipline): you can get a force multiplier of benefit, but you have to think the way the software wants you to. Some really can’t handle that. And sometimes the software causes more problems than it solves. But will you be able to get their on your own?

I liken it to diet and fitness programs. They can work, but it’s mostly about the discipline.

Why do you think that is? In regards to Cloud Foundry being steamrolled by Kubernetes.

There's not a day that goes by where I'm using the "current stack", i.e. K8S, Terraform, etc., and not wish I was using Heroku or something Heroku-like instead.

Kubernetes isn’t focused on solving specific end-user problems, it focuses on a community and a set of lower level computer science problems. The community and openness to extend itself to nearly every use case in distributed or networked computing is its strength. The CNCF’s ecosystem map shows this: there is a strong supply of options. This then drives a deep FOMO in tech consumers.

In the community, from my POV anyway, the fact that Kube lacks the end-user experience of Heroku is irrelevant: what matters is how problems are solved: in the Kubernetes Way, or not at all. Some day developers may get their “cf push” or Heroku “git push”, built in Kubernetes, but it must be done “the right way” (no one knows what that is until they see it) to be accepted by the community and thus standardized. There are attempts at this today such as CNCF’s pack/buildpacks, Knative, or Openshift’s S2I… but none of that really has critical mass. The Heroku experience may never happen, but there’s a lot of money being spent to give it a shot.

Kubernetes is more than software, it is a movement. It is trying to drive a standard architecture of how to build and run distributed software with a set of (mostly) elegant design patterns and principals. The YAML overload is a temporary side effect of limited scope: the endgame is that every piece of server software is manageable as a CRD with an operator, and the greater Kubernetes API ecosystem subsumes all categories of cloud and server software.

It reminds me of past major tech waves like Java or Windows 95 or the Web itself: it sucks a lot of oxygen out of the conversation for a decade or so, and solves some problems while creating new ones.

Cloud Foundry Enterprise is still quite expensive, and based on my CF experience, we took a few years of development upon the open source tools before we really had our development environment dialed in.

“Expensive” has to do with size of market - SuSE (and Stackato before it) were pretty inexpensive options but were subsidized by the expensive distros like IBM Bluemix or PCF. At the same time, it’s not like Pivotal was swimming in piles of cash, it was just getting to profitability when VMware absorbed it.

Getting development dialed into Kubernetes usually also often takes several years, and often isn’t quite as productive. More choice, more potential for problems.

Reply on news.ycombinator.com