Towards Modern Development of Cloud Applications - a paper
published on 2024/01/22
However, splitting applications into independently deployable microservices is not without its challenges, some of which directly contradict the benefits.
C1: It hurts performance. The overhead of serializing data and sending it across the network is increasingly becoming a bottleneck. When developers over-split their applications, these overheads compound.
C2: It hurts correctness. It is extremely challenging to reason about the interactions between every deployed version of every microservice. In a case study of over 100 catastrophic failures of eight widely used systems, two-thirds of failures were caused by the interactions between multiple versions of a system.
C3: It is hard to manage. Rather than having a single binary to build, test, and deploy, developers have to managed different binaries, each on their own release schedule. Running end-to-end tests with a local instance of the application becomes an engineering feat.
C4: It freezes APIs. Once a microservice establishes an API, it becomes hard to change without breaking the other services that consume the API. Legacy APIs linger around, and new APIs are patched on top.
C5: It slows down application development. When making changes that affect multiple microservices, developers cannot implement and deploy the changes atomically. They have to carefully plan how to introduce the change across 𝑛 microservices with their own release schedules.
This paper from Google engineers is worth reading in full.
When writing a distributed application, conventional wisdom says to split your application into separate services that can be rolled out independently. This approach is well-intentioned, but a microservices-based architecture like this often backfires, introducing challenges that counteract the benefits the architecture tries to achieve. Fundamentally, this is because microservices conflate logical boundaries (how code is written) with physical boundaries (how code is deployed).
This is exactly why we use Microsoft Orleans. It allows our application to scale without doing the low level plumbing on how each part of the services need to interact.