81–90 of 130 posts
So many companies shoot themselves in the foot chasing Google/Meta/Netflix backend architectures. If your developer count is in the 10s, you are committing professional negligence chasing a microservices architecture.
Many may know it but for those that don't: Enjoy https://www.youtube.com/watch?v=y8OnoxKotPQ
Earlier quoted context omitted.
> something that different teams can work on without stepping on each other's foot In other words, different teams don't want to talk to one another. That's not really a good reason for having 'micro' services. You can also self-heal monoliths. In fact, it's much easier to do that with a monolith.
Talking and synchronizing dependencies, tools, and releases are different things.
> synchronizing dependencies, tools, and releases
Earlier quoted context omitted.
You can scale monoliths independently too. Depending on the language that means paying some additional memory overhead for unused code but practically it's small compared to the typical amount of ram on a server these days.
Please elaborate on that. Without spawning a new monolith, how do you scale it. Add more resources?
Earlier quoted context omitted.
The thing is they are not harmful, they are valuable above a certain scale. To caricature, monoliths scale with O(n) and microservices O(nlogn). At some point the lines cross and microservices start to get better. The problem is there's no clear answer to where is that point as it also depends on the product being built and other company specifics. But I wouldn't see it being usually worthwhile below a hundred devs.
Your analogy is backwards, nlogn > n.
I believe what the original poster meant to say was microservices grow like O(klogn) and monoliths O(n), i.e. microservices have some upfront constant cost that is large enough that, for small projects, monoliths will still perform adequately and be cheaper to develop and deploy. Once you exceed n large enough to overcome that upfront constant cost, microservices become the superior option.
I'm not agreeing or disagreeing with this, by the way.
Earlier quoted context omitted.
You can scale monoliths independently too. Depending on the language that means paying some additional memory overhead for unused code but practically it's small compared to the typical amount of ram on a server these days.
Please elaborate on that. Without spawning a new monolith, how do you scale it. Add more resources?
I find this highly misleading, Facebook is famously a big monolith, and I think so is instagram. There’s plenty of services and a couple micro services as well, but I don’t think anybody would characterize meta as having a micro services architecture. I have no idea what the authors’ agendas are, but something isn’t right there.
Earlier quoted context omitted.
Please elaborate on that. Without spawning a new monolith, how do you scale it. Add more resources?
You do spawn a new monolith. You make one group the CPU intensive one and route that traffic there. Same concept as a microservice except that it comes with a bunch of dead code. But the dead code is not that resource expensive these days.
I somewhat fail to see how that saves much effort; routing setup sounds like a hassle.
What we‘re using at my work is just a mono repo with all services in it, which works pretty well, and we‘re like 7 BE devs
Earlier quoted context omitted.
break, continue, and even goto in any language created in the last several decades cannot leave the current function. These are not what Dijkstra was talking about. Dijkstra wrote the piece when structured programming was just starting to become a thing and was urging people towards it. Think more like goto in BASIC, where there is no bridling of the operator.
Yes, however I am not sure if Dijkstra meant goto in the sense of jump outside of a function. I don't know enough about Algol 60 and languages of the time, but if you allow usage of goto between different functions you will have a corrupt stack in no time, so I'll be surprised if it was implemented. Going back to the original discussion, my point was that the only statements that are real gotos still in usage (except…
Except I posit that throw/catch still suffers the same problem he speaks of. It becomes difficult to follow when and where the code will jump to an arbitrary spot. The harmful parts of goto live on. Granted, we are learning. Modern languages are abandoning the throw/catch concept.
That’s too bad. One of the funnest thing is when a backend service calls into www, the monolith PHP code base. For example, callbacks when an item enters a queue or video call changes state. And by fun, I mean annoying to debug.
Earlier quoted context omitted.
> hence nowadays GOTO has practically a niche usage. Except where it was rebranded as throw/catch. There, goto remains quite popular. All while bridled (C-style) gotos were considered acceptable by Dijstrka, but are now looked upon with disdain. Amazing what a little marketing can do.
Throw is much worse than GOTO. GOTO is explicit you always know where it goes. Throw has no idea where catch is and catch has no idea where throw is. It's hidden control flow. Go/Rust/Zig Errors as values is a much better system forcing you to explicitly deal with the error, crash or pass it on. Rather than hoping you handled all the correct exceptions/someone else will handle all of them.