Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What the hell have you built

wthhyb.sacha.house

Post reply on HN
Print view View original

91–100 of 239 posts

Re: What the hell have you built

#91

Post by isodev »

This 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 :).

Re: What the hell have you built

#92

Post by Treegarden »

pjc50 wrote: post #62
Treegarden wrote: post #33

Earlier quoted context omitted.

I dont quite follow. I understand mono vs micro services, and in the last 3 weeks I had to study for system design and do the interviews to get offers. Its a tradeoff, and the system design interview is meant to see if one understands how systems can scale to hypothetical (maybe unrealistic) high loads. In this context the only reason for a microservice is independent scaling and with that also fault tolerance if an…

In practice, it seems not to be a tradeoff but an ideology. Largely because you can't measure the counter-factual of building the app the other way. 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…

I dont disagree, but you can horizontally scale a monolith too, no? So scaling vert vs horiz is independent of microservices, its just that separating services allows you to be precise with your scaling. Ie you can scale up a compute heavy micorservice by 100x, the upload service by 10x but keep the user service at low scale. I agree that one can vert scale, why not. And I also agree that there are probably big microservices. At my last workplace, we also had people very bullish on microservices but for bad reasons and it didn't make sense, ie ideology.

Re: What the hell have you built

#93

Post by omnicognate »

9dev wrote: post #81

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: 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 appli…

Conway's Law:

> Organizations which design systems... are constrained to produce designs which are copies of the communication structures of these organizations.

Re: What the hell have you built

#94

Post by Freak_NL »

9dev wrote: post #81

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: 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 appli…

> You want a CI pipeline, so the junior developer can't just break prod because they forgot to run the tests before pushing.

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.

Re: What the hell have you built

#95

Post by buzzardbait »

The 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?"

Re: What the hell have you built

#96

Post by sjamaan »

pjmlp wrote: post #64

An 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 fro…

This 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.

Re: What the hell have you built

#97

Post by contrarian1234 »

I 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

Re: What the hell have you built

#98

Post by jwr »

While 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.

Re: What the hell have you built

#100

Post by StarGrit »

Hendrikto wrote: post #77
StarGrit wrote: post #48

Earlier quoted context omitted.

ORMs 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.

You 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.

You 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.

Post reply on HN