8 ms·
What the hell have you built
- sachahjkl 11mo agoFrom the titular tweet (12 years already !): https://x.com/codinghorror/status/347070841059692545 https://x.com/codinghorror/status/347070841059692545
- danslo 11mo agos/postgres/sqlite/g
- sachahjkl 11mo agoback in the day, the hype was all arround postgres, but I agree
- anonzzzies 11mo agoYeah, we run a fairly busy systems on sqlite + litestream. It's not a big deal if they ae down for a bit (never happened though) so they don't need failover and we never had issues (after some sqlite pragma and BUSY code tweaking). Vastly simpler than running + maintaining postgres/mysql. Of course, everything has it's place and we run those too, but just saying that not many people/companies need them really. (Also considering that we see system which DO have postgres/mysql/oracle/mssql set up in HA and still go down for hours do a day per year anyway so what's it all good for).
- rcarmo 11mo agoThis. So much this. Of course, at one point you start wanting to do queues, and concurrent jobs, and not even WAL mode and a single writer approach can cut it, but if you've reached that point then usually you a) are in that "this is a good problem to have" scalability curve, and b) you can just switch to Postgres. I've built pretty scalable things using nothing but Python, Celery and Postgres (that usually started as asyncio queues and sqlite).
- forgetfulness 11mo agoA queue and a database are more shots on the architecture golf though.
- hshdhdhehd 11mo agoPostgres is simpler. Get your cloud to manage it. Click to create instance, get failover with zero setup. Click button 2 to get guaranteed backups and snapshot point in time.
- 1718627440 11mo agoWhen you use sqlite, you can distribute your program by distributing a single executable file. That's what I call simple.
- hshdhdhehd 11mo agoYes that is simple, especially for a desktop app. 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?
- 1718627440 11mo agoI was especially thinking about a program running on a server. I wouldn't statically link everything for a desktop program, because it just causes incompatibilities left-and-right. But for a server, you don't have external vendors, so this is a good option, and if you use SQLite as the database, then this means that deploying is not more complicated than uploading a single executable and this is also something, that can be done atomically. 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.
- Komte 11mo agoDon't agree. Getting managed postgress from one of the myriad providers is not much harder than using sqlite, but postgress is more flexible and future proof.
- ErroneousBosh 11mo agoI use Postgres for pretty much everything once I get beyond "text in a database with a foreign key to a couple of things". 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.
- eskibars 11mo agoIsn't the entire point of this post that many companies opt for flexible+future proof far too prematurely?
- StarGrit 11mo agoORMs have better support I've found in the past (at least in .NET and Go) for Postgres. Especially around date types, UUIDs and JSON fields IIRC.
- Hendrikto 11mo agoYou don’t need an ORM either. It’s just another level of complexity for very little to no gain in almost all cases. Just write SQL.
- StarGrit 11mo agoYou always get a comment like this. I don't particularly agree. There are pros and cons to either approach 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.
- juangacovas 11mo agoNah, postgres is overhyped, MariaDB is enough and recently: <https://mariadb.org/mariadb-vs-postgresql-understanding-the-architectural-differences-that-matter/ https://mariadb.org/mariadb-vs-postgresql-understanding-the-...>
- stavros 11mo agoI love this comment because it misses the point in exactly the way the article talks about.
- n4r9 11mo agoBut what if all 12 users log in 100 times during the same second of the day?
- stavros 11mo agoIt's a reasonable worry!
- Asraelite 11mo agoNo it doesn't. The fact that the article had to say "Maybe Redis for caching" because Postgres can't handle caching at scale shows that Postgres is not a perfect solution. Choosing an alternative database that can do everything you need means simplifying your architecture in the spirit of the article (not to say that MariaDB specifically is the right choice here, I'm not familiar enough with it to comment on that).
- stavros 11mo ago> because Postgres can't handle caching at scale 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.
- juangacovas 11mo agoLove the downvotes ;P
- brap 11mo agoI feel like sometimes it’s a form of procrastination. 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).
- marfmarkus 11mo agoIt's the natural evolution to becoming a fun addict. 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.
- ErroneousBosh 11mo agoYou know what, you're right. 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.
- moritzwarhier 11mo agoI see your point. But accidental complexity is the most uncomfortable work there is to me. Do programmers really find so much fun in creating accidental complexity? 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 :)
- preommr 11mo agoWhat the hell have you built? Turns out a pretty straightforward service. 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.
- JSR_FDED 11mo agoWhoosh
- whstl 11mo ago> Honestly, even 15 microservices and 8 databases (assuming that it's really 2 databases across multiple envs) aren't that bad Sure, they aren't bad. They're horrible.
- lwn 11mo agoThis comment makes this thread a great time capsule. Given that the website is now over 10 years old, it perfectly illustrates how much 'best practices' and architectural complexity (and cloud bills) have changed since then.
- preommr 11mo agoNo no, don't give me this. 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.
- WesolyKubeczek 11mo agoHeh 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.
- blkhawk 11mo agouh, maybe you only have the issue that you need redundancies because you have so many pieces of software that can 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.
- WesolyKubeczek 11mo agoYes, but if your web server goes down for whatever reason, you’d rather have some more for your load balancer to round robin. Things like physical host dying are not exactly unheard of. Same with DB, once you take money, you want that replication and quick failover and offsite backup.
- paulbjensen 11mo agoOh my word Riak - I haven't seen that DB mentioned for years! 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.
- auxiliarymoose 11mo agoI think remote climate controls in a car are an ideal use-case for a simpler architecture. 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.
- d--b 11mo agoYet the author spent a whole afternoon (hopefully not more!) writing a website to tell some people (who exactly?) that they’re doing it wrong.
- DrewADesign 11mo agoYeah, but the building phase of an overly complex system is rarely the big time suck: maintaining and modifying it are.
- fouc 11mo agoit's a web page on a subdomain of his existing personal website, so probably didn't take him much time at all, probably about as fast as it would take to write up the text in a word document and then farting around with the styling and javascript a bit.
- wiseowise 11mo ago> Yet the author spent a whole afternoon As opposed to what? Not doing anything at all and participating in this insanity of complexity?
- lifestyleguru 11mo agoAre you doing software for money? Because not having Kubernetes in the project will stop you from receiving money. Someone please create with one of these smart AI tools the ultimate killer app: Kubernetes+crypto+AI+blockchain+Angular+Redux+Azure (Working only in Chrome browser).
- hhh 11mo agoyeah because kubernetes for most people isn't actually difficult and its complexity is overblown unless you are faang scale
- adithyassekhar 11mo agoRedux catching strays. RTK is fine.
- officialchicken 11mo agoThat's already a preset in claude - use the /reddit-recommends-stack command. It doesn't bother to understand and modify your existing code, just completely rewrites it every time for speed and ease of vibe.
- cpursley 11mo ago12 years later and Postgres is (still) Enough and getting better by the day: https://gist.github.com/cpursley/c8fb81fe8a7e5df038158bdfe0f06dbb https://gist.github.com/cpursley/c8fb81fe8a7e5df038158bdfe0f...
- wewewedxfgdf 11mo ago"Maybe Redis for caching". 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.
- vlovich123 11mo agoPostgres has support for an eventually consistent in-memory caching layer?
- wewewedxfgdf 11mo agoHa ha nice one - when your startup is Facebook you'll need that, not for your 12 users. 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"?
- deleted 11mo ago[deleted]
- yencabulator 11mo agoWhy would it need to be eventually consistent when it's a single server? https://www.postgresql.org/docs/18/sql-createtable.html#SQL-CREATETABLE-UNLOGGED https://www.postgresql.org/docs/18/sql-createtable.html#SQL-...
- douglee650 11mo ago"Why is Redis talking to MongoDB?" lol, In the diagram, Redis is not even talking with MongoDB
- rf15 11mo ago
- remco_sch 11mo agoI love the unnecessary buttons that do nothing :)
- zargath 11mo agoyou guys are going to miss the days of over-engineered microservice solutions when you are debugging ai workflows :)
- lifestyleguru 11mo agoIt's like debugging the code of that guy who wrote most of the project, was consuming entire coffee in the office, outtalked everyone at the meetings, and then relocated for a new job to Zurich or London.
- fredsted 11mo agoCDD, or CV-driven development, as I like to call it.
- deleted 11mo ago[deleted]
- Copenjin 11mo agoThinking is scary. No one (among non-thinking colleagues) is going to criticize you for using de-facto standard services like kafka, mongo, redis, ecc... regardless of the nonsensical architecture you come up with. 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.
- kiesel 11mo agoI love the fact that the author "wrote" this page with massive CSS framework (tailwind) and some sort of Javascript framework, with a bundler and obfuscator - instead of a plain, simple HTML page. Well played! :-)
- draw_down 11mo ago[dead]
- Bengalilol 11mo agoReact + Tailwind + bundler + googlefont + ... Yeah, humans are paradoxical
- sachahjkl 11mo agogood point, got rid of google font. for the rest, it's just that the DX is unmatched to get something quick and dirty started up. (I _could_ have done a simple .html though). and I'll concede that react is overkill for this, I just wanted components + typescript to not waste time on silly vanilla js bugs
- SpikeMeister 11mo agoFair, the author's point would have been stronger if the page was made using just static HTML/CSS. 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.
- mb2100 11mo agohaha, right?! I'm totally onboard with the author's philosophy, hence for websites: https://mastrojs.github.io https://mastrojs.github.io – the simple web framework and site generator you could have built yourself.
- alansaber 11mo agoAs a practitioner we subconciously optimise for "beauty", in maths, physics or dev. Most hackers are self-motivated, by that beauty, not by 40k ork style functional design.
- cube00 11mo agoBlame the C-suite who approve embedding AWS solution designers into teams.
- s1mplicissimus 11mo agoIronic that the clicking those big buttons only causes a JS error to be logged to console with nothing else happening. That doesn't particularly lend to the authors credibility, although the advice of using simple architecture where possible is correct.
- zelphirkalt 11mo agoAh I didn't even check for an error. I thought it was a joke, that the buttons do nothing, because what are they gonna do anyway, I am merely reading an article, lol.
- jgoode19 11mo ago[dead]
- pjmlp 11mo agoAn improved CV, lets be honest most stuff is boring projects that could even be built with 1990's technology, distributed systems is not something that was invented yesterday. 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.
- damethos 11mo agoThis comment sums up my view as well, but I must confess that I’ve designed architectures more complex than necessary more than once, just to try new things and compare them with what I already knew. I just had to know!
- sjamaan 11mo agoThis is also how you can identify decent places to work at: look for job postings that emphasize you aren't expected to already know the language. 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.
- darkwater 11mo agoTo do that you need a mixture of elements: work in a somehow "exotic" language [1] and the company can afford to pay top-talent salary [2] [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.
- estsauver 11mo agoI built a small simple page that I send to people when they start proposing crazy db architectures that people might like if they like this page: https://nocommasql.com/ https://nocommasql.com/
- damethos 11mo agoUseful, but 10 years ago without JSONB in PG it wasn't really the answer to everything. But as of today, I am recommending PG to anyone that does not have a good reason or use case to NOT use it.
- hu3 11mo agojust a nit. it pollutes back button history when I expand content. took 9 presses of back button to return to HN.
- nilsherzig 11mo agoBut that’s half the fun (and knowledge about these systems got me my current job)
- littlestymaar 11mo agoThe problem with doing things the sensible way (eschewing microservices and k8s when you work on projects that aren't hyperscale) is that you end up missing opportunities later on because recruiters will filter you because you can't meaningfully respond to the question about “how experienced you are with micro service architecture”. Granted I may have dodged a bullet by not joining a company with 50 engineers that claim to replicate Google's practices (most of which are here to make sure tens of thousands of engineers can work efficiently together), but still someone gets to pay the bill at the end of the month…
- deleted 11mo ago[deleted]
- 9dev 11mo agoIt'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: You want straightforward, self-contained deployments for one, instead of uploading files onto your single server. If the process crashes or your harddisk dies, you want redundancy so even those twelve customers can still access the application. You want a CI pipeline, so the junior developer can't just break prod because they forgot to run the tests before pushing. You want proper secret management, so the database credentials aren't just accessible to everyone. 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. 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.
- omnicognate 11mo agoConway's Law: > Organizations which design systems... are constrained to produce designs which are copies of the communication structures of these organizations.
- whilenot-dev 11mo agoTell this to a company of 4 engineers that created a system with 40 microservices, deployed as one VM image, to be running on 1 machine.
- omnicognate 11mo agoLOL, perhaps the communication structure there was "silent, internalised turmoil".
- whilenot-dev 11mo agoProbably =), or Conway's law was always about the lower ends of the communication nodes in a company graph. I think it's time we also always include the upper ends of our cognitive limits of multitasking when we design systems in relation to organization structures.
- Panzerschrek 11mo agoJob security-driven development. It explains why some projects are unnecessary complex.
- fouc 11mo agoFunny, from the title I was expecting a productivity-adjacent "What have you even built?" article. 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.
- deleted 11mo ago[deleted]
- 1313ed01 11mo agoMariaDB from 2009, based on MySQL from 1995. 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?
- anarazel 11mo agoWe don't have the complete version history of postgres, so that's not easy to know. There definitely are still lines from Postgres95 that haven't been changed since the initial import into our repository. 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.
- ruperthair 11mo agoNot that oldness is much of a metric for quality, but Postgres does go quite a lot further back: https://en.wikipedia.org/wiki/PostgreSQL#Ingres_and_University_POSTGRES_(1982%E2%80%931994) https://en.wikipedia.org/wiki/PostgreSQL#Ingres_and_Universi...
- isodev 11mo agoThis kind of complexity is unfortunately also embedded into model training data. 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 :).
- buzzardbait 11mo agoThe alternative to CI/CD pipelines is to rely on human beings to perform the same repetitive actions the exact same way every single time without any mistakes. You would never convince me to accept that for any non-trivial project. Especially in an age where you can basically click a menu in GitHub and say "Hey, can I have a CI pipeline please?"
- arealaccount 11mo agoI think the 2 hours bit was the important part
- 1313ed01 11mo agoNo, the alternative is/was something like "make test" or "build_deploy_and_test.sh".
- contrarian1234 11mo agoI don't really get this line of argument 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
- macspoofing 11mo ago>So sure, you can make a unscalable solution that works for the current moment. 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.
- contrarian1234 11mo agoDo you have actual examples of this? 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 :)
- zelphirkalt 11mo agoBecause you never read about their failures like that. For users they might simply become not interesting, because they fail to deliver good features reliably, because, unbeknownst to the users, they are busy working on their scalable architecture all day. The final statement rarely is that they over-engineered it and this failed to build an interesting service.
- jwr 11mo agoWhile I agree with most of this rant, I have a problem with the common "just use postgres" trope, often repeated here. 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.
- r0x0r007 11mo ago"just use postgres" is an excellent advice. How about incidental complexity and ridiculous limitations of an ORM? Time spent learning how to use an ORM can better be spent 'refreshing' your SQL knowledge. Also, when you learn how an ORM works, you still don't know proper SQL nor how do databases works, so when you switch language now what, you quickly take a course on another ORM? SQL is a language, ORM is not,it's just ' an entire layer of code that your application doesn't really need' and in some applications you could never ever use an ORM.
- jwr 11mo agoIt is rather clear that I am the only one in this discussion who recently had to write code that synchronizes data that I do not control with an SQL database. Everything is easy in toy applications, where you have your USERS table with First_Name and Last_Name.
- mike_kamau 11mo agoI agree 100%. "Complexity is not a virtue. Start simple. Add complexity only when you have proof you need it."
- admissionsguy 11mo agoIs there any good reason to switch from mysql to postgres though?
- dvt 11mo agoThe fact that we have lambdas/serverless functions and people are still over-engineering k8s clusters for their "startup project" is genuinely hilarious. You can literally validate your idea with some janky Python code and like 20 bucks a month. 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.
- mewpmewp2 11mo agoThe problem is job interviews, where you are expected to know how to scale everything reliably, so it wouldn't be satisfactory to answer that just have a monolith against a postgres instance.
- redshiftza 11mo agoIs this targeted at startup bros with an MVP and a dream ? 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
- stereolambda 11mo agoWhile you you're making good points, this shows that engineers and industry intentionally make work more complex than necessary in order to justify higher prices for labor. This is not so uncommon in today's economy, especially white collar and regulated work that most people don't understand, but worth thinking about regardless. To be fair, it's hard to imagine economy and civilization crashing hard enough to force us to be more efficient. But who knows.
- zhisme 11mo agoTotally agree. 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.
- qustrolabe 11mo agoJob offers require experience in technologies that you won't ever need building solo project. I'm not surprised when those big scale technologies get shoehorned into small project for the sake of learning, showcasing "look I know that one" etc. Only totally missing this point could explain why someone would make this hyperbole rant page
- supermatt 11mo agoOr build your microservices as a monolith using a “local” async service mesh (no libs or boilerplate needed, its just an async interface for each service) and service namespaced tables in your DB, then just swap in a distributed transport on a per-case basis if you ever need to scale.
- Havoc 11mo ago> Add complexity only when you have proof you need it. 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
- flurdy 11mo ago12 years on, and a lot of Postgres-based services built since the OP site first went live, I now actually may recommend MongoDB as the sensible option...
- eddie_catflap 11mo agoI had a call the other day with a consultancy to potentially pick up some infrastructure work/project type stuff. Asked about timezones involved and they said a lot of their clientele are US based startups. "So it's mainly Kubernetes work" they said. 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.
- maccard 11mo agoThe problem with kubernetes is that containers just aren't quite enough. 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...
- arbol 11mo agoRecently, with the AWS outage, our stack of loads of different cloud providers ended up working pretty well! It might be a bit complex running distributed nodes and updating state via API, but its cheap and clearly resilient.
- deified 11mo agoThere is an argument I rarely ever see in discussions like this, which is about reducing the need for working memory in humans. I'm just in the mid thirties, but my ability to keep things in working memory is vastly reduced compared to my twenties. Might just be me who's not cut out for programming or system architecturing, but in my experience what is hard for me is often what is hard for others, they just either don't think about it or ignore it and push through keeping hidden costs alive. 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.
- jagraff 11mo agoThis is a good point - having your code broken up into standalone units that can fit into working memory has real benefits to the coder. I think especially with the rise of coding agents (which, like it or not, are here to stay and are likely going to increase in use over time), sections of code that can fit in a context window cleanly will be much more amenable to manipulation by LLMs and require less human oversight to modify, which may be super useful for companies that want to move faster than the speed of human programming will allow.
- lunias 11mo agoThe damages of micro-services, cloud-scale, and a bunch of enterprise architects that have done nothing for 10 years but read blogs (advertisements) written by other enterprise architects that just got back from watching demos at a conference. Absolutely spot-on site. Love it.
- tmarice 11mo agoVery relatable to a recent interview experience I had with a popular freelance platform for the backend developer position. 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.
- ericzundel 11mo agoI'm going through this decision right now. I agree, you are building a product with an unproven market and lots of time to grow organically, maybe you do want to start small and scrappy. Build something you can easily throw away and start over with. Build something that gets you to market as quickly as possible so you can pivot. 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.)