What the hell have you built
wthhyb.sacha.house
wthhyb.sacha.house
There are things we don’t want to do (talk to costumers, investors, legal, etc.), so instead we do the fun things (fun for engineers).
It’s a convenient arrangement because we can easily convince ourselves and others that we’re actually being productive (we’re not, we’re just spinning wheels).
Unless you actively push yourself to do the uncomfortable work every day, you will always slowly deteriorate and you will run into huge issues in the future that could've been avoided.
And that doesn't just apply to software.
I should get off HN, close the editor where I'm dicking about with HTMX, and actually close some fucking tickets today.
Right after I make another pot of coffee.
...
No. Now. Two tickets, then coffee.
Thank you for the kick up the arse.
Removing it, no matter whether I created it myself, sure, that can be a hard problem.
I've certainly been guilty creating accidental complexity as a form of procrastrination I guess. But building a microservices architecture is not one of these cases.
FWIW, the alternative stack presented here for small web sites/apps seems infinitely more fun. Immediate feedback, easy to create something visible and change things, etc.
Ironically, it could also lead to complexity when in reality, there is (for example) an actual need for a message queue.
But setting up such stuff without a need sounds easier to avoid to me than, for example, overgeneralizing some code to handle more cases than the relevant ones.
When I feel there are customer or company requirements that I can't fulfill properly, but I should, that's a hard problem for me. Or when I feel unable to clarify achievable goals and communicate productively.
But procrastrination via accidental complexity is mostly the opposite of fun to me.
It all comes back when trying to solve real problems and spending work time solving these problems is more fun than working on homemade problems.
Doing work that I am able to complete and achieving tangible results is more fun than getting tangled in a mess of unneeded complexity. I don't see how this is fun for engineers, maybe I'm not an engineer then.
Over-generalization, setting wrong priorities, that I can understand.
But setting up complex infra or a microservices architecture where it's unneeded, that doesn't seem fun to me at all :)
Normally the impetus to overcomplicate ends before devs become experienced enough to be able to even do such complex infra by themselves. It often manifests as complex code only.
Overengineered infra doesn't happen in a vacuum. There is always support from the entire company.
I certainly did for a number of years - I just had the luck that the cool things I happened to pick on in the early/mid 1990s turned out to be quite important (Web '92, Java '94).
Now my views have flipped almost completely the other way - technology as a means of delivering value.
Edit: Other cool technology that I loved like Common Lisp & CLOS, NeWS and PostScript turned out to be less useful...
I believe only bad (inexperienced) programmers do.
Interesting term. Probably pretty on-point.
I’ve been shipping (as opposed to just “writing”) software for almost my entire adult life.
In my experience, there’s a lot of “not fun” stuff involved in shipping.
Or is it to satisfy the ideals of some CTO/VPE disconnected from the real world that wants architecture to be done a certain way?
I still remember doing systems design interviews a few years ago when microservices were in vogue, and my routine was probing if they were ok with a simpler monolith or if they wanted to go crazy on cloud-native, serverless and microservices shizzle.
It did backfire once on a cloud infrastructure company that had "microservices" plastered in their marketing, even though the people interviewing me actually hated it. They offered me an IC position (which I told them to fuck off), because they really hated how I did the exercise with microservices.
Before that, it almost backfired when I initially offered a monolith for a (unbeknownst to me) microservice-heavy company. Luckily I managed to read the room and pivot to microservice during the 1h systems design exercise.
EDIT: Point is, people in positions of power have very clear expectations/preferences of what they want, and it's not fun burning political capital to go against those preferences.
In those interviews (and in real work too) people still want you skewing towards certain answers. They wanna see you draw their pet architecture.
And it's the same thing in the workplace.
Also: if there's limited knowledge on the interviewer side, an incorrect answer to a question might throw off a more experienced candidate.
It's no big deal but it becomes more about reading the room and knowing the company/interviewers than being honest in what you would do. People don't want to hear that their pet solution is not the best. Of course you still need to know the tech and explain it all.
For context, my current project is a monolith web app with services being part of the monolith and called with try/catch. I can understand perhaps faster, independent, less risky recovery in the micro services case but don’t quite understand the fault tolerance gain.
It's been a long time since I've done "normal" web development, but I've done a number of high-performance or high-reliability non-web applications, and I think people really underestimate vertical scaling. Even back in the early 2000s when it was slightly hard to get a machine with 128GB of RAM to run some chip design software, doing so was much easier than trying to design a distributed system to handle the problem.
(we had a distributed system of ccache/distcc to handle building the thing instead)
Do people have a good example of microservices they can point us to the source of? By definition it's not one of those things that makes much sense with toy-sized examples. Things like Amazon and Twitter have "micro" services that are very much not micro.
His reasoning was all the big players use it, so we should be too...
It was literally a solution looking for a problem. Which is completely arse backwards.
EC2 was forbidden, it had to be ECS or EKS if Lambda was not possible.
We did the math and the AWS bill had the cost of about 15 developers.
If we can do this with nearly zero marketing, it stands to reason that some well thought out marketing would probably work.
However having in the CV any of those items from left side in the deployment strategy is way cooler than mentioning n-tier architecture, RPC (regardless how they are in the wire), any 1990's programming language, and so forth.
A side effect from how hiring works so badly in our industry, it isn't enough to know how master a knife to be a chef, it must be a specific brand of knife, otherwise the chef is not good enough for the kitchen.
For example, in the recent "who's hiring" thread, I saw at least two places where they did that: Duckduckgo (they mention only algorithms and data structures and say "in case you're curious, we use Perl") and Stream (they offer a 10-week intro course to Go if you're not already familiar with it). If I remember correctly, Jane Street also doesn't require prior OCaml experience.
The place where I work (bevuta IT GmbH) also allowed me to learn Clojure on the job (but it certainly helped that I was already an expert in another Lisp dialect).
These hiring practices are a far cry from those old style job postings like "must have 10+ years of experience with Ruby on Rails" when the framework was only 5 years old.
[1] all those examples check that box, but please let's not start a language war over this statement.
[2] for Jane Street I hear they do, DDG pays pretty well especially because it pay the same rate regardless where you are in the world, so it's a top-talent salary for many places outside SV.
And best of all, you don't feel the need to keep chasing after the latest hype just to keep your CV relevant.
Yes, it’s nonsense, stirring up a turbulent slurry of eventually consistent components for the sake of supporting hundreds of users per second, it’s also the nonsense that you’re expected to say, just do it.
Really that's going way too far - you do NOT need Redis for caching. Just put it in Postgres. Why go to this much trouble to put people in their place for over engineering then concede "maybe Redis for caching" when this is absolutely something you can do in Postgres. The author clearly cannot stop their own inner desire for overengineering.
The reason startups get to their super kubernetes 6 layers mega AWS powered ultra cached hyper pipelined ultra optimised web queued applicatyion with no users is because "but technology X has support for an eventually consistent in-memory caching layer!!"
What about when we launch and hit the front page of HN how will the site stay up without "an eventually consistent in-memory caching layer"?
https://www.postgresql.org/docs/18/sql-createtable.html#SQL-...
lol, In the diagram, Redis is not even talking with MongoDB
The caching abstractions your frameworks have are also likely designed with something like Redis in mind and work with it out of the box. And often you can just start with an in-memory cache and add Redis later, if you need it.
Probably should stop after this line - that was the point of the article. It will work at lower scales. Optimize later when you actually know what to optimize.
It'll give you time to redesign and rebuild so Postgres is fast enough again. Then you can take Redis out, but once you've set it up you may as well keep it running just in case.
I think that redis is a reasonable exception to the rule of ”don’t complicate things” because it’s so simple. Even if you have never used it before, it takes a few minutes to setup and it’s very easy to reason about, unlike mongodb or Kafka or k8s.
Postgres in isolation has no problem with 1000 RPS. But does your Postgres server have that ability? Your server is also handling more complex requests and maybe some writes and concurrent re-indexing.
In that scenario, the last thing you need is another layer between application and database.
Even in a distributed environment, you can scale pretty far with direct-to-database as you say.
Until you get to 100 test users. Then you need Kafka and k8.
Redis/valkey is definitely overkill though. A slightly modified memcached config (only so it accepts larger keys; server responses larger than 1MB aren't always avoidable) is a far simpler solution that provides 99% of what you need in practice. Unlike redis/valkey, it's also explicitly a volatile cache that can't do persistence, meaning you are disincentivized from bad software design patterns where the cache becomes state your application assumes any level of consistency of (including it's existence). If you aren't serving millions of users, stateful cache is a pattern best avoided.
DB caches aren't very good mostly because of speed; they have to read from the filesystem (and have network overhead), while a cache reads from memory and can often just live on the same server as the rest of the service.
But I have to defend Tailwind, it's not a massive CSS framework, it just generates CSS utility classes. Only the utility classes you use end up in the output CSS.
Adding guardrails to protect your team from itself mandates some complexity, but just hand-waving that away as unnecessary is a bad answer. At least if you're not working as part of a team.
> Organizations which design systems... are constrained to produce designs which are copies of the communication structures of these organizations.
I worked for a company that had done pretty much that - not fun at all (for extra fun half the microservices where in a language only half the dev team had even passing familiarity with).
You need someone in charge with "taste" enough to not allow that to happen or it can happen.
The same pattern repeats across multiple companies - it comes down to trust and delegation, if the people with the power are unwilling to delegate bad things happen.
Make them part of your build first. Tagging a release? Have a documented process (checklist) that says 'run this, do that'. Like how in a Java Maven build you would execute `mvn release:prepare` and `mvn release:perform`, which will execute all tests as well as do the git tagging and anything else that needs doing.
Scale up to a CI pipeline once that works. It is step one for doing that anyway.
Maybe interacted with CIs too much and it's Stockholm syndrome, but they are there to help tame and offload complexity, not just complexity for complexity'a sake
Theoretically. Practically, you're hunting for the reason why your GitHub token doesn't allow you to install a private package from another repository in your org during the build, then you learn you need a classic personal access token tied to an individual user account to interact with GitHub's own package registry, you decide that that sounds brittle and after some pondering, you figure that you can just create a GitHub app that you install in your org and write a small action that uses the GitHub API to create an on-demand token with the correct scopes, and you just need to bundle that so you can use it in your pipeline, but that requires a node_modules folder in your repository, and…
Oh! Could it be that you just added complexity for complexity's sake?
But on that point I agree, initial set-up can be extremely dauntin due to the amoun of different technologies that interact, and requires a level of familiarity that most people don't want to have with these tools. which is understandable; they're a means to an end and Devs don't really enjoys playing with them (DevOps do tho!). I've had to wear many hats in my career, and was the unofficial dedicated DevOps guy in a few teams, so for better or worse had to grow familiar with them.
Often (not always) there's an easier way out, but spotting it through the bushes of documentation and overgrown configuration can be annoying.
As long as you're pragmatic and honest with what you need from your CI setup, it's okay that it makes your system more complex—you're getting something in return after all.
Okay no but seriously, if you're not being held back by how slow GitHub CI/Gitlab runners are, great! For others they're slow as molasses and others in different languages with different build systems can run an iteration of their build REPL before git has even finished pushing, nevermind waiting for a runner.
And some of these guidelines have grown into satus quo common recipes. Take your starting database for example, the guideline is always "sqlite only for testing, but for production you want Postgres" - it's misleading and absolutely unnecessary. These defaults have also become embedded into PaaS services e.g. the likes of Fly or Scaleway - having a disk attached to a VM instance where you can write data is never a default and usually complicated or expensive to setup. All while there is nothing wrong with a disk that gets backed up - it can support most modern mid sized apps out there before you need block storage and what not.
I just set one build agent up with a tag that both plans required. The simplest thing that could possibly work.
Or, consider redundancy: Your customers likely expect your service to not have an outage. That's a simple requirement, but very hard to get right, especially if you're using a single server that provides your application. Just introducing multiple copies of the app running in parallel comes with changes required in the app (you can't assume replica #1 will handle the first and second request—except if you jump through sticky session hoops, which is a rabbit hole on its own), in your networking (HTTP requests to the domain must be sent to multiple destinations), and your deployment process (artefacts must go to multiple places, restarts need to be choreographed).
Many teams (in my experience) that have a disdain for complex solutions will choose their own, bespoke way of solving these issues one by one, only to end up in a corner of their own making.
I guess what I'm saying is pretty mundane actually—solve the right problem at the right time, but no later.
So I think now: Unless you have a really really simple model and app, you are just better off simply starting postgres or a postgres container.
> Unless you have a really really simple model and app
And this is the wrong conclusion. I have a really really complex model that works just fine with SQlite. So it’s not about how complex the model is, it’s about what you need. In the same way in the original post there were so many storage types, no doubt because of such “common knowledge guidelines”
I guess you could say "use sqlite as long as it lends itself well to what you are doing", sure. But when do you switch? At the first inconvenience? Or do you wait a while, until N inconveniences have been put into the codebase? And not to forget, the organizational resistance to things like changing the database. People not in the know (mangement usually) might question your plan to switch the database, because this workaround for this small little inconvenience _right now_ seems much less work and less risky for production ... Before you know it, you will have 10 workarounds in there, and sunken cost fallacy.
I may be exaggerating a little bit, but it's not like this is a crazy to imagine picture I am painting here.
Changing the database can create friction, but at that moment you can also ask yourself: What is the cost of adding/learning this giant stateful component with maintenance needs (postgres) vs. say adapting our schema to be more compatible with what we have? (e.g. the lightweight and much cheaper sqlite, but the argument works for whatever you already have).
I'd much rather see folks thinking about that. Same for caching and CDNs and whatever Cloudflare is selling this week to hook people on their platform (e.g. DDoS/API gateway protections come in many variants, we're not all 1password and sometimes it's ok to just turn on the firewall from your hosting provider).
(except the caching layer. Remember the three hard problems of computer science, of which cache invalidation is one.)
Still hoping for a good "steelman" demonstration of microservices for something that isn't FAANG-sized.
Rather, cache invalidation is the process of determining which cache entries are stale and need to be replaced/removed.
It gets hairy when determining that depends on users, user group memberships AND per-user permissions, access TTL, multiple types of timestamps and/or revision numbering, and especially when the cache entries are composite as in contain data from multiple database entities, where some are e.g. representing a hierarchy and may not even have direct entity relationships with the cached data.
Oh, it absolutely does. You need some way to get your secrets into the application, at build- or at runtime, for one, without compromising security. There's a lot of subtle catches here that can be avoided by picking standard tooling instead of making it yourself, but doing so definitely shapes your architecture.
You can get all that with a monolith server and a Postgres backend.
(Sarcasm)
Sarcasm doesn't work online, If I write something like "Donald Trump is the best president ever" you don't have any way of knowing whether I'm being sarcastic or I'm just really really stupid. Only people who know me can make that judgement, and basically nobody on here knows me. So I either have to avoid sarcasm or make it clear that I'm being sarcastic.
If your business can afford irregular downtime, by all means, go for it. Otherwise, you'll need to take precautions, and that will invariably make the system more complex than that.
And if certain servers do get very important you just run a backup server with VPS and switch over DNS (even if you keep a high ttl, most servers update within minutes nowadays) or if you want to be fancy throw a load balancer in front of it.
If you solve issues in a few minutes people are always thankful, and most dont notice. With complicated setups it tends to take much longer before figuring out what the issue is in the first place.
Also in 5 years of working on both microservicy systems and monoliths, not once has these things you describe been a problem for me. Everything I've hosted in Azure has been perfectly available pretty much all the time unless a developer messed up or Azure itself has downtime that would have taken down either kind of app anyway.
But sure let's make our app 100 times more complicated because maybe some time in the next 10 years the complexity might save us an hour of downtime. I'd say it's more likely the added complexity will cause more downtime than it saves.
I don't think I implied that microservices are the solution, really. You can have a replicated monolith, but that absolutely adds complexity of its own.
> But sure let's make our app 100 times more complicated because maybe some time in the next 10 years the complexity might save us an hour of downtime.
Adding replicas and load balancing doesn't have to be a hundred times more complex.
> I'd say it's more likely the added complexity will cause more downtime than it saves.
As I said before, this is an assessment you will need to make for your use case, and balance uptime requirements against your complexity budget; either answer is valid, as long as you feel confident with it. Only a Sith believes in absolutes.
As your business needs grow, you can start layering complexity on top. The point is you don't start at 11 with a overly complex architecture.
In your example, if your server crashes, just make sure you have some sort of automatic restart. In practice that may mean a downtime of seconds for your 12 users. Is that more complexity? Sure - but not much. If you need to take your service down for maintenance, you notify your 12 users and schedule it for 2am ... etc.
Later you could create a secondary cluster and stick a load-balancer in-front. You could also add a secondary replicated PostgreSQL instance. So the monolith/postgres architecture can actually take you far as your business grows.
It is common for founding engineers to start with a preexisting way of working that they import from their previous more-scaled company, and that approach is refined and compounded over time
It does mean starting with more than is necessary at the start, but that doesn't mean it has to be particularly complex. It means you start with heaps of already-solved problems that you simply never have to deal with, allowing focus on the product goals and deep technical investments that need to be specific to the new company
But for management, it's completely different. It's all about managing complexity on an organizational level. It's so much easier to think in terms "Team 1 is in charge of microservice A". And I know from experience that it works decently enough, at least in some orgs with competent management.
I think that's the first time I've heard any "techie" say we use containers because of reliability or zero-downtime deployments, those feel like they have nothing to do with each other, and we've been building reliable server-side software with zero-downtime deployments long before containers became the "go-to", and if anything it was easier before containers.
Deploys usually took minutes (unless something was broken), scaling worked the same as if you were using anything else, increase a number and redeploy, and no Kubernetes, Docker or even containers as far as the eye could see.
I know: it’s ridiculous to have an architectural barrier for an organizational reason, and the cost of a bad slice multiplies. I still think in some situations, that is better to the gas-station-bathroom effect of shared codebases.
But why is this natural? I’m not saying we shouldn’t have network RPC, but it’s not obvious to me that we should have only network RPC when there are cheap local IPC mechanisms.
Premature optimisation is the root of all evil. But premature pessimisation is not a good thing either. You should keep options open, unless you have a good reason not to do so.
If your IPC involves moving gigabytes of transient data between components, may be it's a good thing to use shared memory. But usually that's not required.
This is somewhat common in containerisation where e.g. Kubernetes lets you set up sidecars for logging and so on, but I suspect it could go a lot further. Many microservices aren't doing big fan-out calls and don't require much in the way of hardware.
That’s what I was referring to, sorry for the inaccurate adjective.
Most people try to split a monolith in domains, move code as libraries, or stuff like that - but IMO you rarely avoid a shared space importing the subdomains, with blurry/leaky boundaries, and with ownership falling between the cracks.
Micro services predispose better to avoid that shared space, as there is less expectation of an orchestrating common space. But as you say the cost is ridiculous.
I think there’s an unfilled space for an architectural design that somehow enforces boundaries and avoids common spaces as strongly as microservices do, without the physical separation.
But that doesn't warrant its use in smaller organizations, or for smaller deployments.
Organizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations.
Then suddenly one realises that techies can also be bad at management.
Management of a container environment not only requires deployment skills but also documentational and communication skills. Suddenly it’s not management rather the techie that can't manage their tech stack.
This pointing of fingers at management is rather repetitive and simplistic but also very common.
That's fine, 6 of them are test accounts :-)
> It's sure a corny stance to hold if you're navigating an infrastructure nightmare daily, but in my opinion, much of the complexity addresses not technical, but organisational issues
If you have an entire organisation dedicated to 6 users, those users had better be ultra profitable.
> If the process crashes or your harddisk dies, you want redundancy so even those twelve customers can still access the application
Can be done simply by a sole company owner; no need for tools that make sense in an organisation (K8s, etc)
> You want a CI pipeline, so the junior developer can't just break prod because they forgot to run the tests before pushing.
A deployment script that includes test runners is fine for focused product. You can even do it using a green/blue strategy if you can afford the extra $5-$10/m for an extra VPS.
> You want proper secret management, so the database credentials aren't just accessible to everyone.
Sure, but you don't need to deploy a full-on secrets-manager product for this.
> You want a caching layer, so you're not surprised by a rogue SQL query that takes way too long, or a surge of users that exhaust the database connections because you never bothered to add proper pooling.
Meh. The caching layer is not to protect you against rogue SQL queries taking too long; that's not what a cache is for, after all. As for proper pooling, what's wrong with using the pool that came with your tech stack? Do you really need to spend time setting up a different product for pooling?
> dding guardrails to protect your team from itself mandates some complexity, but just hand-waving that away as unnecessary is a bad answer.
I agree with that; the key is knowing when those things are needed, and TBH unless you're doing a B2C product, or have an extremely large B2B client, those things are unnecessary.
Whatever happened to "profile, then optimise"?
Yes, I also put Redis in that list. You can cache and serve data structure in many other ways, for example replicate the individual features you need in you application instead of going the lazy route and another service to the mix. And don't get me started on Kafka... money thrown in the drain when a stupid grpc/whatever service would do.
Part of being an engineer is also selecting the minimum amount of components for your architecture and not being afraid of implementing something on your own if you only need 1 of 100s features that an existing product require.
Well put!
This does assume that said complexity can be added ad hoc later. Often earlier architecture choices make additions complex too or even prevent it entirely without a complete rewrite
So while the overall message is true there is some liberal use of simplification at play here too
In some cases a compromise can make sense. Eg use k8s but keep it simple within that - as vanilla as you can make it
I totally get the point it makes. I remember many years ago we announced SocketStream at a HackerNews meet-up and it went straight to #1. The traffic was incredible but none of us were DevOps pros so I ended up restarting the Node.js process manually via SSH from a pub in London every time the Node.js process crashed.
If only I'd known about upstart on Ubuntu then I'd have saved some trouble for that night at least.
I think the other thing is worrying about SPOF and knowing how to respond if services go down for any reason (e.g. server runs out of disk space - perhaps log rotation hasn't been setup, or has a hardware failure of some kind, or the data center has an outage - I remember Linode would have a few in their London datacenter that just happened to occur at the worst possible time).
If you're building a side project I can see the appeal of not going overboard and setting up a Kubernetes cluster from the get-go, but when it is things that are more serious and critical (like digital infrastructure for supporting car services like remotely turning on climate controls in a car), then you design the system like your life depends on it.
Consider WhatsApp could do 2M TCP connections on a single server 13 years ago, and Ford sells about 2M cars per year. Basic controls like changing the climate can definitely fit in one TCP packet, and aren't sent frequently, so with some hand-waving, it would be reasonable to expect a single server to handle all remote controls for a manufacturer for all cars from some year model.
Or maybe you could use wifi-direct and bypass the need for a server.
Or a button on the key fob. Perhaps the app can talk to the key fob over NFC or Bluetooth? Local/non-internet controls will probably be more reliable off-grid... can't have a server outage if there are no servers.
I guess my point is if you take a step back, there are often simple, good solutions possible.
Left unchecked, Claude is very happy to propose "robust, scalable and production ready" solutions - you can try it for yourself. Tell it you want to handle new signups and perform some work like send an email or something (outside the lifecycle of the web request).
That is, implying you need some kind of a background workload and watch it bring in redis, workflow engines, multiple layouts for docker deployment so you can run with and without jobs, obscene amount of environment variables to configure all that, create "fallbacks" and retries and all kinds of things that you will never spend time on during an MVP and even later resist adding just because of the complexity and maintenance they require.
All that while (as in the diagram of the post), there is an Erlang/Elixir app capable of doing all that in memory :).
The problem is that people don't like hearing their ideas suck. I do this too, to be fair. So, yes, we spend endless hours architecting what we'd desperately hope will be the next Facebook because hearing "you are definitely not the next Facebook" sucks. But alas, that's what doing startups is: mostly building 1000 not-Facebooks.
The lesson here is that the faster you fail, the faster you can succeed.
My argument is this; even if the system itself becomes more complex, it might be worth it to make it better partitioned for human reasoning. I tend to quickly get overwhelmed and my memory is getting worse by the minute. It's a blessing for me with smaller services that I can reason about, predict consequences from, deeply understand. I can ignore everything else. When I have to deal with the infrastructure, I can focus on that alone. We also have better and more declarative tools for handling infrastructure compared to code. It's a blessing when 18 services doesn't use the same database and it's a blessing when 17 services isn't colocated in the same repository having dependencies that most people don't even identify as dependencies. Think law of leaky abstractions.
OTOH, If you are trying to sell the idea to investors and large companies that you are a serious player and have a plan and know-how to grow and scale your service quickly, maybe you do want to show that you have the design chops and ability to actually scale your product. Take a look and ask yourself, "Does my business model only work if it scales up dramatically, far beyond the capacity of a single database?" If the answer is "yes", start with a scalable architecture to save the 100+ person-years and endless gnashing of teeth it will take to untangle your monolith (been there.)
Especially in an age where you can basically click a menu in GitHub and say "Hey, can I have a CI pipeline please?"
I've built pretty scalable things using nothing but Python, Celery and Postgres (that usually started as asyncio queues and sqlite).
I would argue it is not resilient enough for a web app.
No one wrote the rules in stone, but I assume server side you want the host to manage data recovery and availability. Client side it is the laptop owners problem. On a laptop, availability is almost entirely correlated with "has power source" and "works" and data recovery "made a backup somehow".
So I think we are both right?
I don't see how this has worse effects on recovery and availability. The data is still in a separate file, that you can backup and the modification still happens through a database layer which handles atomic transactions and file system interaction. The availability is also not worse, unless you would have hot code reloading without SQLite, which seems like an orthogonal issue.
Why?
Because in 1999 when I started using PHP3 to write websites, I couldn't get MySQL to work properly and Postgres was harder but had better documentation.
It's ridiculous spinning up something as "industrial strength" as Postgres for a daft wee blog, just as ridiculous as using a 500bhp Scania V8 for your lawnmower.
Now if you'll excuse me, I have to go and spend ten seconds cutting my lawn.
The tooling in a lot of languages and frameworks expects you to use an ORM, so a lot of the time you will have to put up a fair bit of upfront effort to just use Raw SQL (especially in .NET land).
On top of that ORM makes a lot of things that are super tedious like mapping to models extremely easy. The performance gains of writing SQL is very minor if the ORM is good.
I never worked at a FAANG-ish company, and in the course of my 10-year career I spent most of my efforts on stopping the organizations from building the wrong thing in the first place, not on "making things scaleable" from the get-go. My view is that if you have product-market fit, you can throw money on the problem for a very, very long time and do just fine, so everyone in the org should focus on achieving PMF as soon as possible.
The question of "How would you scale a Django service to 10M requests per day" came up, and my answer to just scale components vertically and purchase stronger servers obviously was not satisfactory.
Or at least it's not engaging with the obvious counterargument at all - that: "You may not need the scale now, but you may need it later". For a startup being a unicorn with a bajillion users is the only outcome that actually counts as success. It's the outcome they sell to their investors.
So sure, you can make a unscalable solution that works for the current moment. Most likely you wont need more. But that's only true b/c most startups don't end up unicorns. Most likely is you burn through their VC funding and fold
Okay stack overflow allegedly runs on a toaster, but most products don't fit that mold - and now that they're tied to their toaster it probably severely constrains what SO can do it terms of evolving their service
You're making two assumptions - both wrong:
1) That this is an unscalable solution - A monolith app server backed by Postgres can take you very very far. You can vertically scale by throwing more hardware at it, and you can horizontally scale, by just duplicating your monolith server behind a load-balancer.
2) That you actually know where your bottlenecks will be when you actually hit your target scale. When (if) you go from 1000 users to 10,000,000 users, you WILL be re-designing and re-architecting your solution regardless what you started with because at that point, you're going to have a different team, different use-cases, and therefore a different business.
Your solution is to basically do a re-write when scale becomes a problem. Which is the textbook example of something that sounds good but never works
On the other hand I can't think of a business that failed b/c it failed to scale :)
The final statement rarely is that they over-engineered it and this failed to build an interesting service.
I personally would suggest the vast majority of those startups do not need Kubernetes and certainly don't need to be paying a consultancy to then pay me to fix their issues for them.
You have an app which runs, now you want to put it in a container somewhere. Great. how do you build that container? Github actions. Great. How does that deploy your app to wherever it's running? Err... docker tag + docker push + ssh + docker pull + docker restart?
You've hit scale. You want redis now. How do you deploy that? Do you want redis, your machine, and your db in thre separate datacenters and to pay egress between all the services? Probably not, so you just want a little redis sidecar container... How does the app get the connection string for it?
When you're into home grown shim scripts which _are_ brittle and error prone, it's messy.K8s is a sledgehammer, but it's a sledgehammer that works. ECS is aws-only, and has its own fair share of warts. Cloud Run/Azure Container Apps are _great_ but there's nothing like those to run on DigitalOcean/Hetzner/whatever. So your choices are to use a big cloud with a simpler orchestartion, or use some sort of non-standard orchestration that you have to manage yourself, or just use k8s...
Once you have a service that has users and costs actual money, while you don’t need to make it a spaghetti of 100 software products, you need a bit of redundancy at each layer — backend, frontend, databases, background jobs — so that you don’t end up in a catastrophic failure mode each time some piece of software decides to barf.
I mean it will happen regardless just from the side effects of complexity. With a simpler system you can at least save on maintenance and overhead.
Absolutely spot-on site. Love it.
I recently had to work with SQL again after many years, and was appalled at the incidental complexity and ridiculous limitations. Who in this century would still voluntarily do in-band database commands mixed with user-supplied data? Also, the restrictions on column naming mean that you pretty much have to use some kind of ORM mapping, you can't just store your data. That means an entire layer of code that your application doesn't really need, just to adapt to a non-standard from the 70s.
"just use postgres" is not good advice.
Now every system design interview expects you to build some monstrous stack with layers of caching and databases for a hypothetical 1M DAU (daily active users) app.
Mess in the head.
Except it's really a "What over-engineered monstrosity have you built?" in the theme of "choose boring technology"
p.s. MariaDB (MySQL fork) is technically older and more boring than PostgreSQL so they're both equally valid choices. Best choice is ultimately whatever you're most familiar with.
PostgreSQL from 1996, based on Postgres95 from 1995, based on POSTGRES from 1989, based on INGRES from 1974(?).
I wonder if any lines of 1970's or at least 1980's code still survive in some corner of the PostgeSQL code base or if everything has been rewritten at least once by now? Must have started out in K&R C, if it was even C?
Somewhere there's a CVS repository with some history from before the import into the current repository, but unfortunately there's a few years missing between that repository and the initial import. I've not done the work to analyze whether any lines from that historical repo still survive.
In almost any other scenario I feel the author is being intentionally obtuse about much of the reality surrounding technology decisions. An engineer operating a linux box running postgres & redis (or working in an environment with this approach) would become increasingly irrelevant & would certainly earn far less than the engineer operating the other. An engineering department following "complexity is not a virtue" would either struggle to hire or employ engineers considered up-to-date in 2006.
Management & EXCO would also have different incentives, in my limited observations I would say that middle and upper management are incentivised to increase the importance of thier respective verticals either in terms of headcount, budget or tech stack.
Both examples achieve a similar outcome except one is : scalable, fault tolerant, automated and the other is at best a VM at Hetzner that would be swiftly replaced should it have any importance to the org, the main argument here (and in the wild) seems to be "but its haaaard" or "I dont want to keep up with the tech"
KISS has a place and I certainly appreciate it in the software I use and operating systems I prefer but lets take a moment to consider the other folks in the industry who aren't happy to babysit a VM until they retire (or become redundant) before dispensing blanket advice like we are all at a 2018 ted talk . Thanks for coming to my ted talk
To be fair, it's hard to imagine economy and civilization crashing hard enough to force us to be more efficient. But who knows.
That diagram is just aws, programming language, database. For some reason hadoop I guess. And riak/openstack as redundant.
It just seems like pretty standard stuff with some seemingly small extra parts because that make me think that someone on the team was familiar with something like ruby, so they used that instead of using java.
"Why is Redis talking to MongoDB" It isn't.
"Why do you even use MongoDB" Because that's the only database there, and nosql schemaless solutions are faster to get started... because you don't have to specify a schema. It's not something I would ever choose, but there is a reason for it.
"Let's talk about scale" Let's not, because other than hadoop, these are all valid solutions for projects that don't prioritize scale. Things like a distributed system aren't just about technology, but also data design that aren't that difficult to do and are useful for reasons other thant performance.
"Your deployment strategy" Honestly, even 15 microservices and 8 databases (assuming that it's really 2 databases across multiple envs) aren't that bad. If they are small and can be put on one single server, they can be reproduced for dev/testing purposes without all the networking cruft that devops can spend their time dealing with.
Sure, they aren't bad. They're horrible.
I was there before 10 years ago. I remember the pain in the ass that was hosting your own web server and own hardware, dealing with networking issues with cisco switches and thinking about getting a ccna. I remember the days of trying to figure out php and ranodm ass modules or how python and wsgi fit together on a slow ass windows machine instead of just spinning up an app and doing network calls using a spa.
Have you guys just forgotten all the enterprise crap that existed? Have you guys forgotten before that how things like compilers (ones you had to pay exorbintant amounts of money for) and different architectures were the headaches?
It's been two steps forward, one steps back, but we're still way better off.
Yes, people bring in k8s because they want to resume build and it goes poorly, but I've also used k8s in my personal setup that was much easier than the poor man's version I had of it.
All of this is just rose-tinted glasses, and people throwing the baby out with the bathwater. Just because some people have bad experiences with microservices because people don't often do them right, people just write them off completely.
I personally don't care for it and if I design something I make it so it avoids that stuff if I can at all help it. But I've come to see that it can have real value.
The thing is though, that then you really need someone to be that very competent ops person. If you're a grug like me, you don't get many shots to be good at something. I probably don't have the years in me to be good at both ops and "pure" programming.
So if you are a startup and you're not some kind of not only very smart but smart, fast and with taste, maybe pick your battles.
If you are great at the ops side, ok, maybe design it from that perspective and hire a bunch of not-made-of-unobtainium regular middle-of-the-road coders to fill in what the microservices and stuff should contain and manage those. This requires money for a regular hiring budget. (Or you are supersmart and productive and "play pretend enterprise" with all roles yourself. But I have never seen such a person.)
Or focus on a tight design which can run without any of that, if you come more from the "I'm making a single program" part of the world.
Tinkering syndrome can strike in any kind of design, so you need personal maturity whatever path you choose.
Clown fiesta.
Which is the exact point the article is making. You don't have scale. You don't need to optimize for scale. Just use Postgres on its own, and it'll handle the scale you need fine.
As opposed to what? Not doing anything at all and participating in this insanity of complexity?