Hacker News Reader

Comment by sebazzz | Hacker News Reader

If there is any guideline I follow, it is that any complexity must be justified.

When for a client we have a choice in hosting environment, we still choose Windows because a shared IIS hosting environment or Az App Service in both cases allow deployment though MSDeploy and don't require docker because on Windows you can run many apps side-by-side without issue. This saves a whole lot of hassle.

For frontend, any library or build system needs to be justified. No webpack because it causes more problems than it solves. A simple gulp build suffices.

In terms of software architecture, a simple webapp-database architecture works fine for 80% of the use cases. No need to introduce extra parts with extra complexity. Boring architectures work best. Any complexity can and will be a source of headaches.

I could go on and on.

View on HN

> ... and don't require docker because on Windows you can run many apps side-by-side without issue

As opposed to Linux which would have issues when running apps side-by-side?

Linux took over the entire world and now run on billions of devices and there has to be a reason for that.

One example of devices running several applications side-by-side that we all use would be smartphones: Android or iOS. No Windows to be seen.

If a part of the world moved to containerization, it's not because OSes had issues running applications side-by-side.

> As opposed to Linux which would have issues when running apps side-by-side?

Side-by-side versioned libraries often turn out the problem, which is one of the driving forces behind containerization technology: One version wants version X of that library, one app version Y, and then also every distro has different flavours of the same library.

> As opposed to Linux which would have issues when running apps side-by-side?

The meteoric rise of containers is a massive testament to just how bad Linux is at running apps side-by-side. Or for a more principled approach, take a look at Nix. Either way, the problem is solved by adding quite a lot of complexity.

Android and iOS also solve this with a large amount of sandboxing, which means more complexity. Developing and maintaining mobile apps is anything but simple.

To be clear, I'm not saying these things are bad. They are necessary. But they are not simple.

Linux is emphatically no worse than Windows at running things side by side. Better in many places. But socially it has a custom of using a package manager for dependencies, where Windows instead requires you to vendor everything, because historically it's just had no package manager story.

People sometimes criticise ecosystems like npm and Cargo because you end up with many dependencies. But the alternative was C/C++, where you instead ended up vendoring everything, which has its own problems, and reimplemented things poorly because getting dependencies in is so hard, and that's fairly terrible.

I would suggest that actually containerisation was more an opportunity that Linux could avail itself of, since it was a fairly small shift, things were already normally pretty scripted, whereas it has never taken off much on Windows because everything's already too manual, it takes too much effort to shift.

The reality is probably a bit of this, a bit of that, but Linux is not at all bad at running things side-by-side, so long as you either commit to using the OS package manager tools, or deliberately avoid it entirely, like you effectively have to on Windows.

Nobody is arguing that Linux is bad at running multiple processes at the same time. The whole point is the differences in how people customarily package software for each platform.

It turns out that package distributions on Linux are nice if you only consume from the package distribution, but are a huge pain in the ass if you want to deploy software packaged independently (which applies to a large portion of commercial software deployments).

For proof of how fucking hard it is to effectively vendor your software dependencies in Linux see: Docker, Nix, AppImage, Flatpack, Snap.

It's not hard because of any technical limitation of Linux.

Packaging is pretty easy if you want to stick to a single ecosystem. If you're a Red Hat shop and you're only interested in deploying your stuff on RHEL, then rpms are easy to build. Use the system deps where appropriate, ship your own when not.

The packaging story falls apart when you want to ship software to customers running god-knows-what.

I agree completely. The simplest solution is often the best solution. And also, the best understood and best supported solution. Teams love new shiny objects and toys to play with, but if business leaders truly understood the tradeoffs, they’d shy away from the latest and “greatest” most of the time.

A better resume is built with SQL Server EE than it is with linked-across-the-LAN Access tables. It's also a better solution, but takes far longer to implement. [True story from nearly three decades ago.]

A selfless engineer doesn't care if Perl gets the job done quickly but doesn't look as good to prospective employers. A selfish person weighs their design decisions with more personal factors, no matter how they affect the entire project.

Still, making functional art that is also beautiful is its own hindrance, so we, too, are not without fault. Unless that artistic process is necessary, but who's to say? Aye, there we walk the razor's edge, my friend.

Reply on news.ycombinator.com