Last year, researchers from Google published the paper "Towards Modern Development of Cloud Applications." In it, they describe five issues with microservices:

👎 It is slower. Serializing data is one of the more expensive things applications do, and Microservice architectures create a lot of serialization.

👎 It is harder to test. If every service is deployed independently, you have an ever-expanding set of testable, or more to-the-point, untested, permutations.

👎 It is more complicated to operate. Each service ends up with its build, test, and deploy steps, and while one can work towards a shared framework, skew is almost inevitable.

👎 It slows down change. Deployed APIs are less likely to be modified for fear of breaking production systems, leading to multiple versions of APIs that accomplish nearly the same function.

👎 It impacts application development. Engineers must consider all affected services when rolling out broad changes and create carefully orchestrated deployment plans.

So what is their fix?

✅ Build a monolith, modularized into distinct components

✅ Use the runtime to assign logical components to physical processes (see Akka in the Scala world)

✅ Deploy everything together so that all services are constantly working with the same known version

So, do you need microservices or monolith-as-microservices? The answer is probably neither.

Most teams and technologies benefit from a much simpler, monolithic model.

You do not have Google-sized problems. But, of course, Google Cloud (and Amazon and Azure) would like you to think you do!