Infrastructure Software is Dead (opens in new tab)

So, your not the cool, forward looking engineer when you favor using a 5 year old toolchain to build your product. OTOH, your also the engineer that doesn't have to come in on weekends to debug the death march bug that ends up being a result of doing the upgrade.

At least in fashion you can make an excuse that the design is thirty years old and most people don't remember the last time we did this.

With software it's every six or seven. It's hard not to judge my peers for having such short memories.

We were in the midst of one of these upheavals when I first started, and so I learned programming in that environment. It also means I have one more cycle than most people near my age. Now it all looks the same to me, and I understand those people who wanted to be more conservative. In fact I probably owe some people an apology.

And, just like that, another contract is drawn up and another invoice is sent. They don't care about the underlying tech. They only care about results, and what the results cost them. One-time consulting fees nearly always win over the prospect of hiring staff to take on the task, especially given that my incentive as a consultant is to time-gate a project and get it out the door so I can take on another.

Almost all the big vendors and sales teams start with the approach of looking for problems and trying to re-message their products and services to appeal to the problems of their C-level customers, not the engineers (whom never make the vendor relationship decisions). Several years ago everyone was "cloud-washing" their products to tell CIOs "oh yes Mr. CTO, we're ready for your cloud initiative" by slapping on a web frontend to their managed services and boxed software when they didn't have anything before to maintain a relationship. Those are red herring projects though I've found - it's just another way to keep vendors on their toes.

Another problem is that accurate problem statements can be very hard to get to without escalating to higher level managers that it turns out are oftentimes swayed by existing vendor relationships to get something done more effectively. From here, I simply have to ask "are you happy with the results your vendors have promised compared to what you expected?" and everyone complains about cost but you need to get away from that conversation honestly if possible - because IT at a company will never, ever, ever cost too little since it's a cost center.

These are my exact thoughts about how we now have like two dozen explicitly Docker-releated startups. Because Docker. Docker docker docker docker docker.

I was with you until that little gem. Products fill a known need, solving a problem shared by many organizations. They don't claim that they can help everyone with all problems... but they do solve a specific problem, and if you have that problem, products are good things.

You can flip the attitude the other way by saying that consultants who act like everything they do is better than everyone everyone else will lose when working in well-established problem areas because they re-invent wheels. Expensively.

The truth is that good business can be done from either a broad consulting perspective, looking for new ways to help a specific customer... or from a narrow product perspective, solving a specific need for many customers. One is not inherently better or worse than the other. Just different.

Not only should you not focus on product, but when clients bring up product you should of course listen carefully and respectfully, but you need to consider that they are even then expressing ideas about how to solve their problems. Those ideas may be well thought through, but very often they are not, and comes down to trying to explain what they need based on what they know.

If a client says "we need product X", sometimes they really need it, but often what they are trying to communicate is "we need the stuff product X's marketing material says it will solve", and even that may be imprecise

Someone coming in quoting on what they say rather than what they answer when you ask probing questions about their actual problems will often quote for the wrong thing. And more importantly: Quote for something that someone else will be explaining to them why is the wrong thing while quoting for something more appropriate. Doesn't help if you come in with the best price if someone else has made your solution irrelevant.

The other aspect is that people often value the solution to a problem far higher than they value a product.

I have built a tool that I'm starting to roll out a service around now. And the interesting thing is that when I've talked to people about it, it quickly became clear that if I showed them screenshots of my admin interface and explained the software, they started comparing it to $20/month services that in fact deliver far less value in terms of results, but they still found it hard to see it as something more expensive.

When I instead approach it entirely in the abstract, and show people analytics of the outcomes and never tell them I have a pretty web-based interface, and never suggest they'll get a login to anything, people consistently value the service 10x to 20x higher.

Now, this doesn't work for everything - the reason people value it so high in the latter case is that the analytics makes it clear it deliver results that would cost them in that region otherwise. But the moment I start to describe it as a product, people go blind to the outcomes and value it based on other criteria.

tptacek and patio11 have touched on this previously too when talking about how to get your rates up by focusing on value delivered, and avoiding billing in small increments (e.g. bill daily rather than hourly, or even bill by the week or by the project if you can). But beyond applying just to the price, the overall principle also greatly affect whether or not you'll get a deal at any price.

Someone may even suggest the exact same technical solution as you, cheaper, but still lose out if they focus on the product and you're selling problem solutions and visions of where it will get them next.

E.g. I had a client meeting yesterday to walk through a proposal I'd sent, and the entire meeting involved me telling them what problem each part would solve and what that'd enable next. They sat there grinning through most of it, and kept starting to discuss additional work they just thought of that this would enable them to do later, and cost came up just very briefly at the end. Never mind the initial contract - selling them on the idea and the problem solutions now rather than technical details of a specific product likely already did 90% of the job of selling in 3x+ more work down the line.

Same tired old hype cycle trope. Openstack is dying in the same way that 'virtualization is dead'. Containers are in the spotlight now so openstack is dead - a.k.a enterprises are actually adopting it now so it's addressing all sorts of boring requirements that aren't sexy to developers.

Openstack isn't a replacement for configuration management.

The massive design by committee is fantastic, because you can help change and adapt where openstack goes. You don't have that option with insert vendor.

We just disagree completely

Perhaps the author could refrain from speaking for everybody! OpenStack may be a ruinous rubbish barge of a platform, but others are working on software that seeks to _reduce_ operational complexity. Software that does not exist merely to propel yet another band of consultants into a defeatist, over-priced nightmare cathedral of apparently irreducible complexity and unmitigated unreliability.

Outcomes for customers are extremely important, but it does not follow that software quality is immaterial, or unachievable, or that OpenStack is just as good a choice as anything else -- even if it does come with a consulting racket.

The core services are backwards compatible much longer than 6 months from what I've seen. I'm not sure where you got your experience from, but it doesn't sound like Nova, Cinder, Glance, etc.

Look at the Jetbrains products. They make many open source IDEs feel janky, broken, and non-cohesive in comparison. Some problems aren't solved eloquently by being loosely community owned; sometimes you need a paid, focused group.

I.e. id rather pay for what I get out of Adobe than try to use GIMP.

How can you claim that it's the will of all developers to be unemployed?

Ending all wars is the future. The benefits to mankind are too great.

What this article complains about Pike doing can just as well be leveled at the article author (and colleagues) vs Linux.

"beleive nix* (as in e.g. NixOS) could be a silver bullet here"

Come on, now. Try to avoid that trap. You need to look at what the market needs in compatibility/legacy, production worthiness, talent to aid deployment/support, security, and so on. Always consider these plus target markets when evaluating any software platform. NixOS at first glance appears to fall short in quite a few.

Now, what I do like about NixOS is its declarative, transaction-oriented packaging. That's great if implemented well given my Linux distro's screw that stuff up to this day when I install an odd package with one incompatibility in it. Irreparably breaks system or appears to. (rolls eyes) Source-based is debatable but allows site-specific optimizations. I'm barely in the debate but lean against systemd, which Cantrill's post mentions incidentally, as it's too complex to be in critical position it inhabits. Critics pointed out a simple thing in its spot plus less privileged services doing management or whatever. Consistent with best practices from high-integrity & high-security engineering going back decades. So, I see it as a weakness albeit a small one in larger picture.

So, there's my two cents on that link and claim.

First of all, he should define what "infrastructure software" he is refering to.

He mostly talks about OpenStack, AWS ... "services".

But it is obviously not only that. It is low level libraries (C lib), compilers, interpreters, operating systems, graphic engines, virtualization software, etc. This kind of software runs on allmost all deployments out there. It is far from dead.