Over a million developers have joined DZone.

Microservices vs. Monolith: Risk Analytics in a Microservices Architecture: Part 3

DZone's Guide to

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.

· Microservices Zone ·
Free Resource

Containerized Microservices require new monitoring. Read the eBook that explores why a new APM approach is needed to even see containerized applications.

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.

The Monolith

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.

Discover how to automatically manage containers and microservices with better control and performance using Instana APM. Try it for yourself today.

microservices ,risk analysis ,risk analytics ,monolith

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}