No more magic, please! (2023) | Hacker News Reader

No more magic, please! (2023)

nickgeorge.net

35 pointsindigodaddy21 comments

In my experience we as an industry just can't stop ourselves from moving deck chairs on the Titanic.

We swing from monoliths to microservices and back. From server rendering to client apps and now some bastardization of both via RPC calls.

I've seen this happen most often due to moving too quickly upfront and not putting in the time to really plan for later. We ship fast above all else but end up with a pile of tech debt and a team that's built skills around those very same tools and patterns that are causing problems at scale. Shifting later is extremely tricky (and interesting if you know what you're doing), but you often have a team that is ill suited for the next architecture and paying customers potentially with SLAs that make migrations difficult and risky.

It's an industry with a very specific funding model for a large number of companies... a desire to tap into VC funding. In turn VC's want only one thing: to hit the lottery. The result is a panicky, endless cycle of overpromising and underdelivering.

Everyone wants to be a new Google/Apple level success story, few want to admit that this is an increasingly mature and sometimes moribund industry.

On the startup side that's for sure, though in web development more broadly we're all just trying to ship the next site or maintain the last ones.

VC funding definitely pushes a certain type of incentive on startups building dev tooling, hosting services, and frameworks. Those companies do one heck of a job convincing the devs shipping sites that we need to use the new hotness because everything else is old and busted.

I think when you see products that hide complexity and you're forced to "learn" them and this frustrates you, there are three responses

- Accept this is how we make our money and that being paid to be the $INFRA person (replace with your infra tool or cloud provider of choice) is not necessarily a bad thing unless you can't translate that into whatever the next $INFRA is

- Go build the next $INFRA and sell it to all the people like you that didn't like the old $INFRA (or lose everything, obviously this is risky)

- Complain

I don't think the third option is really a good strategy in life. A lot of the frustrating things in industry exist for good reasons (that more often than not, turned out to be bad/inconvenient a lot later) and life is too short to get upset at things when you're being paid to understand them.

But obviously a config file is just a program and you need to know how to debug it when something goes wrong, and it's not helpful when "what does this config do" is hard to see because the thing it configures is intentionally obfuscated.

> I don't think the third option is really a good strategy in life. A lot of the frustrating things in industry exist for good reasons (that more often than not, turned out to be bad/inconvenient a lot later) and life is too short to get upset at things when you're being paid to understand them.

On the other hand, a lot of frustrating things that could be fixed with a modicum of effort are neglected on the basis that "nobody's complained". Sure, pick your battles, but don't be so compliant that you leave easy wins on the table.

Let's rephrase the options from the author's point of view:

1. accept the problem

2. become part of the problem

3. complain - but please don't

I can't help thinking there must at least be some fourth way . . .

Hoping that fundamental skills aren’t lost in the wayside eg 10 years from now… although I guess it will just be a somewhat smaller subset of peeps that have them, as someone still has to manage the infra all the way down to bare metal I’d think..

The option you are missing is to ignore the last guy who gambled on option 2 and won, and just keep using the previous $INFRA .

I love running a VPS and just controlling everything.

Always feel helpless when app engines cloud, managed db, managed kubernetes upgrades or something else fails. Slow builds, builds getting stuck, upgrade issues, overcomplicated new concepts, cloud outages, slow support.

One exception to them all is Vercel, it's just amazing. Haven't had any issues, fast deploys, works instantly. What a joy.

What I find is missing from this discussion: the major advantage of config-based deployment is that it's relatively stateless and easily reproducible. Their pain point tends to be when state leaks in.

A lot of traditional approaches are gratuitously stateful, and there's a lot of room for tooling improvement there even if you want to avoid YAML.

Kubernetes is declarative. There are now operators published by AWS and azure that you you define and provision managed cloud services like RDS and S3 a CRDs from a cluster.

cdk is so good for aws... i haven't used terriform but I'd bet it's just as good.

Stateless infrastructure is amazing. Checking my infra into code is awesome.

Could you elaborate on the state here?

For example, docker is notable for breaking people's networking and leaving it broken even if you later uninstall docker. Sometimes it's a mere mess instead of breakage. This isn't a docker-specific issue, docker is just what a lot of people use.

Or literally anything to do with certificates/keys. GPG in particular is actively hostile toward stateless operation, far more than is necessary in an admittedly tricky field.

> The further I get into studying deployments/DevOps methods the more surprised I am that the balance has shifted rather strongly towards configuring tools from third party infrastructure vendors and away from what most would call software engineering.

This is kind of an arbitrary line to draw. You can learn the ins and outs of Nginx, but that's also "configuring a tool" rather than "software engineering".

Of course, the advantage of something like Nginx is that it works on any Linux box, so you're not locked into your third-party infrastructure vendor. But most front end frameworks are compatible with many "one step app deployment" vendors, as long as you're careful to avoid any proprietary features.

While I do not necessarily disagree with the author, I really dislike the term magic. It's not magic, it's added abstraction layers. Usually you can peel those back and look underneath. We've been adding abstraction layers since the beginning of computing. It's not magic though, it's neither sorcery nor trickery. You may decide it's not something you want or need, but don't then dress it up in this way to appeal to a certain audience who dislike all "magic", it is unhelpful to the argument.

> Why is there such a strong preference for “one step app deployment”, no infrastructure knowledge required?

> The obvious answer is because it is easier.

No. The answer is that it’s more robust in the face of operator error, it’s repeatable and it’s auditable.

A lot of these tools are created in an atmosphere of corporate redundancy. Sure your test framework, regional deplyments, A/B testing, CI, code coverage, storage infra, network infra, security settings, and app configurations are held in a 20000-line yaml-within-yaml-within-yaml disaster.

On the other hand, at least they aren’t hand-coded by Steve (who left the company last week)

A higher bus factor is nice, but there's almost certainly more thought and wisdom in a popular CI/CD setup than Steve's scripts.

Came here with that exact quote in my clipboard. I have a medical background prior to software, and one of the key learnings there is that wherever there is scope for a human to make a mistake, that mistake will (eventually) be made. It's therefore crucial that wherever possible the capability of making that mistake is eliminated. I see automated deployment as falling into a similar category of utility.

enjoyed the read and agree on how intellectually boring it can be to do the same magic config copy paste every time. i love still going in and doing it my self, its just so much more enjoyable. albeit i can only afford to do this on my own projects.

Reply on news.ycombinator.com