Hacker News new | ask | show | jobs
by jauntywundrkind 818 days ago
Generally I appreciate this post, as yeah the bandwagon effect is real.

I'd characterize mapreduce as a very very specific narrow architectural pattern. Trying to apply it contorts the code you write. I don't see anything remotely like that that's true about Kubernetes or containers (microservices much more so in creating constraints).

We had to reset the Days Since Kubernetes Winge counter again yesterday: https://news.ycombinator.com/item?id=39868586 . And a couple of people spoke to how you might not need containers, but I still haven't heard anyone say what not having containers could win you. What types of code can you only write without containers? We can convince ourselves that Kubernetes is hard, but also lots of people also say it's easy/not bad, so there's some difficulty-factor that's unknown/variable. But I strongly struggle to see a parallel between a strong code architecture choice like MapReduce and a generic platform like Kubernetes or containers.

The platform seems pleasantly neutral in shaping what you do with it, in my view; if that wasn't true it would never have been a success.

2 comments

> I still haven't heard anyone say what not having containers could win you. What types of code can you only write without containers?

Code with one less layer of abstraction. If that layer is buying you something you need, it's great. But abstraction isn't a positive in & of itself, it's why we get upset about GenericAbstractFactoryBeanSingleton(s).

Containers on kubernetes are major part in allowing me to put less abstractions into code directly, if only because I can reduce bits that would be built-in or in messy companion scripts into more or less standardised patterns in k8s
Containers are not code abstraction, they are environment encapsulation.
What would you change about your coding because of deploying in a container? What do you tell your junior & senior engineers to do differently?

I call bull frelling shit. It's not an abstraction. It's a deployment pattern. It doesn't affect how or what we code.

Endless shitty pointless bullshit grousing, over nothing. It doesn't actually matter. It's just hip, you get to feel good, by pretending you are dunking on sheeples. Frivolous counter-cultural motions that people use to make themselves feel advanced & intelligent. But actually, being free of this pattern doesn't really buy you anything new or different. The same code & the same approaches are viable with our without. It just feels good to be shitty to the mainstream.

If there were abstractions maybe there would be some justification for the slippery slope "oh no!" panic. And K8s is definitely some kind of abstraction. But the sloppy slippery slope "oh no abstractions" shit still pulls no weight for me, fails to acknowledge that sometimes abstraction can & is useful, allows good things.

> What do you tell your junior & senior engineers to do differently?

I tell junior & senior engineers to be careful about what assumptions they make of their environments, and to consider everything they depend on a potential liability.

> frelling

damn I had to dust off some cobwebs for that one

> What types of code can you only write without containers

Lots. 3D, DAW, GUI IDEs, Facetime/MSTeams/Zoom, etc.