Author: Brandon Pearman

The views expressed here are mine alone and do not reflect the view of my employer.

We are going to look at the following ways of handling 3rd party services:

  1. Direct to 3rd party
  2. 3rd party specific edge service
  3. Orchestrator service
  4. Business capability service

Terminology

Business services talking directly to the third party

Added security risk because business services need to be able to communicate outside the system.

(Have to manage the security around multiple services talking out)

Contract changes

High cost of change when the 3rd party contract changes.

(every business service will have to adapt to the new contract of the 3rd party provider, then be deployed)

Adding new 3rd party providers

High cost of change when changing 3rd party provider to a new one.

(every business service will have to point to and adapt to the contract of the new 3rd party provider, then be deployed)

Very high cost of change and risk when introducing a new thrid party provider - which needs to function together with the existing provider.

(Every business service needs to know the rules on how to choose a third party, meaning every business service has to modified to have these rules and be deployed. Since the rules are duplicated across business services there is no guarantee of consistency, increasing the risk of bugs.)

eg every business service needs to use "Y third party" for certain cheaper capabilities and use "X third party" for its cheaper capabilities.

Number of extra services to manage

0 extra services

Number of extra network hops

0 extra network hops

Some of the issues with business services talking directly to the third party provider can be improved by abstacting the 3rd party away with an edge service.

For this case we will name our new service "X edge service" so that it can communicate with "X 3rd party". ie the edge service is named after the 3rd party provider.

If you were using this design and you needed to communicate to "Y 3rd party" you would then create a "Y edge service".

The "Y edge service" may replace the "X edge service" or it may need to work together with it.

Here are some examples of how you may need to use both 3rd parties at the same time:

  • Use "Y 3rd party" when "X 3rd party" is down.
  • Use "Y 3rd party" for certain features because they are better or cheaper.
  • Use "Y 3rd party" for certain users only.
Third party specific edge service

Lower security risk because only the edge service needs to be able to communicate outside the system.

(Only have to manage the security around one service talking out)

Contract changes

Low cost of change when the 3rd party contract changes - and the edge service contract is able to remain the same.

(only the edge service will have to adapt to the new contract of the 3rd party provider, then be deployed)

High cost of change when the 3rd party contract changes - and the edge service contract must also change.

(every business service will have to adapt to the new contract of the edge service, then be deployed. Along with changes to the edge service.)

Adding new 3rd party providers

High cost of change when changing 3rd party provider to a new one.

(every business service will have to point to and adapt to the contract of the new edge service, then be deployed along with the edge service)

Very high cost of change and risk when introducing a new thrid party provider - which needs to function together with the existing provider.

(Every business service needs to know the rules on how to choose an edge service, meaning every business service has to modified to have these rules and be deployed. Since the rules are duplicated across business services there is no guarantee of consistency, increasing the risk of bugs.)

eg every business service needs to use "Y edge service" for certain cheaper capabilities and use "X edge service" for its cheaper capabilities.

Number of extra services to manage

n edge services

Number of extra network hops

1 extra network hops

All the issues with business services talking to a specific edge service can be improved by abstacting the edge service away with an orchestrator service. The orchestrator service simply decides which 3rd party specifc edge service to call.

For example, Comms(Orchestrator service) decides if it must send:

  1. an email via "sendGridService"(edge service) which integrates with sendGrid(3rd party)
  2. an sms via "bulksmsService"(edge service) which integrates with bulksms(3rd party)
Orchestrator service

Lower security risk because only the edge service needs to be able to communicate outside the system.

(Only have to manage the security around one service talking out)

There is no gaurantee that every service is going through the orchestrator service, unless you set up port rules and keep checking that they don't get changed (which a new lead may decide to do).

(Developers may decide to call the edge service directly skipping important business decision which provided gaurantees)

Contract changes

Low cost of change when the 3rd party contract changes - and the orchestrator service contract is able to remain the same.

(only the edge service will have to adapt to the new contract of the 3rd party provider, then be deployed. In some cases possibly the orchestrator service may require changes as well.)

Very high cost of change when the 3rd party contract changes - and the orchestrator service contract must also change.

(every business service will have to adapt to the new contract of the orchestrator service, then be deployed. Along with changes to the orchestrator service and the edge service.)

Adding new 3rd party providers

Low cost of change when changing a third party provider to a new one.

