Micro Services: Plugging in 3rd party components
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:
image:https://www.markhneedham.com/blog/ /uploads/2012/12/micro-services.png[Micro services,357]
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.