DOCSLIB.ORG

Gitops Basiertes Continuous Delivery Für Serverless Anwendungen

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Gitops Basiertes Continuous Delivery Für Serverless Anwendungen Institut für Architektur von Anwendungssystemen Universität Stuttgart Universitätsstraße 38 D–70569 Stuttgart Masterarbeit GitOps basiertes Continuous Delivery für Serverless Anwendungen Müslüm Sahin Studiengang: Softwaretechnik Prüfer/in: Prof. Dr. Dr. h. c. Frank Leymann Betreuer/in: Michael Wurster, M.Sc. Beginn am: 3. September 2018 Beendet am: 4. März 2019 Kurzfassung Das Ziel dieser Masterarbeit ist ein Konzept für eine anbieterunabhängige Continuous Delivery Lösung für Serverless Anwendungen zu entwickeln und prototypisch umzusetzten. Serverless bezeichnet ein Paradigma, bei dem die Infrastruktur komplett vom Entwickler verborgen bleibt und vom Cloud Anbieter verwaltet wird. Function-as-a-Service (FaaS) beschreibt ein Serverless Cloud-Service mit der kleine, kurzlebige und ereignisgesteuerte Funktionen bereitgestellt wer- den. Aufgrund der feinen Granularität von Business Services erhöht sich die Komplexität für Deployment und Management der Anwendung. Daher sind automatisierte DevOps Methoden durch Continuous Delivery und Infrastructure-as-Code (IaC) essentiell für eine zuverlässige, sichere und schnellere Softwareauslieferung. Dies wird bereits von einigen Cloud Providern mit eigenen Cloud-Services unterstützt, was jedoch zu einem Vendor Lock-in führt, da individuelle Imple- mentierungen und DevOps-Prozesse vom Anbieter abhängig sind. Daher untersucht diese Arbeit den Stand der Technik im Bereich Herausforderungen, Konzepte, Technologien im gemeinsamen Kontext von Serverless, Continuous Delivery und Multi-Cloud. Hierfür wird eine systematische Literaturrecherche (SLR) verwendet. Statistische Analysen der SLR und weitere Recherchen haben ergeben, dass die Einschränkungen von proprietären FaaS-Plattformen durch Abstraktionen und Multi-Cloud Tools ein alternatives Konzept ergeben, der Vendor Lock-in aber immer noch existiert. Ein Pseudo-Algorithmus wurde entwickelt, um das geeignete Infrastructure-as-Code (IaC) Modell für das Vendor Lock-in Problem zu finden, solange keine Standards für Serverless Anwendungen existieren. Auf Basis weiterer Recherchen wurde ein Konzept für eine GitOps basierte Continuous Delivery Pipeline entwickelt. Um das Konzept zu zeigen wurde eine prototypische CI/CD Pipeline anhand einer Beispielanwendung implementiert. Das Konzept bietet eine Isolierung der Plattform- Anbieter und ist anbieterunabhängig. Das Ergebnis der Arbeit hat gezeigt, dass die Technologie noch jung im Bezug auf Tooling-Support, Standardisierung und Forschung ist. Weiterhin wird zu erwarten sein, dass sich die Lücke zwischen Serverless und Container-Orchestrierung irgendwann schließen wird. 3 Inhaltsverzeichnis 1. Einleitung 17 1.1. Forschungsmethode ................................ 19 1.2. Gliederung ..................................... 19 2. Grundlagen 21 2.1. Serverless und Function-as-a-Service ....................... 21 2.2. Continuous Delivery für Serverless Anwendungen ................ 26 2.3. Der Vendor Lock-in und Function-as-a-Service .................. 29 3. Verwandte Arbeiten 33 4. Stand der Technik: Eine Systematische Literaturrecherche 35 4.1. Planung der Recherche: Das Review-Protokoll .................. 35 4.2. Durchführung der Recherche ........................... 40 4.3. Ergebnisse der Recherche ............................. 42 4.4. Fazit der SLR ................................... 46 5. Alternative Konzepte für Continuous Delivery von Serverless Anwendungen 49 5.1. Infrastructure-as-Code für Serverless Anwendungen ............... 49 5.2. Alternatives Konzept: Abstraktionen durch Serverless Framework und Tools .. 51 5.3. Alternatives Konzept: Multi-Cloud Orchestrierung ................ 54 5.4. Fazit der Alternative ................................ 55 6. Konzept: GitOps basiertes Continuous Delivery von Serverless Anwendungen 57 6.1. Cloud-agnostisches FaaS durch Container-Orchestrierung ............ 57 6.2. Continuous Delivery mit GitOps ......................... 57 6.3. Architektur des Konzepts ............................. 59 7. Prototypische Implementierung 63 7.1. Verwendete Technologien ............................. 63 7.2. Komponenten der Implementierung ........................ 66 7.3. Beispiel einer FaaS Anwendung: Wettervorhersage mit der OpenWeatherMap . 72 7.4. Fazit der Implementierung ............................. 74 8. Zusammenfassung und Ausblick 75 Literaturverzeichnis 77 A. Datenextraktion der Studien 87 B. Synthetisieren der Daten 111 5 C. Suchphrasen der SLR 115 6 Abbildungsverzeichnis 1.1. Serverless im Trend (2014-2019) Quelle: [Goo] .................. 18 1.2. Gewünschte Architektur (vereinfacht) für von Serverless-Anwendungen Quelle: inspiriert durch [Zima] ............................... 19 2.1. Monolith, Microservices und Serverless Funktionen (inspiriert durch: [Ang]) .. 22 2.2. Funktionsweise von FaaS(inspiriert durch: [Gan17]) ................ 23 2.3. Serverless und andere Cloud-native Technologien Quelle: [Cnc18]) ........ 24 2.4. Allgemeine Continuous Delivery Pipeline ..................... 27 2.5. CI/CD Pipeline einer Serverless Anwendung in AWS - Quelle: inspiriert durch ([LB16]) ....................................... 31 4.1. Suchphrase (Beispiel) ................................ 37 4.2. SLR Ergebnisse ................................... 41 4.3. Probleme/Herausforderungen im CI/CD in Serverless/FaaS ............ 43 4.4. Konzepte für CI/CD in Serverless/FaaS ...................... 44 4.5. Technologien für CI/CD in Serverless/FaaS .................... 45 4.6. Konzepte für CI/CD in Multi-Cloud ........................ 46 4.7. Technologien für CI/CD in Multi-Cloud ...................... 47 5.1. Allgemeine Deployment-Pipeline mit dem Serverless Framework Quelle: Eigene Darstellungs ..................................... 53 5.2. Allgemeine Deployment-Pipeline mit Multi-Cloud IaC Tool Terraform Quelle: Eigene Darstellung ................................. 55 6.1. Abstraktes Multi-Cloud FaaS durch Container-Orchestrierung Quelle: Eigene Dar- stellung ....................................... 58 6.2. GitOps Pipeline: Push-Modell Quelle: [Wea] ................... 59 6.3. GitOps Pipeline: Pull-Modell Quelle: [Wea] .................... 59 6.4. Abstrakte CD-Pipeline von containerisierten Serverless Anwendungen Quelle: Eigene Darstellung ................................. 60 6.5. Gesamt-Architektur des Konzepts: GitOps basiertes Continuous Delivery Quelle: Eigene Darstellung ................................. 61 7.1. OpenFaaS Komponenten Quelle: [Ope19] ..................... 65 7.2. GitHub Commit Logs (Build Status) mit Travis CI Integration - Quelle: [Sah19] . 67 7.3. Architektur der prototypischen Continuous Delivery Pipeline Quelle: Eigene Dar- stellung ....................................... 69 C.1. Suchphrase 1 (FF1) ................................. 115 C.2. Suchphrase 2 (FF1) ................................. 116 7 C.3. Suchphrase 3 (FF1) ................................. 116 C.4. Suchphrase 4 (FF1) ................................. 116 C.5. Suchphrase 5 (FF1) ................................. 117 C.6. Suchphrase 6 (FF2) ................................. 117 C.7. Suchphrase 7 (FF3) ................................. 117 C.8. Suchphrase 8 (FF3) ................................. 118 8 Tabellenverzeichnis 2.1. Vergleich der Cloud-spezifischen Features von AWS Lambda, Google Cloud Func- tions und Azure Functions ............................. 30 4.1. Suchterme mit Abkürzungen und Synonymen ................... 37 4.2. Formular zur Datenextraktion ............................ 39 4.3. Synthese-Formular für FF1 ............................. 39 4.4. Synthese-Formular für FF2 ............................. 39 4.5. Synthese-Formular für FF3 ............................. 39 4.6. Die SLR-Studien nach Quelle ............................ 41 A.1. Datenextraktion für [AC17] ............................. 87 A.2. Datenextraktion für [SJ17] ............................. 88 A.3. Datenextraktion für [FCSS15] ........................... 88 A.4. Datenextraktion für [DMB18] ........................... 89 A.5. Datenextraktion für [FSR+14] ........................... 89 A.6. Datenextraktion für [FCS+18] ........................... 90 A.7. Datenextraktion für [BGK+13] ........................... 90 A.8. Datenextraktion für [FCR+13] ........................... 91 A.9. Datenextraktion für [GCGA15] ........................... 91 A.10.Datenextraktion für [VJ14] ............................. 92 A.11.Datenextraktion für [AKC+15] ........................... 92 A.12.Datenextraktion für [Ren16] ............................ 93 A.13.Datenextraktion für [BIS+14] ............................ 93 A.14.Datenextraktion für [SZD+15] ........................... 94 A.15.Datenextraktion für [Elg15] ............................. 94 A.16.Datenextraktion für [MJB+17] ........................... 95 A.17.Datenextraktion für [MB17] ............................ 95 A.18.Datenextraktion für [SS18] ............................. 96 A.19.Datenextraktion für [JY18] ............................. 96 A.20.Datenextraktion für [MPF18] ............................ 97 A.21.Datenextraktion für [LRLE17] ........................... 98 A.22.Datenextraktion für [HB13] ............................. 99 A.23.Datenextraktion für [PM13] ............................. 99 A.24.Datenextraktion für [FRC+13] ........................... 100 A.25.Datenextraktion für [CFN+14] ........................... 101 A.26.Datenextraktion für [PTD+15b] ........................... 101 A.27.Datenextraktion für [CDR+17] ........................... 102 A.28.Datenextraktion für [PTD+15b]
Load more

