The role of Containerization in the Enterprise Content ... role of Containerization in the...
Transcript of The role of Containerization in the Enterprise Content ... role of Containerization in the...
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