使用LLM编程是否意味着更多的微服务?
Does coding with LLMs mean more microservices?

原始链接: https://ben.page/microservices

大型语言模型辅助编码的兴起,无意中推动了向微服务架构的转变。因为微服务具有明确定义的输入和输出(“契约”),大型语言模型可以在不影响系统其他部分的情况下,安全地进行大规模内部重构——本质上为实验创造了一个安全的“避难所”。 这与单体架构形成鲜明对比,单体架构中隐式的依赖和微妙的耦合会在代码更改期间造成风险。微服务也提供组织上的优势:更快的迭代速度,因为代码审查的严格程度降低,以及更容易访问生产数据/基础设施。 然而,这种激增也并非没有缺点。管理数十个独立的服务会给计费和资源跟踪等领域带来复杂性。尽管存在长期的维护挑战,微服务目前仍然是利用大型语言模型的开发人员“阻力最小的路径”,这凸显了在开发工作流程中简化和鼓励最佳实践的必要性。

一个 Hacker News 的讨论探讨了使用大型语言模型 (LLM) 编码的兴起是会导致更多还是更少微服务。核心论点围绕“受限表面积”——即 LLM 在较小、独立的的代码库中表现更好,因为存在上下文窗口的限制。 目前,这*可能*会促使开发者转向微服务,以便将代码适应这些限制。然而,一个关键的反驳观点认为,随着上下文窗口的扩大,这种压力可能会*逆转*。更大的窗口可以让 LLM 处理整个单体应用,从而提供隔离的好处,而无需分布式系统的运维复杂性。 评论者还指出,微服务主要解决*组织*层面的可扩展性问题,而不是技术限制,并且良好模块化的单体应用可以实现类似的好处。有些人甚至认为 LLM 实际上可能会*增加*单体应用的开发,并且可组合的 CLI 工具更适合 LLM 辅助编码。
相关文章

原文

Recently, at work, I’ve seen the beginnings of a proliferation of microservices. It seems that LLM-assisted coding naturally flows towards small microservices, which the big backend uses for specific tasks. For example, a microservice that handles image and video generation AI models.

A microservice has a very well-defined surface area. Everything that flows into the service (requests) and out (responses, webhooks) is defined explicitly. That means that you can let an LLM rip large-scale refactors inside of the service, and as long as the contract with the outside world remains the same, the inside does not matter. The microservice might have its own database, caches, and object storage, but the caller does not care. It’s a bomb shelter (within which you can detonate your Claude-shaped bomb).

When coding in a monolith, you have to worry about implicit coupling. The order in which you do things, or the name of a cache key, might be implicitly relied-upon by another part of the monolith. It’s a lot easier to cross boundaries and subtly entangle parts of the application. Of course, you might not do such unmaintainable things, but your coworkers might not be so pious.

A microservice has much less risk of coupling. Let Claude do whatever it wants, and the outside world doesn’t care as long as the service keeps behaving the same way.

From an organizational perspective, there’s additional reasons why a microservice can be the path of least resistance:

  1. Being in a separate GitHub repo, there’s less scrutiny on PR review (or you can commit straight to main), meaning you can iterate faster
  2. Production data and infrastructure can be much easier to access — often the main production database is hard for everyday engineers to connect to, but a microservice’s infrastructure isn’t deemed so critical to secure

A proliferation of microservices is probably worse and harder to maintain in the long term. When you have dozens of apps (all with their own billing accounts, hosting setups, and resources) it’s a lot easier to forget to renew that OpenAI API account that only your image-generation microservice hosted on Vercel uses.

But these microservices are where the path of least resistance flows. If you want better practices, you have to make it easier for people to achieve their desired outcomes using your desired best practices.

联系我们 contact @ memedata.com