Enterprise Integration Zone is brought to you in partnership with:

Mark is a graph advocate and field engineer for Neo Technology, the company behind the Neo4j graph database. As a field engineer, Mark helps customers embrace graph data and Neo4j building sophisticated solutions to challenging data problems. When he's not with customers Mark is a developer on Neo4j and writes his experiences of being a graphista on a popular blog at http://markhneedham.com/blog. He tweets at @markhneedham. Mark is a DZone MVB and is not an employee of DZone and has posted 553 posts at DZone. You can read more from them at their website. View Full User Profile

Micro Services: Plugging in 3rd party components

12.12.2012
| 2452 views |
  • submit to reddit

Over the past few weeks I’ve been involved in conversations with different clients around micro services and one thing about this architecture that seems quite popular is the ability to easily plug in 3rd party components.

In one case we were talking through the design of a system which would calculate and then apply price optimisations on products. The parts of the system we were discussing looked roughly like this:

 Micro services

As per the annotations, one of the questions asked was whether it would be possible to start out with the assumption that each component would be custom built and then assess that decision after a few weeks.

An advantage of splitting each of the components into their own application is that we could reasonably easily plug in a 3rd party tool behind the boundary while keeping all the HTTP wiring as custom code.

This allows us to get going quickly and write simple stubs in place of the main logic of some of the components to begin with.

We can defer the integration/learning curve of the 3rd party component while we prove out the architecture as a whole. In addition we are not letting the 3rd party component drive the design of our system but instead allowing it to play a supporting role.

One final thing to note is that since each component is a separate application it’s much easier to have different teams working on each one than it would be if they were all contained in the same application.

There would need to be communication between teams around the design of contracts between the services but after an initial period of churn hopefully those would become reasonably stable.

Published at DZone with permission of Mark Needham, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)