There's a big difference between learning from someone and having someone teach you something. The latter expedites your progress and clarifies learning path, whereas the former can even waste your time with political fights pulling you into dead-ends.

That sums up anyone's college experience.

The hard part is telling apart what doesn't matter from what does. More often than not, what dictates which is which is the project you find yourself working on.

This is only syntactic sugar to allow using object initializers to initialize specific member varabiles of a class instance instead of simply using a constructor and/or setting member variables in follow-up statements. It's hardly the feature OP was describing.

Virtually all software ever developed managed just fine to with that alone.

> I don't know of any programming environment that facilitates properly specifying calculating something even that basic in the init phase of running the system, (...)

I don't know what I'm missing, but it sounds like you're describing the constructor of a static object whose class only provides const/getter methods.

> or even a db table's row(s).

I don't think you're describing programming language constructs. This sounds like a framework feature that can be implemented with basic inversion of control.

I don't think you're framing the issue from an educated standpoint. You're confusing high-availability with not designing a brittle service by paying attention to very basic things that are trivial to do. For example, supporting very basic blue-green deployments that come for free in virtually any conceivable way to deploy services. You only need a reverse proxy and just enough competence to design and develop services that can run in parallel. This is hardly an issue, and in this day and age not being able to pull this off is a hallmark of incompetence.

Interesting.

A quick search shows that some people already toyed with the idea of rolling out something similar.

https://github.com/ivanmorenoj/k8s-wireguard

It sounds like a good tradeoff. The monthly cost of a small vCPU is equivalent to a few TB of bandwidth.

I'm sorry, you said absolutely nothing. You just sounded like you were confused and for a moment thought you were posting on 4chan.

I have a side-question pertaining to cost-cutting with Kubernetes. I've been musing over the idea of setting up Kubernetes clusters similar to these ones but mixing on-premises nodes with nodes from the cloud provider. The setup would be something like:

- vCPUs for bursty workloads,

- bare metal nodes for the performance-oriented workloads required as base-loads,

- on-premises nodes for spiky performance-oriented workloads, and dirt-cheap on-demand scaling.

What I believe will be the primary unknown is egress costs.

Has anyone ever toyed around with the idea?

The database is denormalized. The developers are demoralized.

I don't think your poorly thought-through personal attack has any relevance to the topic. I clicked on the article because there was a submission in HN with the title "Myths and Urban Legends About Dual-Socket Servers". What leads you to believe SEO holds any relevance

This is the same sort of myopic, naive, clueless take that led people armed with this blend of specious reasoning to dive head-first onto microservices architectures without looking at what they were doing and thinking about the problems they are solving.

The main problems that microservices solve are a) organizational, b) resilience, c) scalability.

If you work on single-person "teams" maintaining something that is barely used and does not even have SLAs and can be shut down for hours then there's nothing preventing you from keeping all your eggs into a single basket.

If you work on a professional environment where distinct features are owned by separate teams then you are way better off running separate services, and perhaps peel out shared responsibilities to a separate support service. This is a fact.

But let's take it a step further. You want to provide a service but some of the features are already provided by a separate service either provided by a third-party or whose project you can simply download and run as part of your deployment. Does this count as a microservices architecture to you or is it a monolith?

Consider also that your client teams have a very specific set of requirements and they rolled out services to provide them. Is this a microservices architecture or a monolith?

Consider also that you start with a monolith and soon notice some endpoints trigger workflows that are so computationally demanding they cause brownouts, and to mitigate that these are peeled out of the monolith to dedicated services to help manage load. Is this a monolith or microservices?

Consider that you run a monolith and suddenly you have new set of requirements that forces you to do a major rewrite. You start off with a clone of the original monolith and gradually change functionality, and to avoid regressions you deploy both instances and have all traffic going through an API gateway to handle dialups. Is this microservices or monolith?

The main problem with these vacuous complains about monoliths is that they start from a place of clueless buzzwords, not understanding what they are talking about and what problems are being addressed and solved. This blend of specious reasoning invariably leads jumps from absolutisms to other absolutisms. And they are always wrong.

I mean, if problems are framed in terms of fashion tips, how can the possibly be right?

This nonsese reads like a badly prompted machine-generated text.

Against errors and regressions. Meaning, stuff that breaks your code and affects the service you provide to users.

Style issues ain't that. Come on.

I had to check and I was amazed that there are companies selling workstations with dual EPYC processors, providing a whopping 256 CPU cores and over 2TB of DDR5. All in a desktop form factor. Amazing.

The article was posted in 2023.

The are saying "buy a single EPYC instead of two of our competition".

The robo-taxi fleet is scheduled to be launched by 2026. This means Tesla, in spite of Elon Musk's wild claims, is not counting on providing anything remotely similar to FSD until at least 2026.

I don't know where you get your stock quotes. The ones I get tell that last monday TSLA stock prices were at around $350 and right now they stand at $345.