Live data from Hacker News

We're Leaving Kubernetes

gitpod.io

261–270 of 348 posts

Re: We're Leaving Kubernetes

#261

Earlier quoted context omitted.

People just straight-up don’t want to learn. There are always exceptions, of course, but IME the majority of people in tech are incurious. They want to do their job, and get paid. Reading man pages is sadly not in that list.

> People just straight-up don’t want to learn. (...) but IME the majority of people in tech are incurious. They want to do their job, and get paid. Reading man pages is sadly not in that list. I don't think you know what you're talking about. Just because you know people who do not want to waste their time on a set of unproductive chores you arbitrarily singled out, that does not mean they are against learning. Your…

> Do you actually believe that you build up enough knowledge on [distributed services] to become a professional in the field if you "straight-up don't want to learn"?

Given the modern hiring practice of "can you pass Leetcode," and "can you memorize and regurgitate how to architect a link shortener," yes, yes I do. There is a vast difference between learning to pass a test, and learning because you're sincerely interested in the topic.

> Everyone wants to get paid. Do you know anyone who works non-profit?

Of course we all want to get paid. The intent of the sentence, as I think you know, was that many lack intrinsic motivation, of learning for the sake of learning.

> What you're failing to understand is the "do their job" part. Software developers are trained to solve the problems they face, and not waste time with the problems they do not have.

I think what you're failing to understand is that there is a difference between a factory worker and a craftsman. There is absolutely nothing wrong with factory work, to be clear here – I in no way intend to disparage honest work – I just personally find it a difficult personality to work alongside.

> Time is precious, and they invest it where it has the largest return on investment.

To me, this reads as "be selfish." The fastest way to get an answer is to ask someone who knows. This is not, however, the best way to retain knowledge, nor is it considerate of others' time. That's not to say you shouldn't ask for help, but it's a much different ask when you come to someone saying, "this is what I'm trying to do, this is what I've done, and this has been my result – can you help?"

I can't tell you the number of times someone has DM'd me asking for help on something I've never touched, but by reading docs, have solved. I always try to reinforce that by linking to the docs in the answer, but it hasn't proven to be a successful method of deterring future LMGTFY.

> Man pages are notoriously a colossal waste of time.

Citation needed.

> In general they are poorly thought out

Do you have some specific examples?

> They are incomplete

See above; also, if you've found this to be true, have you considered giving back by updating them?

> They were written with complete disregard for user experience

They were and are written for people who wish to understand their tools, not for people who want a 5 minute Medium post that contains the code necessary to complete a task.

> And more often than not they are way out of date.

I can't think of a time where the man pages _included with a tool_ were out of date. If your system is itself out of date, I can see where this could be true. Again, do you have some specific examples?

> Why do you think sites like Stack overflow is so popular? Because all those "incurious" people in tech feels the need to ask questions and dig through answers on how to solve problems?

SO is a great site, with a dizzying variety of quality in its questions and answers. Take one of (the?) most upvoted answers ever, on branch prediction [0]. The question itself isn't easily answerable via reading docs, and as the answer shows, is surprisingly deep. Next, a highly-upvoted question about how to reset local git commits [1]. This is a question that _is_ easily answerable by reading docs [2]. Or a question on what `__main__` is [3] in Python. A fair question (it is somewhat odd from the outside, especially if you have no experience in Python, have no idea what dunder methods are, etc.), but again, one that's easily answerable by reading docs [4].

> I think you're just picking a very personal definition of competence which conveniently boils down to "do the things I do, and do not do the things I don't".

Of course I think that the way I do things is mostly correct; otherwise why would I be doing them?

> Except the bulk of the people in the field is smart, and some have already solved problems that you aren't aware exist, such as wasting precious time deciphering unreadable documents that are systematically out of date.

Strawman aside, I never said people in tech aren't smart, I said they're largely incurious. Words matter.

[0]: https://stackoverflow.com/a/11227902/4221094

[1]: https://stackoverflow.com/questions/927358/how-do-i-undo-the...

[2]: https://git-scm.com/docs/git-reset#Documentation/git-reset.t...

[3]: https://stackoverflow.com/questions/419163/what-does-if-name...

[4]: https://docs.python.org/3/library/__main__.html

Re: We're Leaving Kubernetes

#262
post #219

Earlier quoted context omitted.

> People just straight-up don’t want to learn. (...) but IME the majority of people in tech are incurious. They want to do their job, and get paid. Reading man pages is sadly not in that list. I don't think you know what you're talking about. Just because you know people who do not want to waste their time on a set of unproductive chores you arbitrarily singled out, that does not mean they are against learning. Your…

