Micro-services have been the rage in software circles over the past couple of years. A natural evolution of service oriented architectures (SOA), and popularized by successful implementations at companies like Spotify, Soundcloud and many others, micro-services have become the “must have gadget this holiday season”: if you aren’t doing them, you must be doing something wrong.
But is that true? As much as people (and especially engineers) love black and white, the answer here is a firm “maybe.” Here are some of the positives and negatives from one CTO’s perspective.
On the plus side, micro-service architectures provide an excellent canvas for rapid development and continuous integration. Hard dependencies are minimized, business logic is localized, and the resulting services are typically cloud ready. Developers tend to like micro-services because it allows for a great deal of independence. It’s hard to understate the potential pain savings and optimizations – people, process and technology – that can be driven by moving to this type of architecture.
But it doesn’t come for free. For starters, you’ll likely have a lot more moving pieces in terms of individual components and running executables. A few weeks ago I wrote a post on the architectural heuristic: Simplify Simplify Simplify in which I posited that simple is better when it comes to minimizing TCO. In that vein, one must ask if micro-services follow the rule. Yes, each individual service itself is simpler than a bloated monolith as a result of the small size and tight boundaries. But the total business logic in your enterprise hasn’t changed, and now you may have hundreds or thousands of additional code modules to manage and executables to orchestrate. The good news is that cloud hosting providers like AWS provide an ever increasing set of tools to help with managing micro-service architectures (e.g. Lambda, Container Services), but it still requires a good deal of cultural and process change.
Another side effect of the proliferation of executables is potential increase in cost – many hosting providers and software vendors (e.g. APM providers) still price based on number of processes or agents. If you take the same processing load and 10X the number of running processes, you might find yourself in a world of hurt pretty quickly.
Finally, in moving to micro-services, you’ll find yourself needing to address a host of new challenges that you may not have had to previously – service discovery, versioning, transactions and eventual consistency, event tracing, security, etc. At a minimum, the upside benefits you’ll realize will be offset by developing competency and code to solve those new challenges.
So, what does this mean for the typical company. If you have applications that are bloated monoliths, those are fantastic candidates for breaking down into smaller components or micro-services. On the other hand, if you have a reasonably well architected system with decent boundaries in place already, I’d carefully weight the cost-benefits – maybe run a few trials projects to get a better sense of how it would fit into your platform. Just realize that in many ways you’re “squeezing the balloon” – trading one set of problems for another. So long as you’re happier with the new problems (and the corresponding benefits), you win.
In closing, whether you move to micro-services or not, I do think there are great lessons to be learned from applying the discipline required by micro-services – namely, enforcing clear boundaries around business logic and using “API thinking” to service a variety of clients. I wonder if there isn’t a compromise to be had in which one uses the principles for developing and organizing the code, but you still deploy in a more constrained manner – “Code Micro, Deploy Macro.” But that’s a discussion for another time.