The role of Containerization in the Ent erprise Content Management Roadmap

Transcription

1 The role of Containerization in the Ent erprise Content Management Roadmap Dennis Buis Enterprise Architect Barcelona November, 2016

2 Topics Containerizing in the ECM landscape Introduction to (the strategy of) ING ING Strategy for ECM ING Vision on Docker for ECM 2

3 3 Introduction to (the strategy of) ING

4 About ING ING is a global financial institution 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 countries. 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 World), where ING is among the leaders in the Banks industry group. At end 2015, our colleagues served more than 34 million cust omers. 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). The ING snapshot captures our most important facts & figures and more detailed information can be found on ING.com 4

5 Purpose Empowering people to stay a step ahead in life and in business. Cust om er Promise Clear and Easy Anytime, Anywhere Empower Keep Getting Better Strategic Priorities Creat ing a different iat ing cust omer experience 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 Enablers Simplify & Streamline Operational Excellence Performance Culture Lending Capabilities 5

6 6 ING Strategy for ECM

7 Functional Overview: ECD products used by ING supporting the digital journey Print at the Exit Capture at the Gate Mobile inbox Compose communication Documentum Lines of Business Direct access to Customer dossier Digital Correspondence xpression Customer Dossier InfoArchive 7

8 Today s Situation: The decision to follow a replicated operating model has led to a number of large individual Documentum based environments Three large environment s (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 finding 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) Recommendations 1. Operate from a single Common Core build 2. Operate from a single Data Center Group 3. Common Core Support from a central DevOps t eam 4. Improve via simplify & automate (Continuous Deliver pipeline on standardized platform) = move from a replicated approach to a shared approach iv.

9 New St rat egy: Impact of going from current model (shared design / multiple builds) to target model (single build / shared instance) Current Operating Model = Replicat ed (shared contract + shared design) Target Operating Model = Shared-1 (shared instance + shared services) iv.

10 ECM Roadmap: Priorit y set t ing Ent erprise Cont ent Management Prio Converge 1: Converge from from a a replicated setup to to a a shared-1 implementation Dossier Management (standard = Documentum) Business Process Federated Search (candidate = ElasticSearch) Prio 3: urgent need for central solution to support search content across multiple repositories (operational + archives) Co-Creation ECD & ING How-To InfoArchive on Docker Prio 4: Stop archiving in Documentum, move immutable content to Archiving solution Document Management (standard = Documentum) Legal Archive (candidate = EMC InfoArchive) Prio 2: urgent need for central solution to support long term archiving (for both structured & unstructured data) IPC

11 11 ING Vision on Docker f or ECM

12 Introduction on Various use cases are recognized for ING as indicated by ING Docker pioneers and derived from frontrunner implementations 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, typical 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 primary focus of this present at ion To support vendor software, when Docker-images are the software delivery model from the vendor Container Management frameworks (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

13 Impact on Vendor Software: The container based delivery model shifts a significant part of the responsibility of the IT stack to the provider of the product traditional approach App A Bins/Libs Guest OS Server Hypervisor App B Bins/Libs Guest OS Server responsibility of software supplier responsibility of ING 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 container approach App A Bins/Libs Docker Engine Guest OS Server Hypervisor App B Bins/Libs Docker Engine Guest OS Server responsibility of soft ware supplier responsibility of ING 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> Cent OS 7.x Oracle Java 8 +JCA Apache Tom Cat

14 Today s Challenge: Before applying Docker in a production environment a few concerns need attention Docker Security 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 industry 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 additional security 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 pipel ines. 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 rust ed resources or local registries are used. 2. Implement trust and security by image signing. 3. Educate your users / create policies. Licensed soft ware inside Docker containers 1. Educate users / create policies that using licensed software in container images impact contractual agreements and that proper ING instances for procurement/legal should be involved. 2. Create / request clarity of software vendors for license models in container environment 14

15 InfoArchive on Docker: t he ECD / ING Co-Creation Proof of Concept t riggered a discussion on a number of principles IA WebApp Load Balancer Derived ING Docker Principles (not exhaustive) Containers should not contain unnecessary packages IA WebApp IA WebApp IA WebApp ING API 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 IA Server Load Balancer Containers should minimize the number of layers Simplified containers support readability and long-term maintainability Containers should be ephemeral (stateless) IA Server IA Server IA Server State is contained in data-services and should never be limited to the life span of a container Containers should be immutable (read-only) xdb Server (stateful / traditional) NAS-based Storage (stateful / traditional) 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 pattern 15

16 InfoArchive on Docker: ING feature wish list resulting of the Docker PoC experiences so far (under discussion / work in progress) The InfoArchive on Docker pattern should support spinning up extra containers for a short period of time rationale: instant (up/down) scaling helps to handle peak loads of the environment The InfoArchive on Docker pattern should support spreading a large ingestion across multiple containers rationale: horizontal scaling is preferred above vertical scaling (that is restricted to certain boundaries) The InfoArchive on Docker patter should support prevent downtime during upgrade actions (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 pattern should support initial archive creation (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 pattern should not be based on hard coded connections rationale: the pattern should be (instant) scalable with flexible connectivity (e.g. based on auto service discovery) 16

17 17 Thank you