Skip to content

Reducing infrastructure costs and improving performance in Systems Integration; replacing ESB with Camel Microservices

Terry Beavis | Wednesday, August 5th, 2020

Problem

The SOA solution implemented using WSO2 APIM and WSO2 EI, was following old guidelines and originally designed to live within a secure network. There were a number of issues to resolve:

  • The solution was migrated to the cloud without any security uplift.
  • This SOA solution was implemented on top of VMs and the product used was not designed to run in containers.
  • All APIs developed where sharing the same ESB security context, they were not able to scale independently and were competing for resources (CPU/RAM).
  • Due to some corporate restrictions the solution was not allowed to use AMI, AutoScaling groups and other AWS services, so monitoring the infrastructure and reacting when failures occurred was troublesome (no self-healing).
  • The performance test only achieved half of the SLA required so additional EC2 instances were required.
  • The infrastructure cost of the solution in AWS was expensive, there were significant numbers of EC2 instances for each environment and there were 20+ environments.
  • Debugging the APIs was difficult because WSO2 EI uses XML Synape syntax.

Requirement

The solution:

  • Must be cloud-agnostic.
  • Must be open source, minimise licence costs and avoid vendor lock-in.
  • Must store secrets in a central Hashicorp Vault solution; adhering to corporate policies.
  • As part of new security guidelines encryption in transit has to be implemented for all services.

Solution

A  new microservice architecture was designed on top of Kubernetes, Rancher, Docker, Istio, RabbitMQ, Kafka+ELK, Hashicorp Vault and Apache Camel.

The new architecture follows best practices, such as 12-factor application, and enables new features including: auto-scaling, self-healing, encryption in transit, is multi-cloud and cloud-agnostic.

It centralizes secrets management in Hashicorp Vault; using Vault as central Certificate Authority and Intermediate CAs for digital certificates. It is integrated with Istio to use those certificates to encrypt the communication between servers on the fly.

Another significant switch was the move away from Synapse to start to using Apache Camel. This improved development capacity because this framework is active and is backed up by RedHat. It comes with hundreds of components, and out-of-box integrations with different products.

A set of POCs was conducted to test a new Microservices Architecture approach, that POCs migrate some APIs to Camel microservices and load test each of them to compare them against the incumbent solution.

Challenges

We had a number of challenges; including:

  • Integrating with legacy backend systems that can not support encryption in transit.
  • Working with multiple layers and different cloud providers.

Result

  • The new solution increases the performance of the most critical APIs between 40% for big payloads and 70% for small payloads.
  • Reduce 66% the amount of infrastructure required to provide the same service.
  • Implement by default encryption in transit for all HTTP APIs where we can change certificates on the fly without disrupting the service.
  • Eliminate WS02 support licencing costs and give total control to developers to amend issues of the APIs.

Filed under: Case Study, Systems Integration