Blog Posts Process Management Service Oriented Architecture (SOA)

Microservices Architecture pt.2: Why do we want Microservices architecture? By Lykle Thijssen

Blog: PaaS Community

After exploring what a microservices architecture actually is (see Microservices Architecture pt.1: Definition), we can ask ourselves why we want such an architecture. After all, it seems rather complex, discourages reusability, can lead to data inconsistency and any hype will be overtaken by something else in the future. However, there are benefits too and most of the downsides can be mitigated. It’s also not always necessary to go for the most hardcore version of an idea, some middle ground can be reached to come up with a reasonable solution.
The most important reason for microservices architecture is to get rid of dependencies. Many systems are very hard to manage and maintain, because a small change can create a massive butterly effect and the entire application may be at risk. With microservices architecture, you isolate business modules, so a change in the insurance part of the company will not affect their marketing application and vice versa. This also makes it easier to release changes and updates, because the bounded context protects you from unexpected and undesirable side effects.

Another reason is that many organizations are disappointed with the traditional approach to SOA. In many cases, implementing SOA has not led to more flexibility, but actually less, as now multiple layers need to be tweaked to make a single change and massive enterprise metadata repositories make it virtually impossible to change things without massive consequences. If all your services are using your Person.xsd and you need to make a change to that one, you’re going to be royally screwed. Besides, the Person.xsd will most likely contain everything from every context, which makes it unfocused and hard to work with. On the other hand, not using these metadata models also have downsides, as you need to make a lot of transformations. Microservices architecture can be a nice middle ground here, because you can isolate the Person’s context to the business module and there are no dependencies between the different business domains. So, the context of a person is completely different for insurances as it is for marketing and guess what… that’s totally okay and no longer an issue. Read the complete article here.

PaaS Partner Community

For regular information on Oracle PaaS become a member in the PaaS (Integration & Process) Partner Community please register here.

Blog Twitter LinkedIn Facebook Wiki