How Channex uses Microservices to Integrate Faster and Better in the Travel Industry

A story of how we use it and it’s benefits

The last few years you have probably heard all the hype about microservices. Mostly it was from cloud providers like AWS or Microsoft since they benefited from this by you having to use more servers and more services!

Recently a lot of talk has gone to talk about serverless, which i guess is like a microservices on a pay as you go model.

Anyway for integrations particularly it is a huge time saver and complexity reducer.

What is a Microservice

Basically you can think of your app as one giant pice of code, anytime you add more features the size gets bigger. So if you want to integrate another service like connecting an online travel agent to send prices and receive bookings you are adding that code into the main monolithic app.

Whats the issue with integrations?

For Integrations the biggest problem of adding integrations into the core app is that, if any changes are required you have to deploy the whole app again. Let’s say you you deploy every 2 weeks, you can apply the fix to your integration each 2 weeks or risk a immediate deploy just to fix that one issue.

If you have 3 integrations it is a pretty minimal issue but if you plan 100s of integrations like we do with Channex that is a whole load of pain and risks.

Our experience

As with all startups we needed to save time in the first few years and did integrations from the core system, we needed results fast and waiting months to build a microservice architecture was not great. Once we hit 6 or 7 integrations it started to get a bit tougher and after a few deployment issues just from updating some minor issues we finally bit the bullet to improve.

Separate integrations into microservices

Before building a microservice you need to standardise the way you will talk to them, usually it will be RPC calls which is a fast way to send instructions to a microservice.

Once ready you will want to build your next integration in a microservice and it might take way longer. It took us months longer to build the integration but most of the extra time was to learn and build the core things which you can reuse later.

We estimate about 2–3 months spent to build and plan. Once completed time to integration should go back to normal or a little faster.

Once you have built a few new integrations as a microservice it is time to move your old integrations to the new model. In our experience the microservice integrations ran much better and was easier to look after than built into the core.

The one huge benefit

The huge benefit of this approach is that it simplifies your whole system in regards to integration maintenance. Now if any changes or emergency fixes are required you just need to update and deploy the microservice and not your core system.

You need to rate limit one of the connections?

You need to do some extra logic?

You need to batch the data and send per one minute?

All of this logic can be built into the microservice and deployed and rolled back easily if any issues. Your speed to integrate and adapt is greatly increased and you don’t get that fear of:

“If I touch this integration I am scared the whole thing will fall apart”

Another use case of incoming integrations

Above I talked about Channex integrating to other apps, but often times you need to receive data from other apps in their specifications.

In the travel industry they often send their data in XML in a half standardised way with many little changes to break the standard.

Can Channex build this for my app?

Yes, we are working with a few partners in the travel industry to build the microservices and integrations for them in an outsourced capacity and deliver the code so they have 100% ownership.

If you need to build or wish to move to this method please reach out.