MuleSoft migration to Azure — architecture and technical choices

The starting point

The existing platform rests on the usual components of a proprietary integration suite: runtime engine, API manager, message broker, object store, monitoring, access management.

The flows draw on a wide range of connectors — HTTP, SFTP, FTP, databases, SAP, email, message queues and a scheduler — and some of the systems remain hosted on site.

The study method

We produced a component-by-component analysis rather than a single architecture: application hosting, message broker, API gateway and load balancing, cache and object storage, network connectivity, observability, delivery pipeline.

For each one, the options available on Azure were compared on their technical characteristics, their operational complexity and their total cost of ownership. Those options were then combined into three coherent scenarios, each with its variants.

The central decision was about hosting: Azure Container Apps versus Azure Kubernetes Service. AKS offers greater control and portability, but assumes permanent Kubernetes expertise and therefore a larger team. Container Apps was chosen for its operational simplicity and its autoscaling driven by business signals.

Deliverables from this phase: a technical decisions document and architecture documentation in C4 format, built during workshops held with the client's infrastructure and integration teams.

The target architecture

• Application hosting — containerised Camel microservices on Azure Container Apps, across three environments (development, staging, production). Autoscaling relies on business signals, including queue depth, and not only on CPU load.
• Message broker — RabbitMQ kept and self-hosted in a cluster. The AMQP protocol stays the same, which avoids reworking the application code of the 90 flows — the decisive argument against a cloud-native broker, which would have forced a rewrite.
• Exposure and security — an Application Gateway provides TLS termination, the web application firewall and path-based routing, completed by an ingress controller for fine-grained routing.
• Cache and storage — a managed Redis cache for tokens and session data; object storage for the large files coming from batch and SFTP flows.
• Connectivity — a site-to-site VPN gateway to the on-premise systems, sized for the real load. A dedicated private link was ruled out: oversized for 300 to 400 requests per minute, at a cost and a lead time out of all proportion.
• Observability — application monitoring, distributed traces and centralised logs, fed by metrics exposed from the Camel routes.
• Secrets and identities — a managed secret vault and managed identities; authentication and permissions backed by the corporate directory.

Security decisions

Two components, initially considered for public exposure, were switched to private access to align with the client's security policy: the API gateway and the container registry. A decision taken during design, with consequences for the addressing plan and the deployment pipelines.

Infrastructure as code

The infrastructure is described in Terraform, organised into reusable modules — Container Apps, RabbitMQ, gateway, network, monitoring — and instantiated per environment:

modules/
  container-apps/
  rabbitmq/
  api-gateway/
  network/
  monitoring/
environments/
  dev/
  staging/
  prod/

State is stored remotely with locking, variables are externalised per environment, and infrastructure tests run in the pipeline.

The delivery pipelines

Two pipelines coexist on Azure DevOps.

Camel microservices — Maven build and unit tests, integration tests on ephemeral containers, quality analysis, a multi-stage Docker image build, publication to the registry with semantic versioning, then automatic deployment to development and, on approval, to staging and production.

Infrastructure — validation and formatting of the Terraform files, a preview of the changes, apply on approval, tests, and automatic regeneration of the documentation.

The Apache Camel proof of concept

Before committing to migrating the flows, a proof of concept validates the points that will decide feasibility:

• end-to-end operation of the delivery pipeline;
• communication with the real systems — SAP, SFTP, message queues, databases, HTTP;
• running the externally exposed APIs in parallel during the switchover period;
• CPU and memory consumption of the application containers, measured under load.

It comes with a Camel repository template — a standard Spring Boot application structure, example routes, tests, a parameterised Dockerfile, observability configuration, pipeline files — and a best practice guide for the teams who will take over development.