This interesting paper advises on an alternate architecture for cloud applications. It starts out by listing some drawbacks of Microservices:
- C1:It hurts performance. The overhead of serializingdata and sending it across the network is increasinglybecoming a bottleneck [72]. When developers over-split their applications, these overheads compound [55].
- C2:It hurts correctness. It is extremely challenging toreason about the interactions between every deployedversion 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 [78].
- C3:It is hard to manage. Rather than having a single binary to build, test, and deploy, developers have to manage 𝑛 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 anAPI, it becomes hard to change without breaking theother services that consume the API. Legacy APIs lingeraround, 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.
Their solution is a component-based architecture where the system is deployed in a monolith, and a runtime distributes components across machines.
I like the idea of distributing a system in a monolith and then just running parts where needed – perhaps with command line options for each component. It extends the idea of a mono-repo to a mono-application …
These are hard problems and there is no easy solution, but generally, if we can simplify the problems, that is good. Does this simplify the problem?