(Only the orchestrator service will have to point to and conform to the contract of the new edge service, then be deployed. Along with the new edge service.)

Very low cost of change and risk when introducing a new thrid party provider - which needs to function together with the existing provider.

(Only the orchestrator service needs to know the rules on how to choose an edge service, so only the orchestrator service has to modified to have these rules and be deployed. Since the rules are all in one place, consistency is guaranteed.)

eg the orastrator service decides to use "Y edge service" for certain cheaper capabilities and use "X edge service" for its cheaper capabilities.

Number of extra services to manage

1 orchestrator service + n edge services

Number of extra network hops

2 extra network hops

Instead of splitting up this business decisioning into multiple services with different 3rd party specific edge services and an orchestration service, you can keep the same idea but join them into one service.

For example, Comms(Business capability service) decides if it must send:

  1. an email via "sendGridProvider"(Class/Module) which integrates with sendGrid(3rd party)
  2. an sms via "bulksmsProvider"(Class/Module) which integrates with bulksms(3rd party)
Business capability service with provider modules

Lower security risk because only the edge service needs to be able to communicate outside the system.

(Only have to manage the security around one service talking out)

Contract changes

Low cost of change when the 3rd party contract changes - and the business capability service contract is able to remain the same.

(only the business capability service will have to adapt to the new contract of the 3rd party provider, then be deployed.)

High cost of change when the 3rd party contract changes - and the business capability service contract must also change.

(every business service will have to adapt to the new contract of the business capability service, then be deployed. Along with changes to the business capability service.)

Adding new 3rd party providers

Very Low cost of change when changing a third party provider to a new one.

(Only the business capability service will have to adapt to the new third party contract, then be deployed.)

Very low cost of change and risk when introducing a new thrid party provider - which needs to function together with the existing provider.

(Only the business capability service needs to know the rules on how to choose a third party module, so only the business capability service has to modified to have these rules and be deployed. Since the rules are all in one place, consistency is guaranteed.)

eg the business capability service decides to use "Y edge service" for certain cheaper capabilities and use "X edge service" for its cheaper capabilities.

Number of extra services to manage

1 business capability service

Number of extra network hops

1 extra network hop

Direct to the third party

While other designs have clear advantages over this, you may feel they are unnecessary for your current system. For example if you have ten microservices and only one of them need to communicate to a third party, then you could simply call that third party directly if you wanted.

The moment your system and team grows in size it's worth looking at another solution purely to create guarantees and clarity on how the system works. For example if you 500 microservices can you gaurantee that only 1 of them are using a specifc 3rd party. I have found that teams often duplicate work when there is not a clear existing path.

Second, the moment more than 1 service needs to use the same third party, it's worth looking at another solution in order to create consistency.

Specific edge service

If you do not have a need for alternate providers and it appears that you will always have the same third party then this solution may be tempting. I still recommend not using it in this case because at this point the only difference between a "specific edge service" and the "business capability service" solution is just the name. For example:

Having a name which directly matches your third party provider locks you into that solution. Where as if the edge service is named after the business capability it is serving then it is very easy to pivot to different solutions, such as the "Orchestrator service" with seperate third party specifc edge services.

Orchestrator service

If you like naming your edge services directly after the third party then this solution is better than having business services talking directly to specific edge services but be aware of the need to maintain multiple seperate services.

Business capability service

This solution is theoretically the best and works well if one team maintains the connection to all the different 3rd parties it needs to connect to. For example, the solution does not work too well if the business capability service integrates with 4 different 3rd parties but each integration is maintained by a different team. If this is the case then rather have an orchestrator service where each team can maintain their own specific edge service.

Another possible down side is that developers have to be familiar with writting clean maintainable modular code. You want the ability to easily replace a 3rd party module the same way you would replace a seperate 3rd party specifc edge service. I the modules are not strictly defines and adhered to then the service may degrade over time.

Solution Comparisons

Direct to 3rd party 3rd party specific edge service Orchestrator service Business capability service
Business services comunicate internally X / / /
Contract change X / / /
Contract change with leaks to business services X X X X
Replace 3rd party provider X X / /
Replace 3rd party provider with vastly different contract X X X X
Adding alternative 3rd party provider X X / /
Services to manage / X X /
Network hops / / X /

Check out these links for more info:

My design and architecture repo