Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- Microservices can trample on each other just as easily as monolith internals can. If anything, the friction of reconciling changes in a monolith is useful signal that conflicting changes happened, and it takes slow and flaky e2e tests to replicate in microservices. It's not like you're resolving the merge conflicts by hand.
- I don't understand why microservices would have fewer merge conflicts than monoliths.by HWR_14
- > So Uber’s approach to modularity may have seemed extreme at the time, but it could become the new normal.
I doubt it. This seems to conflate code modularity with service modularity. Moving complexity from the codebase into operations is counterintuitive to at least the way I use LLMs.
by fhub - How would the LLMs even appropriately build and manage context in such a setting?by ch4s3
- Funny take. Monoliths are actually better then microservices because of the context they carry. At the end developers are supposed to run a product, not to keep mindlessly running agents just because they can
- > If you have a large monolithic service where every change has to be coordinated carefully..
Microservices are WAY harder to coordinate for deployments. You end up with feature service dependencies, and you are back to the same coordination, but now harder to discover down stream dependencies..
by layoric - Totally agree. And having a Rails monolith that the LLM can see the entire context - even our marketing landing pages - is a blessing in AI era.by pqdbr
- I think microservices are supposed to be easier to deploy independently, that's the whole point. And if they are not, it means you're just doing it wrong.
But in truth, all the projects with microservices I have seen in real life had deployment coordination problems, and looked to me like distributed monoliths. So maybe it's a 'no true scotsman' thing. Maybe they are always, or at least most of the time, harder.
Makes it harder to justify using them.
by lucianbr - I saw the `require('gulp')` and the memories def came back. That's def how we used to do code ~10 years ago. I still don't like the multi-threaded PER PROJECT too much, I prefer having 2 projects and switching context window, I find the current tools (at least the ones I know) are a bit underwhelming for multi-threading. But I'm also trying to upgrade my knowledge.
A good way I've found, since I do a lot of OSS and have my own libraries, when I find a bug in one of those libraries I can work on the same project on the main window while fixing the library on another window. I normally need to tell the main one "let's skip this for now, I'm fixing the library" meanwhile or similarly.
by franciscop - > find the current tools (at least the ones I know) are a bit underwhelming for multi-threading
Have you tried t3 code? It creates a separate worktree per agent, which makes running multiple agents at once much easier.
by openfront - I hope people don't call automations as "teams". If you are calling it a team just because it "does" work, then CPU cores and threads are also a team, though not so probabilistic (intelligent). They do get the work done.by zkmon
- I want to agree with the sentiment. Then again, OpenMP has in fact used the term "team" in the this kind of sense for a long time.by atq2119
- I'm really skeptical you can ship ~10 PRs a day per person unless these PRs are tiny pieces of one feature or all of them are tiny bugs that are each a 3 line fix that you could review instantly. Otherwise how can you confirm that the AI even did the right fix or feature correctly? That you even wanted that feature done that way?by _345
- I really don't think they can. I feel like if I rush a PR using AI, I can only just kinda hope the AI is good enough that my trust isn't misplaced. It becomes slightly less likely to be bad if you add a thorough AI review on top but it's just rolling the dice.by squibonpig
- Pretty sure Uber ended up with thousands of microservices because they used to tie owning a service to perf and promo, and were trying to cut down the number for years. It's hilarious to see this interpreted as an intentional choice.
- used to work for a company and this is exactly what happened, each team lead pushed for their own little secret garden and fight over who had to add new things. Managing the kafka instance(s) to keep order turned into 2 people's full time jobs. They sold at absolute fire sale price not long agoby the_sleaze_
- I have already commented about this is probably the worst advice I have heard in a long time, and I would definitely not let this guy anywhere near a codebase I had to maintain.
But this is also essentially blogspam. The author intentionally includes two screenshots which add absolutely nothing to their point and which are too small to read. When you click the second one, you are not taken to a larger version, you are taken to the frontpage of his company website which features the same screenshot.
- Wait two years until we have sufficient churn of senior talent in the teams. Then all of the services will have outages daily.
Only the seniors who know their systems are keeping the lights on today by keeping bs commits out.
Once they burnout and quit, nobody will have a freaking clue what the LLMs have done and why services are down.
by whatever1 - This argument comes up during every big layoff season. A good chunk of people pronounced Twitter dead when it got bought out. But software nowadays is pretty stable, despite its perceived jankiness.by tokioyoyo
- I would take the other side of that bet. In five years, there won’t be more outages than today.by fra
- The answer to all the questions, though, is more AI/LLM usage. Nobody got a freaking clue what the LLMs have done and why services are down? Diagnose it with LLM, and get the lights back on ASAP!
I have a similar concern, though. To do my job, I need to understand "the thing". I could outsource the understanding process to AI, but then if I'm asked a question by a developer or tester then I'm essentially stumped / useless because I didn't spend the time to understand the thing, I handballed it.
So I then ask the LLM the question I was asked, and pass the answer back (they could have done this themselves though, so where does that leave me? I'm either an AI wrangler, or replaced by someone else who wrangles AI replacing mutliple people in my role). Does my personally understanding the thing actually add value - do the seniors who know their systems add value - in the age of AI/LLM?
Does "LLMs all the way down" solve the problems?
With the existence of hallucinations I lean towards 'no', but again is that solved by adding layer(s) of LLMs to check for hallucinations?
by BLKNSLVR - You can already see a practical example of this in microsoft's issues with Azure. Too many services, too little understanding, everyone left who knows what is going on. There was an interesting article here a little while ago by one of the architects something like "how azure set a trillion dollars on fire" or something like that.by jaggederest
- A wise troll once said:
> best weapon against complexity spirit demon is magic word: "no"
In counterpoint, I believe small teams can remain small. Small teams can ship simple monoliths with high velocity, commit count, and quality. Service orientation didn’t suddenly become low-cost because of agents; the boundaries between multiple services that version and deploy independently are still tricky beasts to wrangle. And it’s not clear why “running more agents” is inherently desirable or impactful; my small team’s (admittedly anecdotal) experience is that the value quickly saturates.
by davepeck - Agent spam is definitely an excercise in diminishing returnsby alansaber
- Hundreds of bots modifying thousands of microservices may sound good on the surface, but all those thousands of microservices make up an architecture and a product.
Agents aren't very good at carrying the entire model in their context, so when they reason about a small piece of code, they often come up with something that hurts other parts of the code (especially as the KLOCs pile up). The complexity hasn't been replaced, only moved. And guess what's going to happen when all of these microservices become even more of a moving target than they already are?
AI is capable of improving productivity, but this approach sounds more like a nightmare in the making.
by kstenerud - Why do you need to always modify the service? Once it is up and running and performs a function - don't touch it.by john_minsk
- I used to say my job was „managing complexity“, not being a programmer. After AI, thats still true because they suck at it.
- It doesnt sound good at all!
10 people generating 800 commits a day is completely stupid.
I mean at this stage people don’t even know what they’re building anymore. They’ll burn through their backlog faster than the backlog can be filled.
Or maybe they spend 700 commits fixing the issues generated by the first 100?
This doesn’t make any sense to me
by d--b - >Hundreds of bots modifying thousands of microservices
That is way too close to monkeys on typewriters for comfort.
by ReptileMan - Imo there's zero difference between 'thousands of microservices' and 'one monolith with thousands of functions/classes/etc' in terms of effort required to make it correct - both are still tiny interconnected pieces making up a whole, and you can separately unit test a function just as easily as you can separately e2e test a single microservice.
They still make up some whole product that presumably does something as a whole that you actually care about, and the complexity inherent to that doesn't go away with either approach.
by p1necone