The role of Containerizat ion in the Enterprise Content Management Roadmap

Barcelona November, 2016

Dennis Buis Enterprise Architect

2

Topics

Containerizing in the ECM landscape

• Introduction to (the strategy of) ING

• ING Strategy for ECM

• ING Vision on Docker for ECM

Int roduct ion to (t he st rategy of) ING

3

• ING is a global f inancial inst it ut ion with a strong European

base, offering banking services through its operating

company ING Bank and holding a significant stake in the

listed insurer NN Group N.V. The purpose of ING Bank is

empowering people to stay a step ahead in life and in

business. ING Bank’s more than 52,000 employees offer

retail and wholesale banking services to customers in over

40 count ries.

• ING Group shares are listed (in the form of depositary

receipts) on the exchanges of Amsterdam (INGA NA,

ING.AS), and Brussels and on the New York Stock Exchange

(ADRs: ING US, ING.N).

About ING

4

• Sustainability forms an integral part of ING’s corporate

strategy, which is evidenced by ING Group shares being

included in the FTSE4Good index and in the Dow Jones

Sustainability Index (Europe and W orld), where ING is among

the leaders in the Banks industry group.

• At end 2015, our colleagues served more than 34 million

customers.

The ING snapshot captures our most

important facts & figures and more

detailed information can be found on

ING.com

5

1. Earn the primary relationship

2. Develop analytics skills to understand our customers better

3. Increase the pace of innovation to serve changing customer needs

4. Think beyond traditional banking to develop new services and business models

Empowering people to stay a step ahead in life and in business.

Simplify & Streamline

Operational Excellence

Performance Culture

Lending Capabilities

Purpose

Customer Promise

St rategic Priorit ies

Enablers

Creat ing a dif ferent iat ing customer experience

Clear and Easy Anytime, Anywhere Empower Keep Getting Better

ING St rategy for ECM

6

Customer Dossier

Compose communication

Lines of Business

“Capture at the Gate”

Mobile inbox

Direct access to Customer dossier

“Print at the Exit”

Digital Correspondence

xPression

Documentum

7

InfoArchive

Functional Overview: ECD products used by ING supporting the digital journey

Today’s Sit uat ion: The decision to follow a replicated operat ing model has led to a number of large individual Documentum based environments

iv.

Three large environments (plus multiple small ones) 1. Supporting Domestic Netherlands (approx. 10K users) 2. Supporting Domestic Belgium (approx. 5K users) 3. Supporting W holesale Banking (approx. 10K users) Key f inding The TCO of the ECM platform (Documentum, xCP, xPression & Captiva) within ING is (unacceptable) high due to following causes: P1: mandatory yearly LCM activities P2: lack of infra standardization across data centers P3: lack of continuous delivery capabilities P4: migration effort (xCP compatibility ) Recommendat ions 1. Operate from a single Common Core build 2. Operate from a single Data Center Group

3. Common Core Support from a cent ral DevOps team

4. Improve via simplify & automate

(Continuous Deliver pipeline on standardized platform)

= move from a replicated approach to a shared approach

New St rategy: Impact of going from current model (shared design / mult iple builds) t o t arget model (single build / shared instance)

Current Operat ing Model = Replicated (shared contract + shared design) Target Operat ing Model = Shared-1 (shared instance + shared services)

iv.

IPC

Document Management(standard = Documentum)

Legal Archive(candidate = EMC InfoArchive)

Federated Search(candidate = ElasticSearch)

Dossier Management(standard = Documentum)

Business Process

Converge from a replicated setup to a

shared-1 implementation

Prio 1: Converge from a replicated setup to

a shared-1 implementation

Prio 4: Stop archiving in Documentum, move immutable

content to Archiving solution

Prio 3: urgent need for central solution to

support search content across

multiple repositories (operational +

archives)

Prio 2: urgent need for central solution to

support long term archiving

(for both structured & unstructured data)

Co-Creation ECD & ING “How-To

InfoArchive on Docker”

ECM Roadmap: Priorit y set t ing Enterprise Content Management

ING Vision on Docker for ECM

11

Docker

Docker containers wrap software in a complete files system that contains everything needed to run: code, runtime, system tools and system libraries. This guarantees

that the software will always run the same, regardless of its environment. Docker is different from hypervisor based virtualization: hypervisors run different operating

systems, Docker images run on the same operating system host sharing the same operating system kernel.

Docker should be used when there is a clear advantage for using Docker, t ypical use-cases:

• For lightweight, stateless, immutable, easily scalable applications

• To setup local development environments that represent server-like deployments

• Create mini-representations of application-chains for development / test

• To support vendor software, when Docker-images are the software delivery model from the vendor

Container Management f rameworks (immature market / not enterprise ready)

• Container management frameworks provide capabilities on top of (Docker) containers for deployment, (auto)-scaling, load-balancing, monitoring, etc.

• Managing such a framework comes at a cost, should only be implemented when required and therefore considered on a case-by-case basis

• Container management frameworks will be implemented replicated per application or application domain

• Kubernetes as the current front-runner in comparison with Swarm and Mesos/Marathon

12

