How the size of a large organization weighted on a WSO2 integration platform project architecture

Thomas Cordivalenioka Haute Couture

Organizational context

• Automotive industry• Very large organization (≥ 200 000 employees)• Thousands of systems, flows, services• Hundreds of teams in the IT department

2

Business problem

• The purpose of this project was to replace the existing services exposition platform to– Allow on premises applications to expose their

services on the internet securely– Make building front-ends easier, faster and more

agile by providing a unified way of using services– Ease consumption of SaaS services by on

premise applications

3

Technical context• Most applications are hosted in self-owned datacenters

• Existing internet services exposition infrastructure– Was built for web applications entirely hosted inside the

datacenter– Was designed with a focus on serving employees, not end users– Is built on deprecated technologies and focused on SOAP Web-

Services

èWe had to build a new services exposition platform

è This platform was build on WSO2 ESB 5.04

Requirements

• Incoming calls permissions management• (very) Dynamic routing• Payload transformation• Environment management• Credentials management

5

Technical constraints• This was the first project built on a WSO2

component, given the scale of the company, this induced extreme caution

• This shared platform would be used by most internal projects, so deployment had to be integrated with the existing tooling

• Since licenses were paid by the JVM instance, every projects would use the same WSO2 instance

6

Technical team specific requirements• Every payload processing must be done outside of

the ESB

• Every task done by the ESB has to be stateless (or as least must resist to stateless load-balancing)

• Ensure ability to call multiple environments from a single WSO2 instance (with isolation between Production and other environments)

7

Datacenter

Solution Logical architecture

8

JBoss

Route /Transform

servlet

WSO2 ESB

Backend application

Security appliance

LDAP

API

Authorization

Routing table

IncomingHTTP request

ELK

Internal Network

WSO2 Deployment(Production environment)

9

Backend application

Load-Balancer

WSO2ESB

WSO2Registry (ESB)

WSO2ESB

JBossLB JBoss

Routing table(PostgreSQL)

WSO2 ESB as a multi-tenant solutionMultiple projects living in the same WSO2 instance• To allow multiple projects to deploy components to the

same instances of WSO2, we had to define a naming convention to prevent naming clashes

• This was done because the multi-tenant mechanism of WSO2 ESB 5 wasn’t flexible enough for our use case– Sharing sequences– Sharing connectors– Fair runtime resources (CPU, memory…) sharing between

projets– Integrated into our continuous deployment tooling

10

WSO2 ESB as a multi-tenant solutionMultiple projects living in the same WSO2 instance• Named by URL

– API (service’s URL and HTTP methods accepted)– Sequences (reusable logic inside WSO2)

• Named by environment type and backend application– Credentials– Endpoints (URLs of backend applications)

• By environment type– Routing table

11

WSO2 ESB as a multi-tenant solutionComponents sharing• Having every projects in the same instance allowed us to easily

share components (sequences)– Authentication sequence– Routing sequence– Payload processing delegation sequence– Credentials extraction sequence– SaaS connectors (mostly built in-house)– Error handling sequences– Logging Sequences

è These shared components were essentials to the coherence of practices of the multiple projects

12

WSO2 ESB as a multi-tenant solutionOperation of the platform: common tooling and practices• Deployment tooling and practices

– Internal tooling was adapted to deploy APIs, Connectors…• Environments and routing management

– Routing table is stored in the database and interpreted by the servlet hosted by JBoss the JBoss application server

– Routing table is shared between environments and applications• Credentials management

– Built with WSO2 logic– Back-end credentials key come with the routing information

from JBoss• Logs centralization

– Built upon ELK13

What we wish we could have done?

• Better development tooling– Containerization of the tools (WSO2 ESB, Jboss,

PostGreSQL)– More mocks oriented development– More frequent tests

• A more integrated solution– Simplify the solution by offloading less work to the

application server– A lighter CI/CD solution enabling us to deploy regularly

14

Implications of the organization and project sizes on the solutionLarge investment involved some prudence

è Start with low dependence to new technology

Platform built for multiple teamsè Multi-tenancy in naming conventions and projects structure

Large number of projects and APIsè Scalability and good operability from the start

New technology used as foundation for a shared platformè Integration work required to adapt the solution to our specific requirements

• Good: Some best practices become mandatory from the beginning of the project• Bad: You end up building a complex solution to support the size of the project

15

Thank you