Live data from Hacker News

Does coding with LLMs mean more microservices?

ben.page

21–30 of 73 posts

Re: Does coding with LLMs mean more microservices?

#21
post #10

That's an argument for components with well-defined contracts on their interfaces, but making them microservices just complicates debugging for the model. It's also unclear whether tight coupling is actually a problem when you can refactor this fast.

You are taking the article argument too literally. They meant microservices also in the sense of microlibraries, etc, not strictly a HTTP service.

No, I think you’re not reading it literally enough. “Microservices” generally does mean separate HTTP (or at least RPC) servers. Near the beginning, the article says:

A microservice has a very well-defined surface area. Everything that flows into the service (requests) and out (responses, webhooks)

Re: Does coding with LLMs mean more microservices?

#22
post #10

That's an argument for components with well-defined contracts on their interfaces, but making them microservices just complicates debugging for the model. It's also unclear whether tight coupling is actually a problem when you can refactor this fast.

You are taking the article argument too literally. They meant microservices also in the sense of microlibraries, etc, not strictly a HTTP service.

Why arbitrarily invent new meanings (for microservices) and new words (microlibraries) when there are already many adequate ways to describe modular, componentized architecures?

A totally valid and important point but it has been diluted by talking about microservices rather than importance of modular architectures for agent-based coding.

Re: Does coding with LLMs mean more microservices?

#23
I don't think LLMs push us to use microservices as much as Borgers says they do. They don't avoid the problems microservices have always faced, and encapsulation is mostly independent from whether a boundary is a service-to-service boundary:

https://www.natemeyvis.com/agentic-coding-and-microservices/

Re: Does coding with LLMs mean more microservices?

#24
I think this is a promise, probably also for spec driven development. You write the spec, the whole thing can be reimplemented in rust tomorrow. Make small modules or libraries.

One colleague describes monolith vs microservices as "the grass is greener of the other side".

In the end, having microservices is that that the release process becomes much harder. Every feature spans 3 services at least, with possible incompatibility between some of their versions. Precisely the work you cannot easily automate with LLMs.

Re: Does coding with LLMs mean more microservices?

#25

I don't think LLMs push us to use microservices as much as Borgers says they do. They don't avoid the problems microservices have always faced, and encapsulation is mostly independent from whether a boundary is a service-to-service boundary: https://www.natemeyvis.com/agentic-coding-and-microservices/

service-to-service boundary is easiest to keep with the way we are using LLMs to code right now

Re: Does coding with LLMs mean more microservices?

#27
post #9

What matters for LLMs is what matters for humans, which usually means DX. Most Microservice setups are extremely hard to debug across service boundaries, so I think in the future, we'll see more architectural decisions that make sense for LLMs to work with. Which will probably mean modular monoliths or something like that.

Aren't libraries just "services" without some transport layer / gateway?

You should only ever have a separate "service" if there's a concrete reason to. You should never have a "service" to make things simpler (it inherently does not).

Libraries on the other hand are much more subjective.

Re: Does coding with LLMs mean more microservices?

#28

Earlier quoted context omitted.

You are taking the article argument too literally. They meant microservices also in the sense of microlibraries, etc, not strictly a HTTP service.

No, I think you’re not reading it literally enough. “Microservices” generally does mean separate HTTP (or at least RPC) servers. Near the beginning, the article says: A microservice has a very well-defined surface area. Everything that flows into the service (requests) and out (responses, webhooks)

I think a better word would have been "modularization" than "microservices" as I also highly correlate "microservices" with http-based calls.

Re: Does coding with LLMs mean more microservices?

#29

Earlier quoted context omitted.

You are taking the article argument too literally. They meant microservices also in the sense of microlibraries, etc, not strictly a HTTP service.

Why arbitrarily invent new meanings (for microservices) and new words (microlibraries) when there are already many adequate ways to describe modular, componentized architecures? A totally valid and important point but it has been diluted by talking about microservices rather than importance of modular architectures for agent-based coding.

> describe modular,

Agreed. Modular is what they were probably after.

Re: Does coding with LLMs mean more microservices?

#30
post #10

That's an argument for components with well-defined contracts on their interfaces, but making them microservices just complicates debugging for the model. It's also unclear whether tight coupling is actually a problem when you can refactor this fast.

Whether you call it modularization, good design, SOLID principles, or micro services, etc. It all boils down to the same thing. I usually dumb it down to two easy to understeand metrics: cohesiveness and coupling. Something with high cohesiveness and low coupling tends to be small and easy to reason about.

Things that are small, can be easily replaced, fixed, changed, etc. with relatively low risk. Even if you have a monolith, you probably want to impose some structure on it. Whenever you get tight coupling and low cohesiveness in a system, it can become a problem spot.

Easy reasoning here directly translates into low token cost when reasoning. That's why it's beneficial to keep things that way also with LLMs. Bad design always had a cost. But with LLMs you can put a dollar cost on it.

My attitude with micro services is that it's a lot of heavy handed isolation where cheaper mechanisms could achieve much of the same effects. You can put things in a separate git repository and force all communication over the network. Or you can put code in different package and guard internal package cohesiveness and coupling a bit and use well defined interfaces to call a functions through. Same net result from a design point of view but one is a bit cheaper to call and whole lot less hassle and overhead. IMHO people do micro-services mostly for the wrong reasons: organizational convenience vs. actual benefits in terms of minimizing resource usage and optimizing for that.

Post reply on HN