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

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

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

相关文章

原文

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