Building Next Generation Banking Middleware at ING: The role of a lightweight ESB

ING ModelBankMiguel Morales GarcíaEnterprise ArchitectLondon – Nov, 2017

The classic vision of a Bank…

Super Big Host

Anything

It’s true…

• But Banks don´t have a Super Big Host• In the past it was common to find …

More than 200 super big hosts (please, visit bian.org to see a functionality landscape)

• Traditionally, It was the Monolith and Silos Paradise• With this classic approach try to offer the best for our customer in a changing

world was a big challenge. • It was time to …

Next Generation Banking systems (and in this case, middleware)

3

Let’s change

• When talking about Next Generation Banking middleware, we usually think in microservices

It is TRUE

• Ok, you have your great design, with a full set of microservices… And all your existing functionality in your 200 superbigbig hosts

• Migration Will only take 10 years, awesome, no?• (and Yes, we have a colleague that told us that a friend of a friend saw a

greenfield approach before die)• So, now, basically, you have 200 superbigbighosts, 50 microservices (in

your mind) and a superbigbigbigproblem

4

Time to think: Discovering your root problems

• 1st Enemy to solve: The oversimplifier• Avoid the concept of “Target” Fix superb Architecture, it is a dream: You have to

be ready to manage an “In motion” Architecture always. The clean target is an oversimplification of your reality: When you are there, new challenges will arise and you need to evolve again

• Consequence: Learn to design for changes in design and in technology, live seamless in combination with your former approaches and learn how to balance evolution and adaptation at the minimum cost of change (CoC)

• 2nd Enemy to solve: The BIG migration• Big migrations consume your resources and freeze your capability to adapt to your

customer needs• Consequence: Learn to design for microchanges

• 3rd enemy: Separate your customer needs from your technology• Customer needs changes and evolve, your processes need to support that• Consequence: Processes need to be defined by composition of capabilities that are

linked with your customer needs, no GAPS

5

Ok, but HOW? Before the solution…

• Let’s remind some basic knowledge that you (of course) have• Rediscovering the root pattern(*):

• The rules that creates the BUS are basically the mix of two patterns, the Canonical data Model and Common Command Set with a common communication mechanism:• Common Communication infrastructure in all participants, with the ability to know the route

of the messages (or request) from one system to another: For example, common network with a Service Discovery or a Broker that routes the messages

• Common adapter with an agreement in the Canonical data model: The same concepts and the same representation of them have to be shared in the adapters, in order to communicate each other.

• Common command Structure: The participants have to share the same command set : The use of a REST semantics, simplify the creation of the bus structure

6

(*) Those patterns are very well described in the book Enterprise Integration Patterns, Gregor Hohpe, Bobby Woolf & Others, patterns Message Bus, Message Broker, Message Router and Canonical Data Model ) )

New look to the Bus pattern in the microservices

• The goals of the BUS pattern are (*):• Decouple system in a distributed environment• Avoid the N-square problem (point to point integration) from a semantic and

technical perspective • Allow the whole system to be resilient to changes and improve composability

• The BUS pattern doesn´t imply business logic in the BUS itself• The goal is to provide a clear composition structure for building blocks,

no more silos connected applications

7

(*) Those patterns are very well described in the book Enterprise Integration Patterns, Gregor Hohpe, Bobby Woolf & Others, patterns Message Bus, Message Broker, Message Router and Canonical Data Model ) ) . The pictures are

taken form the book as well

The typical deployment of the bus pattern could include a messaging platform (not always a MOM) with highly integration capabilities in order to maintain the original systems untouched an reduce the complexity of the connector deployment

No more silos…

8

Welcome composition!

9

Broker or Brokerless discussion

• However, to implement the BUS that allow us composition as described, a central broker can be used or not. • For example, ZeroMQ and RabbitMQ has a famous blog about that

