Definitely an interesting article overall on how to be successful why avoiding over-engineering. And while there is some good advice here, it’s clear that author has fallen prey to what affects many junior engineers. The belief that the tools that are known are easier and better to use than the available alternatives.
While the author claims to use dead simple things that actually work, in the post, it is clear that the tools neither are simple nor the best solution. I’m going to break down some of the issues with the tech choices.
Backend Issues
Most of these servers can be horizontally scaled.
Having a unique naming formula helps scale, I agree, but it isn’t obvious how easy it is to actually scale them. Despite not having any CI/CD tools, there are tons of unanswered questions here:
- How to do you actually provision these machines? Do you click in the AWS console or something else? (single click of a button <> Ansible)
- How then do you make sure the machines are actually up and running?
- Once they are running how does AWS know that they can be used to support your infrastructure?
- How do security patches or server upgrades work?
- …
With a streamlined pipeline or autoscaling in place, this wouldn’t be a question, you would know you can sleep in because the scaling takes place without needing to intervene in the provisioning and configuration of your infrastructure.
The main data store is PostgreSQL, which I’ve got a lot of development & operational experience over many years — battle tested technology is good, so I can sleep well at night.
This has nothing to do with simple and just works, it is more of a justification of picking the tool you know best. Sure it can be what you like, but it doesn’t mean it is the right tool for the job. So sans the other problems, we haven’t justified the choices made other than using opinions.
Each of the parts of the stack goes on and on, proving that none of the technology choices worked out of the box, and their each required extensive additional knowledge to make sure they work. For instance, if you were using an Application Load Balancer (ALB), you wouldn’t need the gauntlet of tech to support web requests — uWSGI, NGINX, Supervisord, Celery, Celery Beat, etc…
Want cron like processing that is quick? On server start up create a timer that runs on the server? Why include 3 more technologies to additionally support that? That’s neither simple nor the best.
Unless you already knew that the cloud couldn’t contain your solution and you needed some bare metal, (although now most support bare-metal options), all of your backend could have been solved with automated cloud solutions, nothing manual or complicated.
Frontend Issues
Actually most of the tech sounds reasonable, so not sure why make the big fuss over not using the best tools. It sounds like a junior frontend dev that likes playing around with the UI framework goodies, but doesn’t do the due diligence to build a sufficient backend strategy.
But then goes on to talk about
most web pages are half server-side rendered (Django template) and half client-side rendered (React).
That’s some fearsome stuff there. Let’s just mash everything together, this isn’t even a question of tech. Can you imagine having to fix a bug or add a website feature, this is no longer a simple task.
Going forward
While the advice in other areas is nice, there are still some more nuanced issues. Words thrown around like “contractors” shed light on the fact that isn’t totally supported by one guy. This means that when changes need to be done, they are inefficient and costly. $$$ For both running the technology, and $$$ to maintain it.
By making small changes to the architecture time and money can be saved on every change. This would actually make it simple, but it relies on learning the right tech and investing in that as a person rather building a side-project which struggles to scale. Could you imagine jumping into that mess to bring the 1 person team to 2? I’m not suggesting it has to be sustainable up to multiple teams, but even expecting that you have one to two other consistent collaborators makes it much easier to maintain in the long run.