131–140 of 149 posts
Earlier quoted context omitted.
Most of the time you don't even need a cluster of any kind. We live in a world where you can spin up a server with 3TB of RAM and 128 cores whenever you want, and it will cost you less than a senior developer.
https://aws.amazon.com/ec2/pricing/on-demand/ x1e.16xlarge, 64 CPU, 2TB of RAM, $10k per month.
Earlier quoted context omitted.
> Shouldn't that be more like "Let's say you're learning to be a surgeon."? No. It is an exaggerated example, because I am illustrating a psychological effect. The point is that you are consulting an expert, and you don't want that expert to tell you about all their mistakes, because your mind is now occupied with doubting that expert. It's not rational . > For that situation, the person they're learning from discuss…
>The point is that you are consulting an expert, and you don't want that expert to tell you about all their mistakes, because your mind is now occupied with doubting that expert. It's not rational. Sometimes books are written for entry level people (to the technology or topic) and they're written in an authoritative tone. But I work with people who write books. And I read their books. I don't read them like some kind…
Yes, you feel that way. You feel like you're a rational person who values humility, whose judgement isn't clouded by the effects that I am describing.
Well, maybe you really are that person. It doesn't matter. We cannot assume that the buyers are such noble beings.
Earlier quoted context omitted.
> Let's say you go to get a surgery. Shouldn't that be more like "Let's say you're learning to be a surgeon."? For that situation, the person they're learning from discussing problems they hit and how they solved them does sound like it would be very useful.
> Shouldn't that be more like "Let's say you're learning to be a surgeon."? No. It is an exaggerated example, because I am illustrating a psychological effect. The point is that you are consulting an expert, and you don't want that expert to tell you about all their mistakes, because your mind is now occupied with doubting that expert. It's not rational . > For that situation, the person they're learning from discuss…
In the situation where I'm consulting an expert - hired to fix a problem or find a solution - then I'd tend to agree with you.
But when I'm reading text from a person in my field in a subject area of interest (eg learning from a book), then I definitely want to hear of things that went wrong, and how they fixed them.
I think they're two different situations, and the one you described above isn't the correct one for a person who's bought a book to learn from.
It could just be us valuing different things in our learning though. :)
Earlier quoted context omitted.
https://aws.amazon.com/ec2/pricing/on-demand/ x1e.16xlarge, 64 CPU, 2TB of RAM, $10k per month.
So if you pay a senior developer less than 120k then the parent is right.
Earlier quoted context omitted.
>They said the reader wants to see an expert talking, as if experts never make mistakes or need to shift from one tact to another. Your editor was very fucking wrong.
> Your editor was very fucking wrong. The editor is completely right in what they were saying. You just want them to be wrong, because you'd prefer to live in the fantasy world where they are wrong. Let's say you go to get a surgery. You don't want the doctor to tell you about all the times they fucked up and what the awful consequences were. It doesn't matter that they're probably a better surgeon now, having learne…
I actually disagree with the first recommendation as written - specifically, not to set a CPU resource request to a small amount. It's not always as harmful as it might sound to the novice. It's important to understand that CPU resource requests are used for scheduling and not for limiting. As the author suggests, this can be an issue when there is CPU contention, but on the other hand, it might not be. That's becaus…
I agree! I assumed not to trust anyone with all the greedy pods they can schedule. The example you are describing is probably not super common but I will try to rephrase my blogpost so that it reflects this comment:)
Earlier quoted context omitted.
> Your editor was very fucking wrong. The editor is completely right in what they were saying. You just want them to be wrong, because you'd prefer to live in the fantasy world where they are wrong. Let's say you go to get a surgery. You don't want the doctor to tell you about all the times they fucked up and what the awful consequences were. It doesn't matter that they're probably a better surgeon now, having learne…
The book is not presenting to the patient, the book is presenting to another surgeon. If I was a surgeon, I would find value in learning about previous mistakes, and thankfully in programming as a general rule the cost of error is lower (but still a valuable learning).
I like this analogy and I agree that the previous person saying the publisher was right, completely missed the point.
Earlier quoted context omitted.
This is not how defaults work. When you are talking about the realm of the possible , you provide settings that allow you to reach the scenarios that you feel are reasonable, desirable, or lucrative (or commonly enough, some happy combination of the three). Defaults are the realm of the probable. And nobody is requisitioning a 192 core machine without a good bit of due diligence, which would include deciding how to s…
You're suggesting that preventing multiple replicas of the same job to schedule on the same machine as a good default. There's no evidence to support your conclusion, and my experience it quite the opposite. It is much better if people running batch jobs just schedule 100000 tiny replicas, and let the scheduler sort it out. This provides the cluster scheduler with plenty of liquidity. Multiple small processes are mor…
Do you think that batch processing is the default activity in Kubernetes, or something that people find after they are familiar with the system?
In my opinion, the most common mistake is not in the article : using kubernetes when you don't need to. Kubernetes has a lot of pros or the papers but in practice it's not worth it for most small and medium companies.
Most of the time you don't even need a cluster of any kind. We live in a world where you can spin up a server with 3TB of RAM and 128 cores whenever you want, and it will cost you less than a senior developer.
Earlier quoted context omitted.
You're suggesting that preventing multiple replicas of the same job to schedule on the same machine as a good default. There's no evidence to support your conclusion, and my experience it quite the opposite. It is much better if people running batch jobs just schedule 100000 tiny replicas, and let the scheduler sort it out. This provides the cluster scheduler with plenty of liquidity. Multiple small processes are mor…
Still the same question. Do you think that batch processing is the default activity in Kubernetes, or something that people find after they are familiar with the system?