µServices Approach in

ING Mobile Banking

11th of June 2015

www.ing.ro

Agenda

2

ING Internet/Mobile Banking evolution

µServices Architecture: External and Internal Structure

Modularity for solving the complexity problem raised by µServices

ING Internet & Mobile Banking Evolution

2010

Internetics: Webvertiser of the

Year

2011

Finmedia Awards: Bank of the Year in

Remote Electronic Payments Services

2012

No-Cash Awards: Premier of the

Year: Bank Payments Solution

2014

Finmedia Awards: Special Performance in

Online Banking Services & Bank of the

Year in Mobile and Internet Banking

ING Internet and Mobile Banking Evolution

4

Launch of Internet

Banking

based on

BTT (Action/

Push-based web

framework)

Migration project

from

BTT to a

new Spring Web

Flow + JSF

based platform

Mobile Banking

Release – hybrid

architecture

based on an in-

house developed

native wrapper

Home’Bank 3.0

based on

AngularJS SPA

and REST

services

ING Bazar, offer

management and

mobile payments

subsystem of

Home’Bank

April 2006 June 2009 March 2012 July 2014 November 2014 Thinking of tomorrow

The Future is

µServices

Architecture

Launch of Internet

Banking

based on

BTT (Action/ Push-

based web

framework)

Migration project

from

BTT to a

new Spring Web

Flow + JSF

based platform

Mobile Banking

Release – hybrid

architecture

based on an in-

house developed

native wrapper

Home’Bank 3.0

based on

AngularJS SPA

and REST

services

µServices Architecture: External Structure

5

Decomposing application into loosely coupled services:

- Explicit contract/interface

- Boundary alignment with business capabilities

- Asynchronous communication between µServices

- µServices have their own storage (they are the authoritative source of data for their domain)

1

2

3 4

1

2

3

4

Benefits:

• Agility in development

• Resilience in production

• µServices can be scaled independently

• µServices can be deployed independently (different deployment options should be made available by the architecture).

• Failures in a µService can be isolated from other µServices

µServices Achitecture: Event Bus

6

Synchronous communication introduces strong coupling between parties, performance and availability risks. µServices communicate asynchronously by exchanging events over Pub/Sub messaging:

- Events capture the state changes in the domain

- Replication of data subset between modules

using events

- Transactional consistency within a module

- Eventual consistency between modules

- Routing logic based on Apache Camel

integration framework.

1

2

3

4

5

1

3

5

2 4

Benefits:

• Temporal decoupling

• µServices no longer depend on each other’s availability

• Business analytics (by capturing the history of business events)

µServices Architecture: Internal Structure

7

Hexagonal Architecture (named also Ports &

Adapters or Onion or Clean or Boundary/

Controller/ Entity Architecture)

Separation of business concerns from

technological concerns

Frameworks are implementation details

Deployment options are build time

details

How?

Apply DIP at domain boundaries

DIP: Dependency Inversion Principle

8

Deployment options should be details

Flexibility Adaptable to context Deployment drivers

The architecture

should be

adaptable to many

contexts.

9

Deployment options address the

current infrastructure, but the

architecture should support many

of them.

Ideally the decision regarding the

deployment option is deferred

until build time.

The deployment is driven by

the tradeoff between the non-

functional requirements

(availability, resilience) and

the costs:

- one µService per VM or

Docker Image

- one µService per JVM

- multiple µServices per

WAR, per application server

- Etc.

Deployment options (contd.)

10

N.B. Docker is efficient both in terms of costs and isolation, but the emphasis is on the flexibility offered by a proper modular architecture.

The other side of µServices: Modules - the intermediate

granularity level

11

µServices

Unit of inter-process reuse

Modules (jar files or

.NET assemblies Unit of release

Namespaces (.NET)

or

Packages (Java)

Classes

Unit of compilation

Methods and

variables

gran

ularity

The same concerns (high cohesion, low coupling, separation of concerns etc.) apply at all levels.

Managing Complexity at µService level

12

The need for structural modularity

13

To be able to react quickly and cheaper in response to business changes, we need to manage the dependencies at module layer as well. Fundamentally a µService is a logical construct responsible for the data and logic of a business capability. It needs to support multiple deployment options (in-process, separate process, separate machine/container) wherever we need to deploy its functionality.

Functional decomposition into µServices for

achieving agility is not enough.

We need structural modularity

Structural modularity

14

Hierarchy

Each level of granularity

is composed of

elements from the

layers below it.

For each level the

dependencies

between elements are

expressed in terms of

level-specific

interfaces (in terms of

requirements and

capabilities).

Abstraction Isolation

14

Within each level the

internal structure of

an element is

isolated/protected

from external access.

Versioning

Elements can be

versioned in order to

support change.

Evolutionary steps in the direction of mature modularity

1 2

3 4

Creation of modules

Module dependency management

Modules encapsulation

Module dynamism

Dependencies on packages

exported by other modules.

Modules are isolated form each

other by having public and

private packages and dedicated

class loaders.

The modules can be

upgraded/replaced on the fly

without downtime.

15

Dependencies on other modules’

identity (Maven style)

transitive dependencies problem

„jar hell” problem

Minimizing coupling between

modules by applying modularity

patterns and enforcing the desired

dependencies.

• Modularity solves the complexity problems raised by µServices

Questions & Answers

16