> Man pages are notoriously a colossal waste of time. In general they are poorly thought out, they are incomplete, they were written with complete disregard for user experience, and more often than not they are way out of date. Uh, what? What man pages are you reading? I read manpages all the time, and I've never run into an issue where one contained info that was untrue because outdated. The only manpages I've ever…

> And indeed, a trip to StackOverflow never ends at StackOverflow for a person with much curiosity.

My favorite variety of SO question is "how do I do X in $LANGUAGE," because inevitably, people pile in with various answers, and then someone starts benchmarking all of them and providing graphs. Occasionally someone even breaks down the assembly instructions for each solution and explains why one is superior to the other. All in all, a fanatical obsession over something small and relatively unimportant, because they like to learn, and they like to share what they've learned.

Re: We're Leaving Kubernetes

#263
post #183

Earlier quoted context omitted.

I think this, or something of equal complexity, is probably the right choice. I have spent a lot of time helping people with their dev environments, and the same problems keep coming up; "no, you need this version of kubectl", "no, you need this version of jq", "no, the Makefile expects THIS version of The Silver Searcher". A mass of shell scripts and random utilities was a consistent drag on the entire team and ever…

> I think a lot of things are dynamically linked and they include their own /usr/lib tree with the entire transitive dependency chain for that particular app, even if other things you have installed have some overlap with that dependency chain. I prefer the approach of statically linking everything and only including what you need. Wherever there's such overlap, those dependencies are already shared. Static linking i…

Just to answer your edit, nope, I wasn't mixing distros or anything. It would either be all Nix or all Debian.

Re: We're Leaving Kubernetes

#264
post #219

Earlier quoted context omitted.

> Man pages are notoriously a colossal waste of time. In general they are poorly thought out, they are incomplete, they were written with complete disregard for user experience, and more often than not they are way out of date. Uh, what? What man pages are you reading? I read manpages all the time, and I've never run into an issue where one contained info that was untrue because outdated. The only manpages I've ever…

> Uh, what? What man pages are you reading? Every single man page out there leads to a user experience that is at best subpar. > One of the reasons Stack Overflow is so popular is that people who can't/won't read docs can use it to have answers spoonfed to them (...) Pause and look at what you're saying. Your only criticism of SO is how it improves the task of providing meaningful information to users. The way you op…

> Your only criticism of SO is how it improves the task of providing meaningful information to users... the value you place on gratuitous ladder-pulling

How is wanting others to learn ladder-pulling? Also, how do you assume people will have this kind of information handed to them when the people who are interested in deeply learning stop doing so, die off, etc.? If you say AI, first of all, best of luck with the hallucinations, but secondly, who is going to work on and train the AI?

> No. Writing is a skill. Producing content that the target audience is able to consume and brings value is a skill. The moment you, as an end-user, feel the need to hunker down and decipher arcane texts is the moment you should realize the documentation is bad.

I think I see the root disagreement here. You continue to mention "value," as though reading is itself not valuable. Sitting down to read a work of fiction arguably brings no value to anyone (except perhaps the author and publisher), yet millions do it anyway. Similarly, if I find a way to do something, I usually want to know if there are also other ways, and if so, if they're better. There's not much "value" there most of the time, but it brings me happiness, and enhances my knowledge of the subject.

Re: We're Leaving Kubernetes

#265

Earlier quoted context omitted.

> I'd investigate getting a build out to Node.js (looks like you already have this) and then just doing a simple SCP of the build to a VPS. From there, just use a systemd script to handle startup/restart on errors. For logging, something like the Winston package does the trick. If you want some guidance, shoot me an email (in profile). You can run most stuff for peanuts. I appreciate the offer! But it is not as robus…

to be really honest , why don't you use cloudflare for blog post hosting / their storage mechanism if you really want comments hosting. Why are you actually using google cloud for blog post hosting. Also you said a million $ kubernetes wait a second ,have you converted those million $ to 4$ per month what tom foolery is this

I am demonstrating my point using simple personal projects that I can easily explain.

But I am also the Founder/CTO of Threekit.com.

I hope that makes sense now.

Re: We're Leaving Kubernetes

#266

Earlier quoted context omitted.

> You know that Cloud Run is a Kubernetes PaaS, right? Yup. Isn't it Knative Serving or a home grown Google alternative to it? https://knative.dev/docs/serving/ The key is I am not managing Kubernetes and I am not paying for it - it is a fool's errand, and incredibly rarely needed. Who cares what is underneath the simple Cloud Run developer UX? What matters for me is cost, simplicity, speed and understandability. You…

