Upload
andrei-rugina
View
398
Download
0
Tags:
Embed Size (px)
Citation preview
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
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.
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