NOTE: Integration is a key challenge when working with Microservices and so is going to be covered in my book "Antifragile Software: Building Adaptable Software with Microservices" available today on LeanPub.
In this world of ever-smaller services and systems that need to evolve at vastly different rates, the challenge of integrating these services across various boundaries (organisational, political, technical, evolutionary) is rapidly becoming THE set of skills every software developer needs to master.
Unfortunately there is never just one answer to the question of integration; each context must be measured up against what is needed. This requires a lot of careful consideration, and so some guiding questions are needed to help lead you to your right answer.
I'm going to write a short sequence of blog posts on the challenge of integration to get you started on this journey, first by framing the whole issue with just 2 questions.
These 2 questions are the key concerns that should be constantly on the mind of every software developer when trying to integrate two systems, services or components.
I'm going to use the 'system' terminology here for the two participants involved in the integration under examination because it is the most generically applicable term. Where I say 'system', you could replace it with service, application or component.
Those 2 crucial questions that should be on the mind of everyone considering integration are:
Question 1 is all about deciding what contract can be set between the two systems. Question 2 is about weakening that agreement to the right level.
For example it may be possible to accept RPC as an integration technology if the answer to question 1 is that we can agree to everything; we can be tightly coupled. We're going to share code, and evolve at exactly the same rates.
More likely is that one of those coupling factors needs to be weakened, and that's where Question 2 comes in. You could leap to completely asynchronous messaging to integrate your systems, but that comes with a whole plethora of complexity. My approach is to not too much flexibility with complexity if you can avoid it, so I never start from the most flexible solution; I force myself to start from a brittle solution and weaken it.
Those two questions frame most of the details of integration, and in further posts I'll explore different scenarios where those questions will guide us to the right answers.
In this world of ever-smaller services and systems that need to evolve at vastly different rates, the challenge of integrating these services across various boundaries (organisational, political, technical, evolutionary) is rapidly becoming THE set of skills every software developer needs to master.
Unfortunately there is never just one answer to the question of integration; each context must be measured up against what is needed. This requires a lot of careful consideration, and so some guiding questions are needed to help lead you to your right answer.
I'm going to write a short sequence of blog posts on the challenge of integration to get you started on this journey, first by framing the whole issue with just 2 questions.
These 2 questions are the key concerns that should be constantly on the mind of every software developer when trying to integrate two systems, services or components.
I'm going to use the 'system' terminology here for the two participants involved in the integration under examination because it is the most generically applicable term. Where I say 'system', you could replace it with service, application or component.
Those 2 crucial questions that should be on the mind of everyone considering integration are:
- What do we need to agree between the two systems?
- How much complexity are we will to buy to get the right level of flexibility on that agreement?
Question 1 is all about deciding what contract can be set between the two systems. Question 2 is about weakening that agreement to the right level.
For example it may be possible to accept RPC as an integration technology if the answer to question 1 is that we can agree to everything; we can be tightly coupled. We're going to share code, and evolve at exactly the same rates.
More likely is that one of those coupling factors needs to be weakened, and that's where Question 2 comes in. You could leap to completely asynchronous messaging to integrate your systems, but that comes with a whole plethora of complexity. My approach is to not too much flexibility with complexity if you can avoid it, so I never start from the most flexible solution; I force myself to start from a brittle solution and weaken it.
Those two questions frame most of the details of integration, and in further posts I'll explore different scenarios where those questions will guide us to the right answers.
RSS Feed
