The paper, mentioned in the title, addresses the inherent challenges of the widely adopted microservices architecture in cloud computing, including performance bottlenecks, versioning issues, and increased complexity in application management. While microservices offer scalability, fault tolerance, and agile deployment, they also introduce significant overheads, making applications difficult to manage, reason about, and evolve.
The traditional architecture of splitting applications into microservices, while beneficial for scalability, performance, and fault tolerance, introduces significant challenges. These include performance degradation due to serialization and network overhead, complexity in managing multiple binaries and their release schedules, difficulty in ensuring application correctness due to interactions between microservices, and constraints on API evolution due to established contracts between services.
The paper introduces a programming model and runtime that allow developers to write distributed applications as single-binary modular monoliths, focusing solely on business logic.
This model encourages the logical separation of application components without conflating logical and physical boundaries.
A specialized runtime dynamically handles the physical distribution and execution of these components based on performance characteristics, thereby addressing the core challenges of microservices (C1-C5). This approach simplifies application management, enhances performance, and ensures atomic deployment without versioning conflicts.
I don’t have Google’s problems, and likely will never have them. And you are most likely in the same situation.
However, the modularity approach which is highlighted in the paper is an approach that I have followed for quite some time. I really like organising my code by two dimensions: bussiness logic and scale needs. The last one is mostly irrelevant, so I am only left with an organization based on what business the software needs to support.
My infrastructure is also very simple, I typically am totally covered with a single machine approach, without any Docker or any other similar tool. I just build my binary and ship it to the machine, restart the service it’s setup with and I’m done. This is all automated, either with GitHub Actions or some other way.
The details of the problem, solution space and the deep hows you can read about in the paper itself, which is available here.