Polyglot Because a monolith has a single codebase, it also has one language. Introducing a new language, a challenge that many an acquisition onboarding process has encountered, would be a daunting task that could result in significant migration work. However, with the microservices
approach, services can be authored in various languages. For example, you might write domain centric services in a language like Java, and network or system services in a language like Go. If they need to communicate with one another, they do so via language-agnostic means such as HTTP. The same principle also applies to persistence models. While a monolith is backed by a single database, typically relational, microservices often leverage a single database for each service. This opens up exciting possibilities for NoSQL in a climate where financial institutions frequently make use of unstructured data for risk-related decisioning, or where storing credit bureau data in a data lake could introduce tremendous cost savings.
OVERCOMING THE CHALLENGES OF MICROSERVICES
Although vastly beneficial in the right environment, microservices are not a silver bullet. In fact, they add a lot of additional complexity over the monolith. Let’s look at some of the key challenges to consider and highlight some best practices to
Compound this problem if that single change causes a ripple effect, requiring subsequent changes to multiple downstream services. The two most important strategies to avoid this are: 1. Clearly Defined Service Boundaries By encapsulating a business functionality within a single service, you can define a boundary that reduces network hops and dependencies on other services. Reducing dependencies, thus reducing network hops, makes it easier to reason about and test a change before releasing it. 2. Consumer-driven Contract Testing When dependency between services is critical, consumer driven contract (CDC) testing reduces reliance on end-to-end tests, leaving them as basic user journeys. CDC works a lot like test driven development (TDD) but at the architectural level, allowing you to validate functional collaboration between services through their independent component tests. And Voilà! You have shaken that dependence on the end-to-end testing tier.
work around said problems: • The Distributed Monolith • Cultural Resistance • Regulations • Monitoring • Deployment • Distributed Tracing The Distributed Monolith
The distributed monolith, while a problem of execution rather than concept, is often seen anti-pattern in microservice. This occurs when microservices are so tightly coupled that they must always be deployed and tested together as a whole. For example, if you have to run a slow and time-consuming set of end-to-end tests to validate a change to a single service, then a lot of the benefits of microservices are negated.
© 2017 PROVENIR ALL RIGHTS RESERVED
Made with FlippingBook Digital Publishing Software