I haven't looked at Cloud Run pricing but running Kubernetes in the cloud is pretty cheap these days and my experience with solutions like Cloud Run in the past is that they end up becoming expensive. Kubernetes can be as complex or as expensive as you'd like but it's also fairly possible to run a pretty bulletproof simple Kube cluster.

Maybe we misconfigured Kubernetes?

Here are my concerns:

With Kubernetes is that you need to pay for a few node just to keep it up, and then you need to pay for your nodes, no matter how much you use them.

Remember that Cloud Run charges based usage, so if a service sits unused for a while, which often happens in a heterogeneous microservices environment, you don't pay for it.

Also autoscaling is slow (Cloud Run autoscales really quickly, about as fast as your docker can be loaded and started, which for me is 1-3 seconds, where as I found Kubernetes auto-scales on the order of minutes) unless you over-provision, which is costly. This lets one scale to zero even without much of a hit.

I also ran into massive issues trying to get GPUs to work in Kubernetes - it was a driver nightmare that has wasted weeks of time collectively over the years. Whereas they are auto-provisioned properly on Cloud Run if you request them.

Lastly job systems on Kubernetes are a nightmare of configuration. The built-in scheduler cannot handle a lot of jobs but Argo also has its own issues if you actually try to use it. We've wasted weeks of effort on this. Cloud Run Tasks just skips this and is ultra fast too and handles scaling up to do a lot of jobs in such a simple fashion.

Honestly, managing Kubernetes is just overall a pain that has little benefit.

It is really hard to figure out what the benefits of Kubernetes is from my point of view. It has been a massive source of pain and costs and lost developer time.

Re: We're Leaving Kubernetes

#267
post #199

Earlier quoted context omitted.

Yeah, that's fair. The blog was getting quite long, so we need to do some deeper dives in follow-ups. Gitpod Flex is runner-based. The runner interface is intentionally generic so that we can support different clouds, on-prem or just Linux in future. The first implemented runner is built around AWS primitives like EC2, EBS and ECS. But because of the more generic interface Gitpod now supports local / desktop environm…

What’s a “runner”?

It's a compute resource you configure to offload compute jobs from a specific platform. You can have for instance Jenkins runners that will actually execute the pipelines and leave the main node free to do UI and admin tasks.

You also have github and gitlab VCS's that have their own hosted runners for pipelines, but also enable you to configure a runner to use private resources to offload jobs to.

Re: We're Leaving Kubernetes

#268

Earlier quoted context omitted.

Yeah, that's fair. The blog was getting quite long, so we need to do some deeper dives in follow-ups. Gitpod Flex is runner-based. The runner interface is intentionally generic so that we can support different clouds, on-prem or just Linux in future. The first implemented runner is built around AWS primitives like EC2, EBS and ECS. But because of the more generic interface Gitpod now supports local / desktop environm…

Still No idea what you did technically... Maybe a second post? Did you use consul?

that is exactly what a "follow-up" is

Re: We're Leaving Kubernetes

#269
post #249

Earlier quoted context omitted.

You need an option to enable only the services they need to develop locally and automatically configure them to talk to the other services hosted elsewhere.

What ever happened to make? It seems like so much of what developers do now just duplicates what could be done with a single makefile that pokes around, figures out what you need, and makes a script to set it up.

"Use make" advices start so sound a lot like fetish and disregard the actual challenges.

Make is just a framework for you to do your builds. Sure you can cram anything into it, but that is exactly the kind of area that other tools like Ansible or even Terraform shine.

Make isn't a silver bullet.

EDIT: Just to make sure, I'm using fetish as something you spend an unreasonable amount of time with it.

Re: We're Leaving Kubernetes

#270

Earlier quoted context omitted.

> installing ~50ish microservices on their machine Ouch. Where they using macOS at the time with laptops having not-enough-ram? I've seen that go poorly on macOS with java based microservices. Largely due to java VMs wanting ram pre-assigned for each, which really chews though ram that mostly sits around unused. This was a few years ago though, at the tail end of Intel based mac's where 32GB ram in a mac laptop wasn'…

> Largely due to java VMs wanting ram pre-assigned for each Do you mean the JVM min heap size was rather later? Otherwise, there is no need for a very large min heap size on a modern JVM (11+).

Pretty sure it was a mix of java 8 (yeah, very outdated even then) and more modern stuff.
Post reply on HN