These days, you can't swing a dry erase marker without hitting someone talking about microservices. But as developers write more code and build more applications than ever before, the trick is knowing which processes should use microservices and which shouldn't. This report provides a set of principles you can use to focus your efforts.
Nate Schutta-prolific author, seasoned speaker, and proponent of polyglot programming-explains that while there are many good reasons to use microservices, this architecture can make things more complex. If you answer "yes" to one or more of the principles in this report, then your company is a good candidate for microservices. Answering "no" to every principle means you'd likely introduce accidental complexity into your system.
- Parts of your system that evolve at different speeds or in different directions
- Independent life cycles among the features in your application
- Meeting demand by allowing components to scale independently
- Using an abstraction layer to isolate third-party dependencies
- Choosing different technologies to tackle different jobs
- The impact that a technological change has on company culture