Recommended publications
  • Algorithms and Techniques for Automated Deployment and Efficient Management of Large-Scale Distributed Data Analytics Services B
    ALGORITHMS AND TECHNIQUES FOR AUTOMATED DEPLOYMENT AND EFFICIENT MANAGEMENT OF LARGE-SCALE DISTRIBUTED DATA ANALYTICS SERVICES By Anirban Bhattacharjee Dissertation Submitted to the Faculty of the Graduate School of Vanderbilt University in partial fulfillment of the requirements for the degree of DOCTOR OF PHILOSOPHY in Computer Science February 29, 2020 Nashville, Tennessee Approved: Aniruddha S. Gokhale, Ph.D. Abhishek Dubey, Ph.D. Douglas C. Schmidt, Ph.D. Gabor Karsai, Ph.D. Hongyang Sun, Ph.D. DEDICATION To my late Grandmother, Bina Roy Chowdhury, infinitely inspirational and To my beloved wife, Malabika, unbelievably encouraging and To my parents, Ashok and Nilanjana Bhattacharjee, amazingly supportive ii ACKNOWLEDGMENTS I express my sincere gratitude to those who have contributed to this thesis and supported me during this fantastic journey. I am grateful to all of those with whom I have had the pleasure to work during these years. First and foremost, I would like to express my sincere thanks to my advisor Dr. Anirud- dha S. Gokhale, for providing me the opportunity to work in the Distributed Object Com- puting (DOC) group at the Vanderbilt Vanderbilt School of Engineering. His thoughtful advice, guidance, mentorship, and unwavering support over the years helped me at various stages of my research. I appreciate his valuable suggestions, comments, and leadership, which encouraged me to learn more every day and to become an independent researcher. His support has been the most worthy experience for me, and I owe him a big thanks once again for being a fantastic advisor and mentor. I want to thank Dr. Abhishek Dubey, Dr.
    [Show full text]
  • Code Smell Prediction Employing Machine Learning Meets Emerging Java Language Constructs"
    Appendix to the paper "Code smell prediction employing machine learning meets emerging Java language constructs" Hanna Grodzicka, Michał Kawa, Zofia Łakomiak, Arkadiusz Ziobrowski, Lech Madeyski (B) The Appendix includes two tables containing the dataset used in the paper "Code smell prediction employing machine learning meets emerging Java lan- guage constructs". The first table contains information about 792 projects selected for R package reproducer [Madeyski and Kitchenham(2019)]. Projects were the base dataset for cre- ating the dataset used in the study (Table I). The second table contains information about 281 projects filtered by Java version from build tool Maven (Table II) which were directly used in the paper. TABLE I: Base projects used to create the new dataset # Orgasation Project name GitHub link Commit hash Build tool Java version 1 adobe aem-core-wcm- www.github.com/adobe/ 1d1f1d70844c9e07cd694f028e87f85d926aba94 other or lack of unknown components aem-core-wcm-components 2 adobe S3Mock www.github.com/adobe/ 5aa299c2b6d0f0fd00f8d03fda560502270afb82 MAVEN 8 S3Mock 3 alexa alexa-skills- www.github.com/alexa/ bf1e9ccc50d1f3f8408f887f70197ee288fd4bd9 MAVEN 8 kit-sdk-for- alexa-skills-kit-sdk- java for-java 4 alibaba ARouter www.github.com/alibaba/ 93b328569bbdbf75e4aa87f0ecf48c69600591b2 GRADLE unknown ARouter 5 alibaba atlas www.github.com/alibaba/ e8c7b3f1ff14b2a1df64321c6992b796cae7d732 GRADLE unknown atlas 6 alibaba canal www.github.com/alibaba/ 08167c95c767fd3c9879584c0230820a8476a7a7 MAVEN 7 canal 7 alibaba cobar www.github.com/alibaba/
    [Show full text]
  • Fault Tolerant, Self-Healing and Vendor Neutral Multi-Cloud Patterns and Framework Focused on Deployment and Management
    Fault Tolerant, Self-Healing and Vendor Neutral Multi-Cloud Patterns and Framework Focusing on Deployment and Management by Andrey Rybka Submitted in partial fulfillment of the requirements for the degree of Doctor of Professional Studies in Computing at School of Computer Science and Information Systems Pace University October 2017 Version 2.5 We hereby certify that this dissertation, submitted by Andrey Rybka, satisfies the dissertation requirements for the degree of Doctor of Professional Studies in Computing and has been approved. _____________________________________________-________________ Dr. Lixin Tao Date Chairperson of Dissertation Committee _____________________________________________-________________ Dr. Charles Tappert Date Dissertation Committee Member _____________________________________________-________________ Dr. Ronald Frank Date Dissertation Committee Member School of Computer Science and Information Systems Pace University 2017 Abstract Fault Tolerant, Self-Healing and Vendor Neutral Multi-Cloud Patterns and Framework Focused on Deployment and Management by Andrey Rybka Submitted in partial fulfillment of the requirements for the degree of Doctor of Professional Studies in Computing October 2017 Many organizations are looking to migrate to the cloud and looking for the best way to do it securely, reliably and without vendor lock in. Most organizations have to pick a cloud provider that uses proprietary APIs and Software. Most vendors currently do not implement any cloud API standards i.e. TOSCA or OASIS CAMP. Therefore,
    [Show full text]
  • Uforge Appcenter User Documentation Release 3.8
    UForge AppCenter User Documentation Release 3.8 FUJITSU Jun 10, 2019 Contents 1 Getting Started 3 1.1 Signing In to UForge Portal.......................................3 1.2 Keyboard Actions............................................5 1.3 Basic Concepts..............................................6 2 Managing Your Accounts 9 2.1 Modifying Your User Profile.......................................9 2.2 Viewing Your Statistics......................................... 10 2.3 Changing Your Password......................................... 11 3 Managing Your Credentials 13 3.1 Managing Cloud Accounts........................................ 13 3.2 Managing Your Artifact Accounts.................................... 15 3.3 Managing API Keys........................................... 16 3.4 Managing SSH Keys........................................... 17 4 Managing Appliance Templates 19 4.1 Supported Operating Systems...................................... 19 4.2 Creating an Appliance Template..................................... 20 4.3 Modifying an Appliance Template.................................... 24 4.4 Managing the OS Profile......................................... 25 4.5 Updating the Install Profile........................................ 26 4.6 Managing Configuration......................................... 33 4.7 Adding Custom Software Components................................. 35 4.8 Tracking OS Package Updates...................................... 42 4.9 Listing Appliance Templates....................................... 44 4.10 Cloning
    [Show full text]
  • Universidad Politécnica De Madrid a Proposal
    UNIVERSIDAD POLITÉCNICA DE MADRID ESCUELA TÉCNICA SUPERIOR DE INGENIEROS DE TELECOMUNICACIÓN A PROPOSAL FOR A MODEL-BASED APPROACH FOR ADAPTING SOFTWARE CONFIGURATION TO RUNTIME ENVIRONMENTS TESIS DOCTORAL ÁLVARO NAVAS BALTASAR Ingeniero de Telecomunicación 2015 DEPARTAMENTO DE INGENIERÍA DE SISTEMAS TELEMÁTICOS ESCUELA TÉCNICA SUPERIOR DE INGENIEROS DE TELECOMUNICACIÓN UNIVERSIDAD POLITÉCNICA DE MADRID A PROPOSAL FOR A MODEL-BASED APPROACH FOR ADAPTING SOFTWARE CONFIGURATION TO RUNTIME ENVIRONMENTS Autor: ÁLVARO NAVAS BALTASAR Ingeniero de Telecomunicación Director: JUAN CARLOS DUEÑAS LÓPEZ Doctor Ingeniero de Telecomunicación Codirector: FÉLIX CUADRADO LATASA Doctor Ingeniero de Telecomunicación 2015 Tribunal nombrado por el Magfco. Y Excmo. Sr. Rector de la Universidad Politécnica de Madrid, el día de de 2016. Presidente: Vocal: Vocal: Vocal: Secretario: Suplente: Suplente: Realizado el acto de defensa y lectura de la Tesis el día de de 2016 en la E.T.S.I.T. habiendo obtenido la calificación de EL PRESIDENTE LOS VOCALES EL SECRETARIO Abstract Agile development methodologies have risen in popularity within the industry in recent years due to the speed and reliability of the processes they propose. The DevOps philosophy and specifically the methodologies derived from it such as Continuous Delivery and Continuous Deployment push for a totally automated management of the application lifecycle, from the source code to the software running in production environment. Automation in this regard is used as a means to produce repeatable, reliable and fast processes. However, not all parts of the Continuous methodologies are completely automatized. In particular, management of runtime parameter configuration is a problem that has increased its impact in deployment process due to the scalability and elasticity provided by cloud technologies.
    [Show full text]
  • 1484244156 Atos
    Attachment A: NASPO ValuePoint Master Agreement Terms and Conditions 1. Master Agreement Order of Precedence a. Any Order placed under this Master Agreement shall consist of the following documents: (1) A Participating Entity’s Participating Addendum1 (“PA”); (2) NASPO ValuePoint Master Agreement Terms & Conditions, including the applicable Exhibits2 to the Master Agreement; and (3) A Service Level Agreement issued against the Participating Addendum. b. These documents shall be read to be consistent and complementary. Any conflict among these documents shall be resolved by giving priority to these documents in the order listed above. Contractor terms and conditions that apply to this Master Agreement are only those that are expressly accepted by the Lead State and must be in writing and attached to this Master Agreement as an Exhibit or Attachment. 2. Definitions - Unless otherwise provided in this Master Agreement, capitalized terms will have the meanings given to those terms in this Section. Confidential Information means any and all information of any form that is marked as confidential or would by its nature be deemed confidential obtained by Contractor or its employees or agents in the performance of this Master Agreement, including, but not necessarily limited to (1) any Purchasing Entity’s records, (2) personnel records, and (3) information concerning individuals, is confidential information of Purchasing Entity. Contractor means the person or entity providing solutions under the terms and conditions set forth in this Master Agreement.
    [Show full text]
  • Uforge Appcenter Admin Documentation Release 3.8
    UForge AppCenter Admin Documentation Release 3.8 FUJITSU Jun 10, 2019 Contents 1 Architecture Considerations 3 1.1 UForge Platform Overview.......................................3 1.2 Reliability................................................8 1.3 Security..................................................8 1.4 Storage Considerations..........................................8 1.5 Scalability through Partitioning..................................... 10 1.6 Image Generations............................................ 10 1.7 Estimating Scan Size........................................... 11 1.8 Deployment Examples.......................................... 11 1.9 Network Topology............................................ 12 1.10 Minimum Software Topology...................................... 13 1.11 Security Options............................................. 14 1.12 High Availability............................................. 14 2 Installing UForge 15 2.1 UForge Installation Overview...................................... 15 2.2 UForge Repository Setup........................................ 16 2.3 UForge Repository on Shared Storage.................................. 17 2.4 UForge Repository on Local Storage.................................. 17 2.5 Installing from an ISO.......................................... 18 2.6 Post-Installation Cleanup......................................... 19 2.7 Configuring UForge........................................... 19 2.8 Cloud Platform Default Ports...................................... 22 2.9 Testing
    [Show full text]
  • Cloudcamp: Automating Cloud Services Deployment & Management
    CloudCAMP: Automating Cloud Services Deployment & Management Anirban Bhattacharjee∗, Yogesh Barve∗, Aniruddha Gokhale∗ Takayuki Kuroday ∗Department of Electrical Engineering and Computer Science yNEC Corporation Vanderbilt University, Nashville, Tennessee, USA Kawasaki, Kanagawa, Japan Email: {anirban.bhattacharjee; yogesh.d.barve; a.gokhale}@vanderbilt.edu Email: [email protected] Abstract—Users of cloud platforms often must expend sig- A. Motivating the Problem nificant manual efforts in the deployment and orchestration Consider the case of a LAMP [Linux, Apache, MySQL, of their services on cloud platforms due primarily to hav- ing to deal with the high variabilities in the configuration and PHP] -based service deployment on a cloud platform. options for virtualized environment setup and meeting the Figure 1 shows the desired cloud application topology con- software dependencies for each service. Despite the emergence sisting of two connected software stacks, i.e., a PHP-based of many DevOps cloud automation and orchestration tools, web front-end and a MySQL database backend. The frontend users must still rely on specifying low-level scripting details WebApplication stack holds the business logic, and it will be for service deployment and management using Infrastructure- as-Code (IAC). Using these tools required domain expertise deployed on Ubuntu 16.04 server virtual machine (VM), which along with a steep learning curve. To address these challenges is managed using the OpenStack cloud platform. The backend in a tool-and-technology agnostic manner, which helps promote DBApplication stack holds the relational database, which is interoperability and portability of services hosted across cloud used to store and query the product data.
    [Show full text]
  • Curriculum Vitae
    Curriculum Vitae Table of Contents Personal Details . 1 Professional Experience. 2 Self Employed at Netdava . 2 Self Employed at Stan Ioan Eugen PFA . 4 Java Developer at 1and1 Internet România. 6 Java Developer at Apache James (Google Summer of Code) . 6 Java Developer at Joseki Bold . 7 Fire Fighter Officer at Inspectoratul pentru Situatii de Urgentă "Dealu Spirii" Bucuresti-Ilfov. 7 NetBeans Platform Translator at Joseki Bold . 7 Conferences & presentations . 7 Education . 8 Academic Background . 8 Language Skills . 8 Hobby and other. 8 Personal Details Eugen Stan I’m passionate about technology and the benefits it can bring. I believe technology should serve people and I do my best to achieve that goal. I like building systems and I find myself experimenting. Two personality traits that describe me are curiosity and tenacity. My first coding experience was in ~6th grade with a HC 85 PC running Basic. In high school we learned Turbo Pascal and I self-thought myself C and Linux. I used to sneak in the computer lab often. I convinced them to let me install Slackware. I read Let’s Build a Compiler and then I wrote an interpreter for a simple language, unimaginatively called Interpreter for Pseudo Code. I took a break from coding during most of my college years. When I started coding professionally I used mainly Java and JavaScript. Today my language of choice is Clojure and ClojureScript. It’s a fun language to use. I like libre/open source software and I was/am involved/support/promote Apache Software Foundation and Debian communities.
    [Show full text]
  • An Automation-Based Approach for Reproducible Evaluations of Distributed DBMS on Elastic Infrastructures
    Institut für Organisation und Management von Informationssystemen An Automation-based Approach for Reproducible Evaluations of Distributed DBMS on Elastic Infrastructures Dissertation zur Erlangung des Doktorgrades Dr. rer. nat. der Fakultät für Ingenieurwissenschaften, Informatik und Psychologie der Universität Ulm vorgelegt von Daniel Seybold aus Crailsheim 2020 This thesis has been written by Daniel Seybold in partial fulfilment of the requirements for a doctoral degree of the faculty of Engineering, Computer Science and Psychology at Ulm University. It has been submitted on June 30, 2020. Amtierender Dekan: Prof. Dr.-Ing. Maurits Ortmanns Erstgutachter: Prof. Dr.-Ing. Dr. h.c. Stefan Wesner Zweitgutachter: Prof. Dr.-Ing. Samuel Kounev Tag der Promotion: 08.03.2021 Contact Daniel Seybold mail: [email protected] www: https://www.uni-ulm.de/in/omi/institut/persons/daniel-seybold/ Institute of Information Resource Management Faculty of Engineering, Computer Sciences and Psychology University of Ulm Albert-Einstein-Allee 43 89081 Ulm, Germany Typesetting This document was set by the author using the X LAE TEX typsetting system, the Meta font family, and the Latin Modern font family. My sincere apologies to those people whose names are not typeset correctly due to limitations of the fonts. Layout Many thanks to Jörg Domaschka for sharing the template for this thesis. ©2020 Daniel Seybold Abstract Driven by the data-intensive applications of the Web, Big Data and Internet of Things, Database Management Systems (DBMSs) and their operation have significantly changed over the last decade. Besides relational DBMSs, manifold NoSQL and NewSQL DBMSs evolved, promising a set of non-functional features that are key requirements for each data-intensive application: high performance, horizontal scalability, elasticity and high-availability.
    [Show full text]
  • Using Docker
    U s i n g Docker DEVELOPING AND DEPLOYING SOFTWARE WITH CONTAINERS Adrian Mouat www.allitebooks.com www.allitebooks.com Using Docker Adrian Mouat Boston www.allitebooks.com Using Docker by Adrian Mouat Copyright © 2016 Adrian Mouat. All rights reserved. Printed in the United States of America. Published by O’Reilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA 95472. O’Reilly books may be purchased for educational, business, or sales promotional use. Online editions are also available for most titles (http://safaribooksonline.com). For more information, contact our corporate/ institutional sales department: 800-998-9938 or [email protected]. Editor: Brian Anderson Indexer: WordCo Indexing Services Production Editor: Melanie Yarbrough Interior Designer: David Futato Copyeditor: Christina Edwards Cover Designer: Randy Comer Proofreader: Amanda Kersey Illustrator: Rebecca Demarest December 2015: First Edition Revision History for the First Edition 2015-12-07: First Release See http://oreilly.com/catalog/errata.csp?isbn=9781491915769 for release details. The O’Reilly logo is a registered trademark of O’Reilly Media, Inc. Using Docker, the cover image, and related trade dress are trademarks of O’Reilly Media, Inc. While the publisher and the author have used good faith efforts to ensure that the information and instructions contained in this work are accurate, the publisher and the author disclaim all responsibility for errors or omissions, including without limitation responsibility for damages resulting from the use of or reliance on this work. Use of the information and instructions contained in this work is at your own risk. If any code samples or other technology this work contains or describes is subject to open source licenses or the intellectual property rights of others, it is your responsibility to ensure that your use thereof complies with such licenses and/or rights.
    [Show full text]
  • Iot Projects in FLOSS Foundations Dashboard
    IoT Projects in FLOSS Foundations Dashboard https://iotfloss.bitergia.net/ A dashboard based on communities data v0.1 Alvaro del Castillo <[email protected]> Valerio Cosentino <[email protected]> https://thingso2.com https://bitergia.com Bring to you by ... Álvaro del Castillo Valerio Cosentino <[email protected]> <[email protected]> Open Source advocate and developer! GrimoireLab maintainer, CHAOSS contributor Working now in an IoT platform at ThingsO2 Working at Bitergia In love with reactive technologies and Interested in source code analysis, ETL functional programming processes and reverse engineering Impressed by the IoT grow and possibilities Newbie in the IoT ecosystem PLC4X committer Outline Overview IoT architectures Apache Software Foundation (AF) Eclipse Foundation (EF) Linux Foundation (LF) Project selection and classification Findings and Insights Conclusion Overview Why More visibility is needed of what’s happening on the FLOSS IoT landscape. This dashboard provides a place to better understand the IoT ecosystem. How The dashboard is made with GrimoireLab, an open source toolset for software development analytics. It’s part of CHAOSS, a project under the Linux Foundation: https://chaoss.github.io/grimoirelab/ Contribute Have a look at https://github.com/aylabs/iotfloss, and join us! Warnings Our initial focus was IIoT We use IoT for simplicity but both are converging Project selection and classification are debatable Both are the pillars of the dashboard Basic metrics in this version CHAOSS project could
    [Show full text]