Many times, it's just not worth it!
I have been championing MicroServices for well over a decade. But I don't always go to a MicroService solution for my clients' problems. In this talk, I will characterize the traits that should drive you to avoid MicroServices, and instead look toward more traditional or even SOA alternatives. Included in the talk is my recent experiences in two Norwegian government projects, both very successful, with minimal MicroService influences.
"If you aren't doing MicroServices, you are building an obsolete system!"
"MicroServices are the way to go if I want to keep my job."
"If it is good enough for Netflix, it should be good enough for us."
I hear all of these things as I attend conferences. And I feel apprehension for these companies, suspecting that the vast majority will fail. And failure will come from several sources:
* Little or no experience with MicroServices.
* Processes from traditional systems being forced on MicroService projects.
* MicroServices is not the appropriate architecture for the problem!
In this talk, I will focus on the latter issue. The other two issues will resolve themselves with time and experience. The latter issue will always be fatal!
First, we will discuss the problem domains particularly appropriate for MicroServices. Then we will address the radical differences in processes, team organization, and business management of MicroService and non-MicroService approaches.
Finally, we will touch on two recent projects for the Norwegian government, their overall architecture, and their minimal use of MicroServices. We will note, however, that they do exploit event buses, continuous deployments, and modern languages. So despite not being MicroService-based, they are being successfully deployed.