[http://www.rabbitmq.com/blog/2010/09/22/broker-vs-brokerless/]. The broker implementation is usually needed when you need a common control point for security, manegability, decoupling and reusing of integration instances, etc, as it is used as a common proxy for communications.

10

Broker or Brokerless Approach (1)Brokerless Approach: • It is implemented with peer to peer communications and:

• A central registry (for example Zookeper) that acts as a level of indirection to allow changes

• Usually is behind a Gateway in request response scenarios (i.e. internet channels)

• Common communication channel and protocols and compatible building blocks

• Pros: • No central point of failure for processing despite the GW and the

Registry, that can be cached• No performance hit when a central system has to process every

message• Better overall simplicity and easier scalability if not logic in client

routing• Cons:

• Cross concepts have to be implemented in every node (for example security), so any changes in then implies refresh all your nodes and the nodes are more complex and prone to suffer the classic SOAP ripple effect. If the platform has some flaw, you will find this flaw in your platform and it will be a single point of failure, as you don´t have SoC in platforms

• You have to maintain only one node to a given integration with a system, to avoid the N-square problem, that implies always a very good design and governance (if a node centralized the integration you are using a de facto integration gateway)

• If nodes are not governed, and resilience patterns are not well implemented by different stacks the entire network can suffer the SLA inversion antipattern

11

Registry

1’

2’

3’

4’

Broker or Brokerless Approach (2)

Broker Approach• It is implemented with a central system that processes all

the requests, usually including an internal registry, with systems that have very good capabilities of transformation and multiple network transports

• Applicable specially in heterogeneus environments• Pros:

• Cross concepts are deployed in the broker, so changes to the whole architecture don´t imply node refresh

• All the technical adaptations needed to implement a BUS concept can be easily managed and centralizing avoiding the N-square problem and the building blocks are simpler

• The broker can store messages in case of node fails and improve the global resilience

• Cons:• Central point of failure in code, not in nodes, as the brokers are

usually several instances in parallel, if you can´t resort to peer to peer

• Add some delay to every request because have to process them

• Add some complexity in the deployments because it has to manage all the cross transformations and capabilities, like security

12

The Hybrid Model

• The hybrid model is the preferred path to evolve architectures. It holds the best of broker-brokerless worlds needed in typical worldwide scenarios.

• The hybrid model states that the systems should support brokerless approach with Service Discovery, but a broker approach is valid as well. Allow true composability scenarios in the real world.

13

Typical Use cases:- Migration or canary releasing that

requires Message Based Routing (MBR) even in peer to peer scenarios

- Legacy apps that need message or protocol adaptation, avoiding the pollution in the other participants and the n-square problem

- External (Internet, 3rd party) apps- Internal apps that need to be secured

because not all the new security requirements are supported

- To provide bulkheading, circuit breaking limit number of concurrent requests or additional tracking control between participants

- New technology app’s or prototyped ones that don´t implement the calls to the security API’s by themselves

Typical Use cases:- Low latency communication (even using

loopback or direct in-memory connection)- Strong authentication in a peer to peer

communication can be deployed in your components

- Participants have the Circuit breaker, Service Discovery, Failover groups and semaphore control implemented in their stacks natively

- Language and commands are shared and use natively between participants.

WSO2 as Lightweight ESB in Hybrid Models

• Once a common BUS is created based on REST and EVENTS, it can runs as a broker, managing all the interactions between apps or blocks

• But, at the same time, it can participate as a member in peer to peer scenarios thanks to its flexibility and speed

14

WSO2 ESB as broker

Of course, “API First” need to be introduced as well

• WSO2 ESB allows us to deploy API’s automatically from our Development lifecycle using swagger (Open API) definitions, and do it with zero downtime. Its flexibility allowed us to decommission older solutions while maintaining compatibility with classic API’s and new ones

• Its ability to provide API prototyping using scripting accelerates integration and the rollout of new ideas

15

WSO2 ESB as API GW

Integrated Development Lifecycle with API’s as

an assest

Defined Api’s

Defined Api’s

Defined Api’s

WSO2 ESB as internal API

GW and broker

New patterns in your always in transition Architecture

• Once you introduced in any way a highly distributed architecture as microServices, the integrity of information need new patterns to be maintained:• The use of the classic 2 phase commit transactions is not recommended• Provide clear API’s with good data integrity even if more than a system is fulfilment them• The new patterns that new to be introduced in an harmonic way in your architecture are:

• CQRS, which requires messaging and events and not always in the same system• Sagas patterns, which requires in turn some properties and capabilities in the participants, as signalling

protocols, local transactions inside every participant, and the capability to combine HTTP and messaging in some situations

• Streaming, to change the blocking transaction paradigm to a stream of events• Domain events, to create new patterns in functionality and process composition

• Those patterns requires a lot of effort to be done correctly in you have legacy, but need to be done if you want to evolve your current situation

• WSO2 lightweight ESB have been absolutely key to provide the adaptations between new and classic systems, thanks to its unique capabilities to mix transport and protocols seamlessly (messaging, HTTP, REST, SOAP, JSON), and provide a way to unify the behaviour in the integrity of information in your overall landscape

16

Some advantages of WSO2 ESB after 2 years

• Deployed in mission critical scenarios: WSO2 ESB has demonstrated to be solid as a rock, fast and very flexible accepting loads thanks to its NIO model

• It has a very low TCO and support is really worth to pay• It’s true lightweight and very efficient and installations can handle thousands of request per second with only

few very low end virtual machines• The latency added per request is usually very low, just few milliseconds in our use cases• Incredible flexibility and extensibility, apart from the out of the box features (for example, REDIS integration). It

is fully integrated in our development lifecycle seamlessly • The stability patterns included have been very valuable specially with legacy (circuit breaker, failover groups,

message stores)• OSGI foundation is key with complex scenarios, in which transitive library dependencies of some home made

connectors could be very difficult to manage• The included registry has been very useful to include parametrization in deployments

17

The load was increased x4 times in production,

latency times in the ESB were not affected

Some lessons learned

• To get all the potential of the product, deep knowledge of it is required, even how it manages interaction in complex scenarios (i.e. multiple backend fails, congested networks, etc)

• In corner situations, some bugs appeared (v4.8.1), solved with support, use the latest version if possible is highly recommended

• A better semantics working with clones and aggregates is needed• Try to maintain your own class mediators and connectors under control, as the

complexity to deploy them is higher and requires Apache Felix tools to deploy them as true OSGI bundles. The deployment of those artefacts requires restarting, also.

• Use JMX and health checks to monitor its state and endpoint suspension• Include clear templating system for traceability, monitoring and logging and

avoid big .car files to allow the teams to deploy their own API’s after approval• Use axis2 modules in key aspects to maintain them under control, no matter the

development artefact (for example, security) in open development scenarios• Define clearly your common message and its properties as well as the default

flow to manage the messages

18

Main Ideas

• Design for change. Consider hybrid approaches depending on your current situation

• Don´t get trap in oversimplifications, any approach have advantages and drawbacks and be fair analysing them

• In our experience, a lightweight ESB as WSO2 is a key component to evolve an architecture inside an hybrid approach• WSO2 ESB: With its superb-solid, fast NIO approach and its beautiful and extensible

simple design, it can be deployed in a lot of scenarios even participating as if were a peer-to-peer component

• New patterns are needed in new architectures, WSO2 ESB helped us to tackle them in multiple scenarios

• One of the main advantages of WSO2 ESB is to use it as a API Gateway, totally integrated with your development lifecycle, and offering a very good performance and flexibility

• Know the product and its behaviour specially in use cases when network or other systems are failing to tune it correctly

19

Thanks

20