Microservices vs. Monolith: Risk Analytics in a Microservices Architecture: Part 3
This microservices series wraps up by contrasting the approaches of the monolith and a microservices approach to round out our understanding of the concept.
Join the DZone community and get the full member experience.Join For Free
Unless you've been living under a rock without wi-fi, in which case I would question your ability to read this article, you've likely heard the concept of microservices compared with a monolithic architectural style. Comparison with the monolith is a great way to explain the characteristics of a microservices style because the two architectural concepts exist in stark contrast: large and interwoven, small and discrete.
If you're looking for the benefits of microservices, you can find that in our article here. Or, if you're looking for a dive into the implementation of microservices, you can find a Q&A here. For now, we will simply contrast microservices with the monolithic approach to development to gain a baseline understanding of the concept.
Part of an architectural concept where the focus is on discrete services that do one thing, and do that one thing very well. In the risk decisioning context, an analytics group within an organization might be responsible for developing and exposing scorecards as microservices. The data scientist, or analysts, would focus on developing really good scorecards and making sure these scorecards continuously deliver quality results. They would then expose these scorecards as discrete services that could be called upon to deliver excellent and accurate scores. An operations group could then develop applications or processes that call out to these scorecards at the right time, leveraging these scores in a decision process.
Most of the time, business processes are designed to be an end-to-end process. That's what we call a monolithic architecture. All parts of the decision process are developed as one, large complex process. Let's consider scorecards again, as an example. If you want to make a change to a scorecard there may be a great deal of coordination, refactoring or redevelopment of the process, then testing before rolling out again.
If you find this comparison helpful, I dive into the concept with more detail in this video.
Published at DZone with permission of Mike LaFleur, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.