Comment by unicornporn | Hacker News Reader

Comment by unicornporn | Hacker News Reader

Sorry, this reads like a The Onion piece for developers. It looks like pure nightmare. There's so much complexity that simply doesn't need to be there.

I have to agree here, this article really goes out to show the perceived state of JavaScript & web development. over-engineered is the key word here

On the other hand, a lot of people on HN promote Kubernetes, even for relatively basic sites/servers/APIs

Kubernetes is a way to handle complexity with infrastructure and operations that is codified and implemented as a single standardized and portable solution. Much of what K8S does is replace what you would be doing manually or by tying together many other tools yourself.

That's completely different than taking a simple blogging site and turning it into some distributed monstrosity.

> Much of what K8S does is replace what you would be doing manually or by tying together many other tools yourself

So that's where it's wrong IMO, it replaces simple static site hosting/managers/etc, instead of having a single-click toolchain that takes your commits and CI/CD it properly, you now have to install and maintain that yourself manually.`

There are many CI/CD pipelines that deploy to K8S.

The "simple static site hosting" isn't magic, it's usually nothing more than a wrapper around putting your code into a nodejs docker container and deploying it to some lambda/serverless platform with a CDN in front. Your post is exactly what I mean about many frontend devs not understanding backend or infrastructure resulting in convoluted architectures.

Kubernetes is a low level tool which should be used only at large companies with large teams to support it and build all the required tooling around it.

80% of companies building on top of kubernetes should just pay some provider to do it for them, or use higher level tools. The crazyness going in the DevOps/Infrastructure world is as bad, or worse, as the one going on in the frontend space.

Kubernetes provides a standardized way to deploy application artifacts to multiple servers, and handles monitoring, logging, process management, storage, networking, security, isolation, high-availability, rolling deployments, and other concerns in a industry-standard way that is portable across providers.

It's just software that runs your software. You can't remove complexity, only abstract it. Instead of using Chef/Puppet/systemd/hand-written scripts and a bunch of other tools to run and monitor your processes, you can replace all that with K8S.

> "used only at large companies with large teams"

Actually it's even more useful with smaller teams and let me, as a team of 1, deploy a global ad platform running billions of requests a day across hundreds of servers in multiple regions. Don't mistake lack of knowledge and experience as a problem with the tool.

> "pay some provider to do it for them"

Yes, you should use a managed K8S offering. Using K8S doesn't mean you have to install and operate it from scratch.

GCP's Autopilot k8s is basically point-and-click. Literally takes few minutes to get up and running. It even creates CI/CD pipelines for you.

As with everything else, setting up things is not the problem. The problem is maintaning them.

It takes much less effort to maintain k8s deployments than to maintain bespoke, randomly cobbled together ones.

Looks like he is selling courses(have to justify those prices somehow) and simple stable boring stuff doesn't sell ;)

He's selling courses on the technology he used, so the site is both a demonstration of and lesson in what he teaches. It's a functional portfolio that seems intended to demonstrate that the author and instructor understands what he is asking you to pay him to teach.

Understanding when and where to deploy technology is much more important than just using everything. Sadly that's much harder to teach.

Agree 100%. By erecting this over-engineered gold-plated edifice the author has demonstrated knowledge, but not wisdom.

Just out of curiosity, how would you design a distributed website like this? How can this be done simpler?

By not making it distributed.

What is missing from the description apparently is the SLA for the site's downtime.

If it's really low, I can imagine why it was made distributed. Otherwise, I'd see that as a demo and an exercise.

It is the author's own website, there is no contractual SLA.

In any case, with a distributed architecture there are many parts that can break. Fewer moving parts means fewer broken pieces.

> What is missing from the description apparently is the SLA for the site's downtime.

> If it's really low, I can imagine why it was made distributed.

If an extremely low SLA is the goal, I would not be home-rolling a distributed website technology stack. The more moving pieces you have, the more likely one of them is to fail.

The recipe for a high availability, high reliability website is relatively simple in the age of Cloudflare and other cheap hosted services. Introducing a lot of complexity and home-grown solutions is the last thing you want for high availability unless you have scores of engineers to maintain it and you can't solve it through traditional means.

While I agree in principle, a database-driven distributed site would need a bit more than cloudflare.

(For a personal informational site I'd take a static site generator.)

That “distributed” quality itself is a choice that introduces complexity. There are many sites that deliver the same or greater level of value to users, and use a “boring” architecture and deployment.

Do you mind sharing some? Most websites I can think of are either highly distributed (e.g. Facebook, Netflix) or their customer base is geographically limited (Yelp).

Uploading media files to (or from) developing countries with weaker internet infra often results in timeouts and dropped connections. I tried uploading a 8GB file to Singapore S3 from Florida and my connection often timed out.

I'm trying to imagine how you can deliver a fast website to users around the globe without distributed systems.

Those are all sites with 1000s of engineers, real-world use, and actual evolutionary pressure driving their features. You want to compare to essentially static sites with some light user statefulness.

This guy's site is not netflix nor facebook, nor is he 10k developers to support those architectures.

If this guy were pragmatic, a Ruby on Rails/django app in heroku would do wonders. If he wants to promote React because that's what he sells, that's a different story.

The problem is the people taking what this guy says as "the modern way to do it" and then you find the messes you find at work.

Sorry for offtopicness but could you please email hn@ycombinator.com? I want to send you a repost invite.

My email is the same as my username at the usual proton mail domain.

Sorry for my dumbness, but not sure what a repost invite is. Something good I hope XD.

Thanks.

Thanks, I'll send it!

For anyone who's wondering: a repost invite is a way of getting a post into the second-chance pool (https://news.ycombinator.com/pool, explained at https://news.ycombinator.com/item?id=26998308), so it will get a random placement on HN's front page. If the original submission is older than a few days, we don't re-up it, but rather invite the submitter to repost it. Then it goes automatically into the pool. So yes, it's something good :)

Done. Thanks!

Well since this looks like a blog, either using a blogging platform, or a static website generator hosted on either a static website platform(1) or something like lambda + a cdn

(1): https://azure.microsoft.com/en-us/services/app-service/stati...

and the login for your users?

The article explicitly mentions needing to support writes with a globally distributed user base. This is not a static website.

Not everything in a static webapp needs to be static, just push most static things to the CDN and render some things like "user details" on the client... it just works out so much simpler.

At least half of the gains can probably achieved by just rolling a distributed redis setup and not distributing the PostgreSQL database. This should cover most non-personalized read operations which on this type of site should be most of them. It also seems like the database distribution is an attempt to solve a problem of his own making. He states that each blog posts page view needs 30 database queries in the background. This to me suggests an inefficient data structure or complexity for complexity’s sake. Heck, he could probably even achieve 80% of what he’s trying to do by delivering selected slow but static queries from edge computing KV stores without having any further distributed backend or database servers. But ofc this whole project is a sales pitch and he would get the attention he’s receiving with a simple Django+Postgres+Redis setup in a single region with just basic CI/CD.

Ruby On Rails

It doesn't need to be distributed. It's a mostly static site with some dynamic parts.

A single small server running a typical web framework (anything from django to asp.net to laravel) can easily serve all these pages in milliseconds. Add a CDN in front to cache and serve quickly to users around the world.

This was my first reaction. But then I can also understand why you would use your own website as either an exercise or a showcase of all these techs.

I used to host my blog on Kubernetes for a while for that specific reason, just practice how to deploy and operate it. Then after I got bored with that simply transfered that to a static hosting solution.

Just imagine all the newbie and junior devs following the ideas this person puts in their heads. That's how you land a new job just to find out the landing has more engineering than the Mars Rover.

Nailed it. The whole time I was reading I had this uncanny valley feeling of like “this is so close to satire but not quite” waiting on the needle to drop that sealed it as satire, but it never came.

Reply on news.ycombinator.com