[wso2con eu 2017] how a large organization weighted on a wso2 integration platform architecture
TRANSCRIPT
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