Int roduct ion on Docker@ING: Various use cases are recognized for ING as indicated by ING Docker pioneers and derived from front runner implementat ions

primary focus of t his

presentat ion

In the Docker based softwarendelivery model the software supplier get more responsibilities in the software stack, e.g. from a: Life cycle management perspective (application + middleware) Patching perspective (application + middleware) Software stack integration perspective (application + middleware)

Updates of the container are expected to be delivered (with a high frequency) by the supplier as:

Preferred: Pre-build Docker image (e.g. via a private Docker hub) Alternative: Software components + Docker build instruction

The overall IT stack dependencies between the solution provider and the hosting provider will be reduced to:

1. The (minimal) version of the Docker engine 2. The (minimal) version of the Linux kernel

Compared with InfoArchive software requirements in a traditional setup: Windows Server 2012 x64 <or> RHEL 7.x x64 <or> CentOS 7.x Oracle Java 8 +JCA Apache TomCat 8.0.32

13

Impact on Vendor Software: The container based delivery model shif t s a signif icant part of t he responsibilit y of t he IT stack to t he provider of t he product

responsibilit y of software supplier

responsibilit y of software supplier

responsibilit y of ING

responsibilit y of ING

Bins/Libs

App A

Hypervisor

Server

App B

Bins/Libs

Bins/Libs

App A App B

Bins/Libs

Guest OS Guest OS

Server

Hypervisor

Server Server

Guest OS Guest OS

Docker Engine

Docker Engine

trad

itio

nal a

ppro

ach

cont

aine

r app

roac

h

14

Docker Securit y ING needs to establish a sound security baseline for running Docker containers. Groundwork in that area has already been performed within ING. But there are concerns that need to be addressed. Concerns How to solve

Host and Docker engine securit y 1. Docker must be installed and configured according to industry hardening guidelines, and containers must only run with those (kernel) privileges explicitly needed. There are well accepted indust ry guidelines for this.

2. Optional, you can run secured Docker ready OS (f.i. RedHat Atomic or CoreOS).

Docker management API securit y 1. Implement addit ional securit y measures through network isolation, additional encryption and authentication methods.

2. Adjust process and management methods.

Development / patching of containers 1. Implement baseline rules for save image development based on industry standards and implement image scanning, automated through CI/CD pipelines.

2. Developers must adapt to new methods of patching; patching must be executed through redeployment . Do not patch containers in production.

3. Do not install unnecessary packages. Keep images small and fit for purpose.

Source of Docker images 1. Govern that only images from t rusted resources or local registries are used. 2. Implement trust and security by image signing. 3. Educate your users / create policies.

Licensed software inside Docker containers 1. Educate users / create policies that using licensed software in container images impact cont ractual agreements and that proper ING instances for procurement/legal should be involved.

2. Create / request clarit y of sof tware vendors for license models in container environment

Today’s Challenge: Before applying Docker in a product ion environment a few concerns need at tent ion

Derived ING Docker Principles (not exhaust ive)

Containers should not contain unnecessary packages Extra packages increase complexity , dependencies, file

sizes, and build times Containers should run only one process Horizontal scaling and container linking is preferred above

complex heavy weight containers Containers should minimize the number of layers Simplified containers support readability and long-term

maintainability Containers should be ephemeral (stateless) State is contained in data-services and should never be

limited to the life span of a container Containers should be immutable (read-only) All protective measures (security scans, access control,

etc.) should be implemented around the containers (i.e. not part of / added to the container)

Containers should always be delivered as part of a (pre-tested) blueprint pat tern

15

InfoArchive on Docker: t he ECD / ING Co-Creat ion Proof of Concept t riggered a discussion on a number of principles

IAWebApp

(stateless container)

IAWebApp

(stateless container)

IAWebApp

(stateless container)

INGAPI

(stateless container)

IA ServerLoad Balancer

(stateless container)

IA WebAppLoad Balancer

(stateless container)

IAServer

(stateless container)

IAServer

(stateless container)

IAServer

(stateless container)

NAS-based Storage(stateful / traditional)

xDB Server(stateful / traditional)

The InfoArchive on Docker pat tern should support spinning up ext ra containers for a short period of t ime

rationale: instant (up/down) scaling helps to handle peak loads of the environment

The InfoArchive on Docker pat tern should support spreading a large ingest ion across mult iple containers

rationale: horizontal scaling is preferred above vertical scaling (that is restricted to certain boundaries)

The InfoArchive on Docker pat ter should support prevent downt ime during upgrade act ions (in case of a 24/7 A4 rated environment )

rationale: 24/7 A4 is a recognized ING pattern (not determined yet if this is a hard requirement for the (legal) archive)

The InfoArchive on Docker pat tern should support init ial archive creat ion (using Ant ) in a separate dedicated (read-only) container

rationale: containers should be immutable and support dedicated functionality (and allows spinning down when not needed)

The InfoArchive on Docker pat tern should not be based on hard coded connect ions

rationale: the pattern should be (instant) scalable with flexible connectivity (e.g. based on auto service discovery)

16

InfoArchive on Docker: ING feature wish list result ing of t he Docker PoC experiences so far (under discussion / work in progress)

Thank you

17