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


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.

clip_image003 Blog clip_image005 Twitter clip_image004 LinkedIn image[7][2][2][2] Facebook clip_image002[8][4][2][2][2] Wiki

Technorati Tags: SOA Community,Oracle SOA,Oracle BPM,OPN,Jürgen Kress

About Jürgen Kress
As a middleware expert Jürgen works at Oracle EMEA Alliances and Channels, responsible for Oracle’s EMEA Fusion Middleware partner business. He is the founder of the Oracle SOA & BPM and the WebLogic Partner Communities and the global Oracle Partner Advisory Councils. With more than 5000 members from all over the world the Middleware Partner Community is the most successful and active community at Oracle. Jürgen manages the community with monthly newsletters, webcasts and conferences. He hosts his annual Fusion Middleware Partner Community Forums and the Fusion Middleware Summer Camps, where more than 200 partners get product updates, roadmap insights and hands-on trainings. Supplemented by many web 2.0 tools like twitter, discussion forums, online communities, blogs and wikis. For the SOA & Cloud Symposium by Thomas Erl, Jürgen is a member of the steering board. He is also a frequent speaker at conferences like the SOA & BPM Integration Days, JAX, UKOUG, OUGN, or OOP.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: