6 ms·
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.
by unicornporn 5y ago
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.
- itake 5y agoJust out of curiosity, how would you design a distributed website like this? How can this be done simpler?
- glutamate 5y agoBy not making it distributed.
- nine_k 5y agoWhat 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.
- glutamate 5y agoIt 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.
- PragmaticPulp 5y ago> 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.
- nine_k 5y agoWhile 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.)
- deleted 5y ago[deleted]
- jcoder 5y agoThat “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.
- itake 5y agoDo 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.
- jcoder 5y agoThose 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.
- midrus 5y agoThis 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.
- charles_f 5y agoWell 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/static/ https://azure.microsoft.com/en-us/services/app-service/stati...
- fullstackchris 5y agoand the login for your users?
- itake 5y agoThe article explicitly mentions needing to support writes with a globally distributed user base. This is not a static website.
- gitgud 5y agoNot 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.
- hijodelsol 5y agoAt 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.
- midrus 5y agoRuby On Rails
- manigandham 5y agoIt 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.
- mariogintili 5y agoI 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
- listenallyall 5y agoOn the other hand, a lot of people on HN promote Kubernetes, even for relatively basic sites/servers/APIs
- manigandham 5y agoKubernetes 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.
- franciscop 5y ago> 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.`
- manigandham 5y agoThere 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.
- midrus 5y ago
- ithrow 5y agoLooks like he is selling courses(have to justify those prices somehow) and simple stable boring stuff doesn't sell ;)
- cratermoon 5y agoHe'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.
- manigandham 5y agoUnderstanding when and where to deploy technology is much more important than just using everything. Sadly that's much harder to teach.
- cratermoon 5y agoAgree 100%. By erecting this over-engineered gold-plated edifice the author has demonstrated knowledge, but not wisdom.
- charles_f 5y agoThis 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.
- midrus 5y agoJust 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.
- jonwest 5y agoNailed 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.