Hacker News Reader

Comment by falcolas | Hacker News Reader

My opinion is simply: You should understand the environment your code runs in. Be it bare metal, Kubernetes, or anything in-between. How that environment works determines how your code works - or doesn’t work.

Despite our best efforts, we have yet to abstract away the runtime environment. Despite Java’s best efforts.

View on HN

I don't really agree on this. If your data scientists are extracting important information about your data in Python or R. The actual hard work of this is them figuring out the algorithms to run, not what it is being run on. They develop this code to sift through data in a data warehouse, a database, or flat files and then come up with answers. What servers, or cloud infra, or kubernetes fleet it then runs on is of 0 concern to the actual code they just laid down.

Do you believe front-end CSS / HTML designers should understand the entire stack down to the machine code and hardware running the VMs? I don't think I can agree with this, our stacks are too tall these days.

That runs in a browser, so they should understand the browser if you follow their logic.

I think this actually gets at an important distinction. Are Data Scientists more like designers or developers? UX designers shouldn't need to know anything about k8s (or any other infrastructure) but developers should. Ultimately if you are not only responsible for building something but also running it in production and maintaining availability then you need to understand the infrastructure it runs on to some degree.

i don't think it is necessary or sufficient for all individuals to have a deep understanding of the runtime environment. i agree that if the team needs to ship production code, it would be a good idea if at least one person in the team has a good understanding of how the code runs.

but there are other failure modes -- if everyone on the team is great at writing efficient production code, but no one understands the business context or the problem domain or understands if the problem they're attempting to solve is even vaguely feasible from some kind of theoretical perspective (maybe someone with a decent statistics background could demonstrate the entire premise of the project is flawed, and needs to be rethought, using a blackboard and no computers at all), maybe they'll spend months or years building and deploying a lot of fast, beautiful, completely worthless machinery.

Except that most devs who learn this stuff but do not use it daily (or ever) (and why would they, they are devs), will know just enough to have opinions and too little for them to make sense. You (in general, maybe YOU do) do not understand the env your code runs on: it is layers on layers on layers with millions of LoC in between; you know some abstraction and maybe you know a bit more about this abstraction than others but you still do not understand it really. If you run Java or .NET Core or whatever popular with good support, your day to day programming won't matter for whatever env it runs on; if you write best practice code in those envs, writing different code for whether it runs in k8s or bare metal is... weird in almost every case. Someone in the team should know how to tweak the knobs and if there are things you should not do (use the filesystem for persistence and other trivial things) but the average dev or data scientist really doesn't need to know about it in any significant detail.

But I am curious where you have seen modern runtimes fail and where the code was the issue (not tweaks to the JVM settings); any concrete examples where well written, best practice code worked on the laptop but failed in k8s?

> But I am curious where you have seen modern runtimes fail and where the code was the issue (not tweaks to the JVM settings); any concrete examples where well written, best practice code worked on the laptop but failed in k8s?

Not sure about OP, but the most times I have seen devs have issues with Kubernetes is in the tweaking of the knobs around deployments including security. Startup v/s readiness v/s liveness probes, rolling updates, auto-scaling, pod security policies and such are usually all-new to developers, and have a lot of different options. Most devs just want "give me the one that works, with good defaults", and need a higher level abstraction.

But at most companies I have seen those are handled by specific roles in the company who are in the team as well. Not all devs on the team need this knowledge. Depending on the service, you need resourcing. We have monoliths and microservices running on ecs and eks and we have 1 person who does the knobs turning and 1 person (me) who can take over if need be. I see no need to burden others with this, I dare say it, crap, because it is just not really useful or needed for writing business functionality that our clients want and need and pay for.

OP seemed to imply that coders needed to know this stuff because their code might not work: if that means turning knobs on the outside (runtimes/containers) then sure, but the devs don't need to know, but their comment about the JVM implies something else and I am curious what that is.

Java was doing alright, but then plenty of people decided they didn't want to go along with it.

We develop on Windows, and deploy on multiple kinds of scenarios and OS stacks, I hardly have to care what lies underneath.

Same applies to .NET, although in smaller extent, given its Windows focus until quite recently.

>Despite our best efforts, we have yet to abstract away the runtime environment. Despite Java’s best efforts.

I think containers are a pretty good attempt at abstracting away runtime environments, no? Same docker image works on your local docker setup, docker-compose, vanilla kubernetes, managed kubernetes, fancy PaaS like CloudRun, Fargate, Heroku etc

That's just running the code, you need to connect to something or have something connected to it, handle failures etc - docker doesn't solve these on its own.

Reply on news.ycombinator.com