On Recent Advances on Stateful Orchestrated Container Reliability

Total Page:16

File Type:pdf, Size:1020Kb

On Recent Advances on Stateful Orchestrated Container Reliability On Recent Advances on Stateful Orchestrated Container Reliability Kęstutis Pakrijauskas Dalius Mažeika Faculty of Fundamental Science Faculty of Fundamental Science Vilnius Gedinimas Techincal University Vilnius Gedinimas Techincal University Vilnius, Lithuania Vilnius, Lithuania [email protected] [email protected] Abstract— Thanks to its flexibility and light weight, containers there is no risk of data loss, and recreation of the failing are becoming the primary platform to run microservices. component is a small deal. However, it is a different matter with Container orchestration frameworks – Kubernetes or Docker stateful microservices that deal with data. State is “a sequence Swarm – enable companies to stay on competitive edge by keeping of values in time that contain the intermediate results of a the velocity of code deploys high. While containers are ideal for desired computation.” [6]. The state makes deployment, stateless workloads, using orchestrated containers for stateful management, scaling, replication a complex engagement. State services is an option too. Being a commodity and crucial to any has to be synchronized across multiple replicas in a business, state or, in other words, data has to be protected and be microservice. Recovering a stateful microservice is not a trivial available. This research raises questions on what the reliability matter. Solid backup recovery strategy, replication, sharding, challenges of running stateful microservices are, and what are the recent approaches to increase reliability of stateful services in etc. may not be enough to ensure high reliability on stateful orchestrated container systems. A literature review was microservices. Inter-service state consistency of data may be performed to answer the questions. violated if a single microservice was recovered to an earlier state. Data of seemingly healthy stateful microservice can be Keywords—microservices, containers, Kubernetes, stateful, corrupted, thus triggering a restore or rollback operation. failure, availability, review Migration to a healthier node in the platform is a challenge with stateful microservices as well because of its resource intensive I. INTRODUCTION and potentially disrupting nature. Software and technology are the key in transforming organizations and delivering value to stakeholders and customers in modern times [1]. Success of business closely depends on whether or not its systems are running at the desired state. Microservices, an implementation of Service-Oriented Architecture, allows companies to keep up with the demand to scale and roll new services out [2]. Challenges of running microservice-based application are different compared to monolithic application: monitoring, recovery, and load balancing, etc. Data or state is an asset of any business. Modern systems becoming highly complex and of high scale according to DevOps report 2018 [3] and 2019 [4]. High system reliability is a concern. Thus, enterprises, such as Google [5], build their systems with resilience and reliability in mind. Components of microservices should be engineered, prepared Fig. 1. Comparison of monolith and microservice architectures for failure instead of attempting to ensure that no components fail. Microservices and entire system should be tolerant to Container orchestration frameworks, such as Kubernetes, failures, able to recover quickly [2], [11]. Downtime of Docker Swarm, or Mesos, were developed for [7]. Such tools microservice based systems is decreased if microservice returns allow to automate and abstract different microservices back online in a timely manner. management tasks like service discovery, storage orchestration, rollout and rollback, resilience [8]. It is important to evaluate A stateless service is limited to its function – its output reliability of applications running in container orchestration depends on its input. Recovery of stateless microservices systems given their capabilities of running microservices. components is straight forward – its components are ephemeral, XXX-X-XXXX-XXXX-X/XX/$XX.00 ©20XX IEEE Reliability is commonly defined as “The probability that an performed using guidelines defined by Kitchenham and Chaters item will perform a required function without failure under [13]. The search was limited to digital libraries and search stated conditions for a stated period of time.”[9]. Mathematical engines on the Internet. The search used the following terms: and statistical methods are used to quantify reliability. However, “stateful microservice” OR “stateful container orchestration” uncertainty too great in practice or reliability to be calculated. OR “microservice database” OR “container database” OR Reliability became an important effectiveness parameter as cost “microservice fault” OR “container fault”. Further studies were and complexity of systems increases. According to ISO/IEC identified by examining references in included articles. 25010 standard, reliability is a characteristic of systems and software product quality model. This paper aims to discover II. CHALLENGES SUBJECT TO STATEFUL MICROSERVICES approaches applicable to stateful microservices to satisfy the A. Federated Multidatabase sub-characteristics of reliability as described in the standard [10]: Fine-grained microservices are developed and operated by independent teams. Each microservices can be independently • maturity: degree to which a system, product or deployed and scaled. Stateful services rely on their own component meets needs for reliability under persistent storage mechanism. To reduce coupling, integration normal operation at storage level, i.e., using one data storage mechanism, like database, tends to be avoided. Interaction between microservices • availability: degree to which a system, product or should be limited to APIs. However, as there is no guarantee that component is operational and accessible when a link to retrieve records from another microservice is valid, required for use consistency becomes a challenge [14]. • fault tolerance: degree to which a system, product Microservices, being autonomous and independently or component operates as intended despite the deployed, may store data on a variety of platforms. Each presence of hardware or software faults microservice stores persistent data on its own private database. • recoverability: degree to which a system, product This data is accessible to other services only via API. or component operates as intended despite the Relationships to other entities in REST architecture are presence of hardware or software faults expressed as URI links. URI is Uniform Resource Identifier that globally addresses the referenced entities. Lifecycle of A prerequisite to reliability evaluation is setting the standard microservices is independent, thus databases are backed up of performance. The standard of performance is defined by periodically and independently. In case of recovery, links Service Level Agreement (SLA), Service Level Objectives between microservices may be broken due to inconsistent state (SLO) and Service Level Indicators (SLI) [12]. of microservices after data was restored from a backup on one SLI is a defined quantitative measure of an aspect of the level of them [15]. of a service. An SLO is the target range or value of SLIs. Setting Microservice architecture is designed to survive its SLO is important to evaluate reliability as it adds transparency individual components failing. Stateless and stateful services and understanding whether the level of a service meets the can be recovered independently. As data in stateful services can expectations or not. An SLA is an agreement with users on what be recovered from a backup, there is a question whether the to do with the service if it is not performing within the SLO. restored data is consistent with the data on other microservices. Having an established service health baseline and solid The challenge is ensuring data consistency among multiple prediction on what is to happen with a microservice is not microservices, how and when perform backup operations [14]. enough. Orchestrated container systems have a rich selection of Databases of microservices can be seen as a federated settings and techniques that can be used to increase microservice multidatabase – a hybrid between centralized and distributed reliability by taking a data-driven decision or detecting faults. database system. A database that is distributed for global users This paper aims to summarize the available information on and centralized for local users. Each microservice treats its studies related to reliability of stateful microservices in database as a centralized one, ensuring its durability and orchestrated container systems. The research questions are: consistency [15]. However, managing its consistency as a challenge because of distributed persistence. Foreign key • RQ1: How and what kind of data can be used to relationships between databases of different microservices are make data-driven decision on microservice represented as loosely coupled references like URI. There is no reliability in orchestrated container systems? guarantee that a retrieved URI points to a valid record in another microservice. • RQ2: What are the recent data-driven methods used to increase or predict stateful microservice Although backup of individual microservices can be reliability? successfully used for independent recovery, it is likely that its state will not be consistent with the state of the application. For
Recommended publications
  • Kubernetes Security Guide Contents
    Kubernetes Security Guide Contents Intro 4 CHAPTER 1 Securing your container images and CI/CD pipeline 6 Image scanning 6 What is image scanning 7 Docker image scanning open source tools 7 Open source Docker scanning tool: Anchore Engine 8 Securing your CI/CD pipeline 9 Image scanning in CI/CD 10 CHAPTER 2 Securing Kubernetes Control Plane 14 Kubelet security 14 Access to the kubelet API 15 Kubelet access to Kubernetes API 16 RBAC example, accessing the kubelet API with curl 16 Kubernetes API audit and security log 17 Audit log policies configuration 19 Extending the Kubernetes API using security admission controllers 20 Securing Kubernetes etcd 23 PKI-based authentication for etcd 23 etcd peer-to-peer TLS 23 Kubernetes API to etcd cluster TLS 24 Using a trusted Docker registry 24 Kubernetes trusted image collections: Banning non trusted registry 26 Kubernetes TLS certificates rotation and expiration 26 Kubernetes kubelet TLS certificate rotation 27 Kubernetes serviceAccount token rotation 28 Kubernetes user TLS certificate rotation 29 Securing Kubernetes hosts 29 Kubernetes 2 Security Guide Using a minimal host OS 30 Update system patches 30 Node recycling 30 Running CIS benchmark security tests 31 CHAPTER 3 Understanding Kubernetes RBAC 32 Kubernetes role-based access control (RBAC) 32 RBAC configuration: API server flags 34 How to create Kubernetes users and serviceAccounts 34 How to create a Kubernetes serviceAccount step by step 35 How to create a Kubernetes user step by step 37 Using an external user directory 40 CHAPTER 4 Security
    [Show full text]
  • Running Legacy VM's Along with Containers in Kubernetes!
    Running Legacy VM’s along with containers in Kubernetes Delusion or Reality? Kunal Kushwaha NTT Open Source Software Center Copyright©2019 NTT Corp. All Rights Reserved. About me • Work @ NTT Open Source Software Center • Collaborator (Core developer) for libpod (podman) • Contributor KubeVirt, buildkit and other related projects • Docker Community Leader @ Tokyo Chapter Copyright©2019 NTT Corp. All Rights Reserved. 2 Growth of Containers in Companies Adoption of containers in production has significantly increased Credits: CNCF website Copyright©2019 NTT Corp. All Rights Reserved. 3 Growth of Container Orchestration usage Adoption of container orchestrator like Kubernetes have also increased significantly on public as well private clouds. Credits: CNCF website Copyright©2019 NTT Corp. All Rights Reserved. 4 Infrastructure landscape app-2 app-2 app-M app-1 app-2 app-N app-1 app-1 app-N VM VM VM kernel VM Platform VM Platform Existing Products New Products • The application infrastructure is fragmented as most of old application still running on traditional infrastructure. • Fragmentation means more work & increase in cost Copyright©2019 NTT Corp. All Rights Reserved. 5 What keeps applications away from Containers • Lack of knowledge / Too complex to migrate in containers. • Dependency on custom kernel parameters. • Application designed for a custom kernel. • Application towards the end of life. Companies prefer to re-write application, rather than directly migrating them to containers. https://dzone.com/guides/containers-orchestration-and-beyond Copyright©2019 NTT Corp. All Rights Reserved. 6 Ideal World app-2 app-2 app-M app-1 app-2 app-N app-1 app-1 app-N VM VM VM kernel VM Platform • Applications in VM and containers can be managed with same control plane • Management/ Governance Policies like RBAC, Network etc.
    [Show full text]
  • Ovirt and Docker Integration
    oVirt and Docker Integration October 2014 Federico Simoncelli Principal Software Engineer – Red Hat oVirt and Docker Integration, Oct 2014 1 Agenda ● Deploying an Application (Old-Fashion and Docker) ● Ecosystem: Kubernetes and Project Atomic ● Current Status of Integration ● oVirt Docker User-Interface Plugin ● “Dockerized” oVirt Engine ● Docker on Virtualization ● Possible Future Integration ● Managing Containers as VMs ● Future Multi-Purpose Data Center oVirt and Docker Integration, Oct 2014 2 Deploying an Application (Old-Fashion) ● Deploying an instance of Etherpad # yum search etherpad Warning: No matches found for: etherpad No matches found $ unzip etherpad-lite-1.4.1.zip $ cd etherpad-lite-1.4.1 $ vim README.md ... ## GNU/Linux and other UNIX-like systems You'll need gzip, git, curl, libssl develop libraries, python and gcc. *For Debian/Ubuntu*: `apt-get install gzip git-core curl python libssl-dev pkg- config build-essential` *For Fedora/CentOS*: `yum install gzip git-core curl python openssl-devel && yum groupinstall "Development Tools"` *For FreeBSD*: `portinstall node, npm, git (optional)` Additionally, you'll need [node.js](http://nodejs.org) installed, Ideally the latest stable version, be careful of installing nodejs from apt. ... oVirt and Docker Integration, Oct 2014 3 Installing Dependencies (Old-Fashion) ● 134 new packages required $ yum install gzip git-core curl python openssl-devel Transaction Summary ================================================================================ Install 2 Packages (+14 Dependent
    [Show full text]
  • Openicra : Vers Un Modèle Générique De Déploiement Automatisé Des Applications Dans Le Nuage Informatique
    ÉCOLE DE TECHNOLOGIE SUPÉRIEURE UNIVERSITÉ DU QUÉBEC MÉMOIRE PRÉSENTÉ À L’ÉCOLE DE TECHNOLOGIE SUPÉRIEURE COMME EXIGENCE PARTIELLE À L’OBTENTION DE LA MAÎTRISE EN GÉNIE CONCENTRATION : RÉSEAUX DE TÉLÉCOMMUNICATIONS M. Ing. PAR Ridha GADHGADHI OPENICRA : VERS UN MODÈLE GÉNÉRIQUE DE DÉPLOIEMENT AUTOMATISÉ DES APPLICATIONS DANS LE NUAGE INFORMATIQUE MONTRÉAL, LE 6 SEPTEMBRE 2013 ©Tous droits réservés, Ridha Gadhgadhi, 2013 II ©Tous droits réservés Cette licence signifie qu’il est interdit de reproduire, d’enregistrer ou de diffuser en tout ou en partie, le présent document. Le lecteur qui désire imprimer ou conserver sur un autre media une partie importante de ce document, doit obligatoirement en demander l’autorisation à l’auteur. PRÉSENTATION DU JURY CE MÉMOIRE A ÉTÉ ÉVALUÉ PAR UN JURY COMPOSÉ DE : M. Mohamed Cheriet, directeur de mémoire Département de génie de la production automatisée à l’École de technologie supérieure M. Stéphane Coulombe, président du jury Département de génie logiciel et des TI à l’École de technologie supérieure M. Chamseddine Talhi, membre du jury Département de génie logiciel et des TI à l’École de technologie supérieure M. Ali Kanso, examinateur externe Ericsson Research, Ericsson Inc. IL A FAIT L’OBJET D’UNE SOUTENANCE DEVANT JURY ET PUBLIC LE 23 AOÛT 2013 À L’ÉCOLE DE TECHNOLOGIE SUPÉRIEURE REMERCIEMENTS Je tiens tout d’abord à remercier chaleureusement mon directeur de recherche, le professeur Mohamed Cheriet, pour son expertise, ses conseils et son soutien inconditionnel. Je remercie aussi Mathieu Lemay d’Inocybe Technologies Inc. pour ses conseils techniques. Je tiens à remercier tous les membres du jury de m'avoir fait l'honneur d'accepter de juger mon mémoire : • Monsieur Stéphane Coulombe, de l’ÉTS, Université du Québec; • Monsieur Chamseddine Talhi, de l’ÉTS, Université du Québec; • Monsieur Ali Kanso, d’Ericsson Montréal, Canada.
    [Show full text]
  • High Availability in Clouds: Systematic Review and Research Challenges Patricia T
    Endo et al. Journal of Cloud Computing: Advances, Systems Journal of Cloud Computing: and Applications (2016) 5:16 DOI 10.1186/s13677-016-0066-8 Advances, Systems and Applications REVIEW Open Access High availability in clouds: systematic review and research challenges Patricia T. Endo1,2*, Moisés Rodrigues2, Glauco E. Gonçalves2,3, Judith Kelner2, Djamel H. Sadok2 and Calin Curescu4 Abstract Cloud Computing has been used by different types of clients because it has many advantages, including the minimization of infrastructure resources costs, and its elasticity property, which allows services to be scaled up or down according to the current demand. From the Cloud provider point-of-view, there are many challenges to be overcome in order to deliver Cloud services that meet all requirements defined in Service Level Agreements (SLAs). High availability has been one of the biggest challenges for providers, and many services can be used to improve the availability of a service, such as checkpointing, load balancing, and redundancy. Beyond services, we can also find infrastructure and middleware solutions. This systematic review has as its main goal to present and discuss high available (HA) solutions for Cloud Computing, and to introduce some research challenges in this area. We hope this work can be used as a starting point to understanding and coping with HA problems in Cloud. Keywords: Cloud computing, High availability, Systematic review, Research challenges Introduction in $336,000 less revenue per hour. Paypal, the online pay- Cloud Computing emerged as a novel technology at the ment system, experiences in a revenue loss of $225,000 end of the last decade, and it has been a trending topic ever per hour.
    [Show full text]
  • Container and Kernel-Based Virtual Machine (KVM) Virtualization for Network Function Virtualization (NFV)
    Container and Kernel-Based Virtual Machine (KVM) Virtualization for Network Function Virtualization (NFV) White Paper August 2015 Order Number: 332860-001US YouLegal Lines andmay Disclaimers not use or facilitate the use of this document in connection with any infringement or other legal analysis concerning Intel products described herein. You agree to grant Intel a non-exclusive, royalty-free license to any patent claim thereafter drafted which includes subject matter disclosed herein. No license (express or implied, by estoppel or otherwise) to any intellectual property rights is granted by this document. All information provided here is subject to change without notice. Contact your Intel representative to obtain the latest Intel product specifications and roadmaps. The products described may contain design defects or errors known as errata which may cause the product to deviate from published specifications. Current characterized errata are available on request. Copies of documents which have an order number and are referenced in this document may be obtained by calling 1-800-548-4725 or by visiting: http://www.intel.com/ design/literature.htm. Intel technologies’ features and benefits depend on system configuration and may require enabled hardware, software or service activation. Learn more at http:// www.intel.com/ or from the OEM or retailer. Results have been estimated or simulated using internal Intel analysis or architecture simulation or modeling, and provided to you for informational purposes. Any differences in your system hardware, software or configuration may affect your actual performance. For more complete information about performance and benchmark results, visit www.intel.com/benchmarks. Tests document performance of components on a particular test, in specific systems.
    [Show full text]
  • Kubernetes As an Availability Manager for Microservice Based Applications Leila Abdollahi Vayghan
    Kubernetes as an Availability Manager for Microservice Based Applications Leila Abdollahi Vayghan A Thesis in the Department of Computer Science and Software Engineering Presented in Partial Fulfillment of the Requirements for the Degree of Master of Computer Science at Concordia University Montreal, Quebec, Canada August 2019 © Leila Abdollahi Vayghan, 2019 CONCORDIA UNIVERSITY SCHOOL OF GRADUATE STUDIES This is to certify that the thesis prepared By: Leila Abdollahi Vayghan Entitled: Kubernetes as an Availability Manager for Microservice Based Applications and submitted in partial fulfillment of the requirements for the degree of Master in Computer Science complies with the regulations of the University and meets the accepted standards with respect to originality and quality. Signed by the final examining committee: ________________________________________________ Chair Dr. P. Rigby ________________________________________________ Internal Examiner Dr. D. Goswami ________________________________________________ Internal Examiner Dr. J. Rilling ________________________________________________ Co-Supervisor Dr. F. Khendek ________________________________________________ Co-Supervisor Dr. M. Toeroe Approved by: ___________________________________ Dr. L. Narayanan, Chair Department of Computer Science and Software Engineering _______________ 2019___ __________________________________ Dr. Amir Asif, Dean, Faculty of Engineering and Computer Science ii ABSTRACT Kubernetes as an Availability Manager for Microservice Based Applications Leila
    [Show full text]
  • Immutable Infrastructure, Containers, & the Future of Microservices
    Immutable infrastructure, containers, & the future of microservices Adam Miller Senior Software Engineer, Red Hat 2015-07-25 What we'll cover in this session ● Define “microservices” ● Define “containers” in the context of Linux systems ● Container Implementations in Linux ● What Immutable Infrastructure is – Example of what Immutable Infrastructure deployment workflow looks like ● Red Hat Enterprise Linux Atomic Host – How RHEL Atomic enables and enhances these concepts ● Kubernetes – Orchestrating the Immutable Infrastructure ● OpenShift – Enabling the development and container building pipeline Microservices Microservices are not entirely new. ● The vocabulary term is “new-ish” (2012 – James Lewis and Martin Fowler) ● The idea is very old – Microkernels have existed since the 1980s – Could argue that system admins have been doing this with shell scripts and pipes for years ● Applying this concept to services higher in Monolithic Kernel Microkernel the stack is a newer trend based Operating System based Operating System – Application Heavily influenced by popular technologies System Call such as web microframeworks and containers. user mode VFS IPC, File System Application UNIX Device File IPC Server Driver Server Scheduler, Virtual Memory kernel mode Device Drivers, Dispatcher, ... Basic IPC, Virtual Memory, Scheduling Hardware Hardware What are Microservices? ● Services, “the UNIX Way” – Do one thing, do it well. – Decouple tightly coupled services, make the architecture more modular. ● Loosely coupled services using programming language agnostic APIs for communication – Example: REST APIs The mythical cloud The mythical cloud Micro services Containers What are containers? ● Operating-system-level Virtualization – We (the greater Linux community) like to call them “containers” ● OK, so what is Operating-system-level Virtualization? – The multitenant isolation of multiple user Traditional OS Containers space instances or namespaces.
    [Show full text]
  • System Design for Telecommunication Gateways
    P1: OTE/OTE/SPH P2: OTE FM BLBK307-Bachmutsky August 30, 2010 15:13 Printer Name: Yet to Come SYSTEM DESIGN FOR TELECOMMUNICATION GATEWAYS Alexander Bachmutsky Nokia Siemens Networks, USA A John Wiley and Sons, Ltd., Publication P1: OTE/OTE/SPH P2: OTE FM BLBK307-Bachmutsky August 30, 2010 15:13 Printer Name: Yet to Come P1: OTE/OTE/SPH P2: OTE FM BLBK307-Bachmutsky August 30, 2010 15:13 Printer Name: Yet to Come SYSTEM DESIGN FOR TELECOMMUNICATION GATEWAYS P1: OTE/OTE/SPH P2: OTE FM BLBK307-Bachmutsky August 30, 2010 15:13 Printer Name: Yet to Come P1: OTE/OTE/SPH P2: OTE FM BLBK307-Bachmutsky August 30, 2010 15:13 Printer Name: Yet to Come SYSTEM DESIGN FOR TELECOMMUNICATION GATEWAYS Alexander Bachmutsky Nokia Siemens Networks, USA A John Wiley and Sons, Ltd., Publication P1: OTE/OTE/SPH P2: OTE FM BLBK307-Bachmutsky August 30, 2010 15:13 Printer Name: Yet to Come This edition first published 2011 C 2011 John Wiley & Sons, Ltd Registered office John Wiley & Sons Ltd, The Atrium, Southern Gate, Chichester, West Sussex, PO19 8SQ, United Kingdom For details of our global editorial offices, for customer services and for information about how to apply for permission to reuse the copyright material in this book please see our website at www.wiley.com. The right of the author to be identified as the author of this work has been asserted in accordance with the Copyright, Designs and Patents Act 1988. All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording or otherwise, except as permitted by the UK Copyright, Designs and Patents Act 1988, without the prior permission of the publisher.
    [Show full text]
  • Protection Group (PG): This Is a Dynamic Entity That Informally Represents the Groups of Components to Which a CSI Has Been Assigned
    ÉCOLE DE TECHNOLOGIE SUPÉRIEURE UNIVERSITÉ DU QUÉBEC THESIS PRESENTED TO ÉCOLE DE TECHNOLOGIE SUPÉRIEURE IN PARTIAL FULFILLEMENT OF THE REQUIREMENTS FOR A MASTER’S DEGREE WITH THESIS IN INFORMATION TECHNOLOGY ENGINEERING M. A. Sc. BY Maxime TURENNE A NEW DOMAIN SPECIFIC LANGUAGE FOR GENERATING AND VALIDATING MIDDLEWARE CONFIGURATIONS FOR HIGHLY AVAILABLE APPLICATIONS MONTREAL, October 6th, 2015 Maxime Turenne 2015 This Creative Commons licence allows readers to download this work and share it with others as long as the author is credited. The content of this work may not be modified in any way or used commercially. BOARD OF EXAMINERS THESIS M.A.Sc. THIS THESIS HAS BEEN EVALUATED BY THE FOLLOWING BOARD OF EXAMINERS Mr. Abdelouahed Gherbi, Thesis Supervisor Department of software and IT engineering at École de technologie supérieure Mr. Ali Kanso, Thesis Co-supervisor Researcher at Ericsson Canada Mr. Mohamed Cheriet, Chair, Board of Examiners Department of software and IT engineering at École de technologie supérieure Mr. Sègla Kpodjedo, Member of the jury Department of software and IT engineering at École de technologie supérieure THIS THESIS WAS PRENSENTED AND DEFENDED IN THE PRESENCE OF A BOARD OF EXAMINERS AND THE PUBLIC SEPTEMBER 4TH, 2015 AT ÉCOLE DE TECHNOLOGIE SUPÉRIEURE ACKNOWLEDGMENTS I would like to express my sincere gratitude to: • My supervisors, Dr. Abdelouahed Gherbi not only for giving me the chance to benefit from his large and substantial knowledge, but also for his human approach from which I have learned a lot. • Dr. Ali Kanso from who I learned almost everything about high availability for his inspiring example as a scientific and colleague.
    [Show full text]
  • Kubernetes As an Availability Manager for Microservice Applications
    Kubernetes as an Availability Manager for Microservice Applications Leila Abdollahi Vayghan Mohamed Aymen Saied Maria Toeroe Ferhat Khendek Engineering and Computer Engineering and Computer Ericsson Inc. Engineering and Computer Science Science Montreal, Canada Science Concordia University Concordia University [email protected] Concordia University Montreal, Canada Montreal, Canada Montreal, Canada [email protected] [email protected] [email protected] Abstract— The move towards the microservice based services that can be deployed and scaled independently by fully architecture is well underway. In this architectural style, small and automated deployment machinery, with minimum centralized loosely coupled modules are developed, deployed, and scaled management [2]. Microservices are built around separate independently to compose cloud-native applications. However, for business functionalities. Each microservice runs in its own carrier-grade service providers to migrate to the microservices process and communicates through lightweight mechanisms, architectural style, availability remains a concern. Kubernetes is often using APIs [3]. Microservices address the drawbacks of an open source platform that defines a set of building blocks which monolithic applications. They are small and can restart faster at collectively provide mechanisms for deploying, maintaining, the time of upgrade or failure recovery. Microservices are scaling, and healing containerized microservices. Thus, loosely coupled, and failure of one microservice will not affect Kubernetes hides the complexity of microservice orchestration while managing their availability. In a preliminary work we other microservices of the system. The fine granularity of this evaluated Kubernetes, using its default configuration, from the architectural style makes the scaling more flexible and more availability perspective in a private cloud settings.
    [Show full text]
  • Docker and Kubernetes: Changing the Opentext Documentum Deployment Model
    White paper Docker and Kubernetes: Changing the OpenText Documentum deployment model Containerization with Docker and Kubernetes’ cloud-first technology is not only a game changer for effectively managing on-premises ™ ™ OpenText Documentum solutions, it also paves the way for deploying EIM solutions in the cloud. Contents New deployment models 3 Customer case study—Part I 3 What is containerization? 4 What are Docker containers? 4 Docker container advantages 5 Available containers 6 What is Kubernetes? 6 Kubernetes advantages 6 Customer case study—Part II 7 EIM in the cloud 7 What is the cloud? 7 Cloud EIM 8 Customer case study—Part III 9 ™ OpenText Managed Services 9 Summary 9 Docker and Kubernetes: Changing the OpenText Documentum deployment model 2/10 New deployment models ™ ™ OpenText Documentum administrators can face two challenges: 1. Effectively managing complex Documentum deployments. Highly customized, mission-critical applications consume disproportionate administrative cycles, budgets and resources to install, upgrade, maintain and enhance. Upgrading these applications requires significant investments in change management. As a result, applications are often not upgraded in a timely fashion and do not leverage the latest technology. 2. Developing a cloud strategy for Enterprise Information Management (EIM) applications. Corporate IT is under intense pressure to produce an enterprise cloud strategy. Leveraging cloud technology for Enterprise Information Management (EIM) applications can be a big win, as long as it does not impact adoption, productivity and governance. Containerization enables new deployment models to help organizations meet these challenges, effectively managing on-premises solutions and paving the way for deploying EIM solutions in the cloud. Customer case study—Part I This real-world customer case study illustrates how containerization can benefit existing Documentum customers.
    [Show full text]