DOCSLIB.ORG

Evaluation of Infrastructure As a Code for Enterprise Automation

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Evaluation of Infrastructure As a Code for Enterprise Automation Masaryk University Faculty of Informatics Evaluation of Infrastructure as a Code for Enterprise Automation Master’s Thesis Michal Hagara Brno, Spring 2018 Declaration Hereby I declare that this paper is my original authorial work, which I have worked out on my own. All sources, references, and liter- ature used or excerpted during elaboration of this work are properly cited and listed in complete reference to the due source. Michal Hagara Advisor: Bruno Rossi, PhD i Acknowledgements I would like to thank Dr. Bruno Rossi for being my adviser during the thesis, as without his advice and help I would not be able to finish the thesis. I would like to thank him also for his patience and understanding on the personal level. iii Abstract Expansion of cloud and virtualization is present every day, and it has to be handled accordingly, as there is an emphasis on speed, consis- tency and time to market. The thesis deals with this phenomenon and provides insight into terms such as automation, Infrastructure as a Code, DevOps or configuration management (CM). The thesis aims to introduce how the selection process of configuration management tool for enterprise automation should be carried out, as the integra- tion of the right tool to the infrastructure is critical. The selection process is divided into two parts. First part evaluates mechanics and different aspect of configuration management tools from the practical point of view. In the second part of the thesis evaluation of public survey of configuration management tools is presented. The primary contribution of this thesis is aimed at providing insight on how the selection process of CM tool should be carried out, and also to provide a comprehensive review of CM tools for enterprise automation. iv Keywords Configuration management, automation, DevOps, Infrastructure asa Code, Ansible, Chef, Puppet, SaltStack v Contents 1 Introduction 1 2 Infrastructure as a Code 3 2.1 History and DevOps background of IaC ...........3 2.2 Infrastructure as a Code as a part of DevOps .........4 2.3 Configuration management ..................5 3 Comparison of configuration management tools 7 3.1 Ansible ............................9 3.1.1 Communication and security . .9 3.1.2 Ansible specific working mode . .9 3.1.3 Ansibles mechanics and terminology . 10 3.1.4 Ansible DSL and templating engine . 12 3.2 Chef .............................. 13 3.2.1 Communication and security . 13 3.2.2 Chefs specific working mode . 14 3.2.3 Chefs mechanics an terminology . 14 3.2.4 Chef DSL and templating engine . 16 3.3 Puppet ............................. 17 3.3.1 Communication and security . 17 3.3.2 Puppet specific working mode . 18 3.3.3 Puppets mechanics an terminology . 18 3.3.4 Puppet DSL and templating engine . 20 3.4 SaltStack ........................... 21 3.4.1 Communication and security . 21 3.4.2 Salts specific working mode . 21 3.4.3 Salts mechanics an terminology . 22 3.4.4 Salt DSL and templating engine . 25 3.5 Intermediate result of evaluation ............... 25 4 Public survey of configuration management tools 27 4.1 Installability .......................... 30 4.2 Configurability ........................ 31 4.3 Stability ............................ 33 4.4 Scalability ........................... 34 4.5 Usability/learning curve ................... 36 vii 4.6 ACL capabilities ........................ 38 4.7 Documentation ........................ 39 4.8 Support ............................ 41 4.9 Training ............................ 42 4.10 Supported Operating Systems ................ 43 4.10.1 OS Support of Ansible . 44 4.10.2 OS Support of Chef . 45 4.10.3 OS Support of Puppet . 46 4.10.4 OS Support of SaltStack . 46 4.11 Advantages .......................... 47 4.12 Disadvantages ......................... 48 4.13 Satisfaction .......................... 49 4.14 Deployment properties .................... 50 4.14.1 Portability . 50 4.14.2 Installability . 51 4.14.3 Adaptability . 51 4.14.4 Configurability . 51 4.14.5 Distributability . 51 4.14.6 Scalability . 51 4.14.7 Stability . 52 4.15 Specification management properties ............. 52 4.15.1 Language . 52 4.15.2 Monitoring . 53 4.15.3 Versioning . 53 4.15.4 Integration . 53 4.15.5 Access Control . 53 4.16 Result of the public survey of CM tools ............ 54 5 Conclusion 59 5.1 Results in regards to the comparison of CM tools ...... 59 5.2 Results in regards to the public survey of CM tools ..... 59 5.3 In retrospect .......................... 60 A Online survey 69 B CM tools code examples 77 B.1 Ansible ............................ 77 B.1.1 Playbook example . 77 viii B.2 Chef .............................. 78 B.2.1 Recipe example . 78 B.3 Puppet ............................. 79 B.3.1 Manifest example . 79 B.4 SaltStack ........................... 80 B.4.1 State file example . 80 B.5 Jinja template example .................... 81 B.6 ERB template example .................... 82 ix List of Tables 3.1 Overview of practical CM tools comparison 26 4.1 Overview of respondents occupation 29 4.2 Overview of public survey results 58 xi List of Figures 4.1 Installability graph 30 4.2 Configurability graph 32 4.3 Stability graph 34 4.4 Scalability graph 35 4.5 Usability graph 37 4.6 ACL graph 38 4.7 Documentation graph 40 4.8 Support graph 41 4.9 Training graph 42 4.10 OS Support graph 44 4.11 Advantages graph 47 4.12 Disadvantages graph 48 4.13 Satisfaction graph 49 4.14 Deployment properties graph 50 4.15 Specification Management properties graph 52 xiii 1 Introduction In the enterprise of the present, when a large number of services is involved in the business of companies, there is a need for structure and consistency as well as a need for rapid deployments. Companies services usually consist of several parts, two of them being software and network infrastructure, e.g., servers. Many companies tend to use cloud services either for themselves or to provide their services to another enterprise. There is also part of an enterprise which for different reasons, for example, security, decides to host their servers in-house. Each of these worlds deals with the same challenges and are sig- nificantly affected by modern IT demands. The client usually wants to have their service up and to run as fast and stable as possible. As part of this trend, the term DevOps arose not limited to principles of agile development. DevOps allows companies to be able to compete on fast-growing market of nowadays. In practice, there are two approaches how one can look at this term. DevOps engineer might be a developer or a Software engineer, who is also able to perform system engineers task and vice versa [1]. "DevOps is a term given to a set of practices, ideals, and tools that are helping organizations of various sizes deliver value on their IT investments at quicker rate[2, p. 30]." As a part of DevOps, or more precisely one of the steps in this practice is methodology defining network infrastructure called Infras- tructure as a Code or shortly IaC. IaC resolves around the term of idempotence, which means the ability to set up and configure the same environment every time it is applied. Not only providing consistency to new systems but also keeping already running systems according to desired definitions as the way the environment should look and behave is defined. The administrator isn’t forced to manage a large number of servers, where each becomes unique during some period, but can keep the systems in the same stat [3]. When implementing IaC in the enterprise, it’s not possible to un- derestimate selection of the right tool, as wrong decision might result 1 1. Introduction in management dissatisfaction, delayed projects, and other unplanned complications. Thus, the thesis goals and objectives are to give insight on Infras- tructure as a Code, its history, principles, and characteristics. To discuss DevOps as a base for Infrastructure as a Code. The thesis also gives insight and explores modern trends in infras- tructure automation, e.g., configuration management. The following text also evaluates configuration management tools as users around the world see them. Last but not least the thesis practically discusses different configu- ration management tools. The structure of the thesis is following: Chapter 2, Infrastructure as a Code provides information on Infras- tructure as code, DevOps principles, and configuration management tools in general. Chapter 3, Comparison of configuration management tools com- pares different aspects of configuration management tools such as security, means of communication, etc. Chapter 4, The public survey of configuration management tools gives insight on how users perceive their CM tools in regards to prop- erties such as installability, configurability, etc. 2 2 Infrastructure as a Code 2.1 History and DevOps background of IaC In the past number of IT professionals was not as large as it is today. Over the years the complexity of systems and IT grew. Professions as a System administrator, System engineer as well as more specialized jobs as Quality assurance specialists, Database specialists or Security specialist arose. With this trend the need for automated processes became apparent. System administrators as a part of operations were responsible for keeping systems up and running. DevOps was in a way a result of this continual fast expansion of IT but isn’t as new as it might seem at first glance. The term DevOps is splittable into two separate words "Development" and "Operations". This particular methodology is a convergence of several principles, as the Lean movement, Agile principles, Theory of constraints, change management, quality assurance (QA), product management and oth- ers, two of the most notable being Lean and Agile. Agile arose around the end of the second millennium and is in a way successor to waterfall model, with its incremental releases, small changes, and highly self- motivated teams.
Load more

Recommended publications
  • A Study of the Effectiveness of Cloud Infrastructure
    A STUDY OF THE EFFECTIVENESS OF CLOUD INFRASTRUCTURE CONFIGURATION A Thesis Presented to the Faculty of California State Polytechnic University, Pomona In Partial Fulfillment Of the Requirements for the Degree Master of Science In Computer Science By Bonnie Ngu 2020 SIGNATURE PAGE THESIS: A STUDY OF THE EFFECTIVENESS OF CLOUD INFRASTRUCTURE CONFIGURATION AUTHOR: Bonnie Ngu DATE SUBMITTED: Spring 2020 Department of Computer Science Dr. Gilbert S. Young _______________________________________ Thesis Committee Chair Computer Science Yu Sun, Ph.D _______________________________________ Computer Science Dominick A. Atanasio _______________________________________ Professor Computer Science ii ACKNOWLEDGEMENTS First and foremost, I would like to thank my parents for blessing me with the opportunity to choose my own path. I would also like to thank Dr. Young for all the encouragement throughout my years at Cal Poly Pomona. It was through his excitement and passion for teaching that I found my passion in computer science. Dr. Sun and Professor Atanasio for taking the time to understand my thesis and providing valuable input. Lastly, I would like to thank my other half for always seeing the positive side of things and finding the silver lining. It has been an incredible chapter in my life, and I could not have done it without all the love and moral support from everyone. iii ABSTRACT As cloud providers continuously strive to strengthen their cloud solutions, companies, big and small, are lured by this appealing prospect. Cloud providers aim to take away the trouble of the brick and mortar of physical equipment. Utilizing the cloud can help companies increase efficiency and improve cash flow.
    [Show full text]
  • Lessons Learned from a Large-Scale Infrastructure As Code Project
    PowerShell Conference Europe 2019 Hannover, Germany June 4-7, 2019 Lessons learned from a large-scale infrastructure as code project Platinum Sponsor Mark Warneke After this Session - I am able to develop a mature “Infrastructure As Code” project from scratch using a Test-Driven development approach, avoiding common pitfalls and getting a heads up in necessary considerations, tools and best practices - I can build sophisticated Azure Release Pipelines that leverage advanced testing scenarios using Azure Resource Manager Templates, PowerShell tooling to support an advanced “Infrastructure As Code” project @MarkWarneke Agenda Introduction Architecture Demo @MarkWarneke By viewing cloud computing as a starting point for IT automation, companies may be able to have it all: scalability, agility, flexibility, efficiency, “ and cost savings. But that’s only possible by building up both automation and cloud capabilities. – McKinsey @MarkWarneke“ What is the challange? Speed Control Agility @MarkWarneke Why change? Servers Services @MarkWarneke Paradigm shift Enforce/Control Enable/Support Controlled & central responsibility Freedom & delegated responsibility @MarkWarneke What organization want Secure, predictable, and flexible Control service delivery and operations capability (end to end traceability). Faster business innovation through Innovation adoption of cloud services. Business agility and reduced time-to- Speed/Agility market through efficient DevOps teams. Costs Efficient use of public cloud scale. @MarkWarneke DevOps benefits based on research Source: 2018 State of DevOps Report DORA @MarkWarneke A Cloud Center of Excellence (CCoE) is a cross- functional team of people responsible for developing and managing the cloud strategy, “governance, and best practices that the rest of the organization can leverage to transform the business using the cloud.
    [Show full text]
  • Adoption, Support, and Challenges of Infrastructure-As-Code: Insights from Industry
    Adoption, Support, and Challenges of Infrastructure-as-Code: Insights from Industry Michele Guerriero,1 Martin Garriga,2 Damian A. Tamburri,3 Fabio Palomba4 1Politecnico di Milano, Italy 2Jheronimus Academy of Data Science & Tilburg University, The Netherlands 3Jheronimus Academy of Data Science & Eindhoven University of Technology, The Netherlands 4University of Zurich, Switzerland [email protected], [email protected], [email protected], palomba@ifi.uzh.ch Abstract—Infrastructure-as-code (IaC) is the DevOps tactic semi-structured interviews in as many companies to distill: (1) of managing and provisioning infrastructure through machine- how practitioners currently develop infrastructural code — that readable definition files, rather than physical hardware config- is, the best/bad practices experienced by the practitioners as uration or interactive configuration tools. From a maintenance and evolution perspective, the topic has piqued the interest of IaC blueprints grow in size and maintenance costs [8], (2) practitioners and academics alike, given the relative scarcity of what is the automatic support available — that is, pros and supporting patterns, best practices, tools, and software engineer- cons of using existing tools in practice, and (3) the challenges ing techniques. Using the data coming from 44 semi-structured reported by the practitioners via direct experience — that is, interviews in as many companies, in this paper we shed light the research and industrial avenues that practitioners perceive on the state of the practice in the adoption of IaC and the key software engineering challenges in the field. Particularly, as worthy of investigation in the near future. we investigate (i) how practitioners adopt and develop IaC, (ii) Data on the above points reveals a number of results as well which support is currently available, i.e., the typically used as valuable avenues for further work.
    [Show full text]
  • INFRASTRUCTURE AS CODE–FINAL REPORT John Klein, Phd and Douglas Reynolds December 2018
    INFRASTRUCTURE AS CODE–FINAL REPORT John Klein, PhD and Douglas Reynolds December 2018 1 Introduction This report concludes work on Research Project 6-18 518 Feasibility of Infrastructure as Code, summarizing the problem addressed by the research, the research solution approach, and results. 1.1 Background 1.1.1 What Is Infrastructure as Code? Infrastructure as code (IaC) is a set of practices that use “code (rather than manual commands) for setting up (virtual) machines and networks, installing packages, and configuring the environment for the application of interest” [3]. The infrastructure managed by this code includes both physical equipment (“bare metal”) and virtual machines, containers, and software-defined networks. This code should be developed and managed using the same processes as any other software; for example, it should be designed, tested, and stored in a version-controlled repository. Although information technology (IT) system operators have long employed automation through ad hoc scripting of tasks, IaC technology and practices emerged with the introduction of cloud computing, and particularly infrastructure-as-a-service (IaaS) technology. In an IaaS-based envi- ronment, all computation, storage, and network resources are virtualized and must be allocated and configured using application programming interfaces (APIs). While cloud service providers furnish management consoles that layer an interactive application on top of the APIs, it is not practical to use a management console to create a system with more than a couple of nodes. For example, creating a new virtual machine (VM) using the Amazon Web Services management console requires stepping through at least five web forms and filling in 25 or more fields.
    [Show full text]
  • Adopting 'Infrastructure As Code' Misha Zynovyev (GSI)
    Adopting 'Infrastructure as Code' Misha Zynovyev (GSI) adopting 'infrastructure as code' to run HEP applications Misha Zynovyev ([email protected]) Dennis Klein ([email protected]) Victor Penso ([email protected]) HEPiX Spring 2011 GSI, Darmstadt, 5th of May 2011 Adopting 'Infrastructure as Code' Misha Zynovyev (GSI) acknowledgements Dr. Peter Malzacher Bastian Neuburger Christopher Huhn Dr. Stefan Haller Helge Brust Oliver Wirth Adopting 'Infrastructure as Code' Misha Zynovyev (GSI) outline of the talk our mission statement current approaches to infrastructure management our approach to running HEP applications describing infrastructure with code our playgrounds results outlook Adopting 'Infrastructure as Code' Misha Zynovyev (GSI) clarification target audience: developers, system administrators and infrastructure providers you accept the benefits of virtualization presented concepts are transparent to users1 this is not about how to build the Infrastructure-as-a-Service (IaaS) clouds, but about efficient ways to use them 1nevertheless users can have as much control of details as they can cope with Adopting 'Infrastructure as Code' Misha Zynovyev (GSI) our mission statement we want to simplify deployment and operation of scientific computing applications and their infrastructure by describing everything in code furthermore, we need a mechanism which will allow us to use external resources provided by IaaS clouds in a transparent way Adopting 'Infrastructure as Code' Misha Zynovyev (GSI) deploying infrastructure manual (with OS tools, text-editor):
    [Show full text]
  • Salt Documentation Release 2014.7.6
    Salt Documentation Release 2014.7.6 SaltStack, Inc. May 19, 2015 Contents 1 Introduction to Salt 1 1.1 e 30 second summary ........................................... 1 1.2 Simplicity ................................................... 1 1.3 Parallel execution ............................................... 1 1.4 Building on proven technology ....................................... 2 1.5 Python client interface ............................................ 2 1.6 Fast, flexible, scalable ............................................. 2 1.7 Open ...................................................... 2 1.8 Salt Community ................................................ 2 1.9 Mailing List .................................................. 2 1.10 IRC ....................................................... 3 1.11 Follow on Github ............................................... 3 1.12 Blogs ...................................................... 3 1.13 Example Salt States .............................................. 3 1.14 Follow on ohloh ................................................ 3 1.15 Other community links ............................................ 4 1.16 Hack the Source ................................................ 4 2 Installation 5 2.1 ick Install .................................................. 5 2.2 Platform-specific Installation Instructions ................................. 5 2.3 Dependencies ................................................. 26 2.4 Optional Dependencies ............................................ 27 2.5 Upgrading
    [Show full text]
  • CV - Russell Dunphy [email protected] | 07849465404 |
    CV - Russell Dunphy [email protected] | 07849465404 | https://www.linkedin.com/in/rsslldnphy/ An experienced software developer, technical leader, and manager, with a love of functional ​ ​ ​ ​ ​ ​ ​ programming and coding as language. Came to programming by a somewhat unusual route: ​ ​ ​ a first class degree in Creative Writing. I see people, teams, code, and infrastructure as an interconnected ecosystem, and enjoy ​ ​ tending that ecosystem by sitting at the intersection of them all: doing people management, process optimisation, architecture, and coding as and when needed. I also enjoy developing long-term technical strategy, taking into account how this ecosystem fits into the wider business ​ ​ context, and finding sustainable, iterative ways to implement it. I’ve managed teams ranging in size from two to twelve, including developers, data scientists, scrum masters and testers. I’ve worked with a number of languages, most recently Clojure, ​ ​ Clojurescript, and Javascript/Typescript, and love learning more. I’m happy wrangling ​ ​ ​ ​ ​ infrastructure, doing backend work, or building frontend features. Most of all I like finding ways to make these different levels of the stack, and the people who work on them, form a cohesive whole. Employment Head of Engineering - HealthUnlocked Jun 2016 - Present ​ HealthUnlocked is social network for health, with around 3-4 million unique sessions per month. As Head of Engineering I am responsible for managing the tech team; for recruitment; for setting technical strategy for the organisation;
    [Show full text]
  • Python Guide Documentation 0.0.1
    Python Guide Documentation 0.0.1 Kenneth Reitz 2015 11 07 Contents 1 3 1.1......................................................3 1.2 Python..................................................5 1.3 Mac OS XPython.............................................5 1.4 WindowsPython.............................................6 1.5 LinuxPython...............................................8 2 9 2.1......................................................9 2.2...................................................... 15 2.3...................................................... 24 2.4...................................................... 25 2.5...................................................... 27 2.6 Logging.................................................. 31 2.7...................................................... 34 2.8...................................................... 37 3 / 39 3.1...................................................... 39 3.2 Web................................................... 40 3.3 HTML.................................................. 47 3.4...................................................... 48 3.5 GUI.................................................... 49 3.6...................................................... 51 3.7...................................................... 52 3.8...................................................... 53 3.9...................................................... 58 3.10...................................................... 59 3.11...................................................... 62
    [Show full text]
  • Python Guide Documentation 0.0.1
    Python Guide Documentation 0.0.1 Kenneth Reitz 2015 09 13 Contents 1 Getting Started 3 1.1 Picking an Interpreter..........................................3 1.2 Installing Python on Mac OS X.....................................5 1.3 Installing Python on Windows......................................6 1.4 Installing Python on Linux........................................7 2 Writing Great Code 9 2.1 Structuring Your Project.........................................9 2.2 Code Style................................................ 15 2.3 Reading Great Code........................................... 24 2.4 Documentation.............................................. 24 2.5 Testing Your Code............................................ 26 2.6 Common Gotchas............................................ 30 2.7 Choosing a License............................................ 33 3 Scenario Guide 35 3.1 Network Applications.......................................... 35 3.2 Web Applications............................................ 36 3.3 HTML Scraping............................................. 41 3.4 Command Line Applications....................................... 42 3.5 GUI Applications............................................. 43 3.6 Databases................................................. 45 3.7 Networking................................................ 45 3.8 Systems Administration......................................... 46 3.9 Continuous Integration.......................................... 49 3.10 Speed..................................................
    [Show full text]
  • Devops: Introducing Infrastructure-‐As-‐Code
    DevOps: Introducing Infrastructure-as-Code Elisabetta Di Nitto, Damian A. Tamburri*, Michele Guerriero*, Matej Artac+, Tadej Borovsak+ *Politecnico di Milano +XLAB Corp. Roadmap o Session 1: DevOps In a Nutshell o Break! (5 mins) o Session 2: Infrastructure-as-code Explained through TOSCA o Session 3: Our proposal to connect Dev and Ops: the DICER tool Session 1 DevOps In a Nutshell Dev & Ops: the classical roles Dev focuses on o Developing features o Changing requirements o Releasing products Ops focuses on o Offering services o Providing guarantees and stability Dev vs. Ops “The system works correctly in the development machine but it does not on the operation machine” “10 days after successful deployment of last release, the system is overloaded” Who is guilty? Dev– team, or –Ops team? The problem: two disconnected groups • Dev works to apply releases • Ops resists to releases • Dev does not pay attention • Ops is aiming at to QoS guarantees guaranteering QoS • Changes are fundamental for the business! • QoS guarantees are needed too! DevOps • What is it: “Practices or tools that bridge the gap between development and operations” • Goal: Creates a collaborative mindset where a single team performs Dev and Ops àthe team must contain differentiated competences, background, etc. • Requires: • Culture management; • Automation tools; • Organisational as much as technical metrics • Continuous sharing artifacts, procedures, languages, approaches… DevOps Need 1: Process Alignment! - Unified Processes - Unified tooling Before DevOps Development
    [Show full text]
  • Infrastructure As Code (Iac) to Reduce Provisioning Time by 65%
    Infrastructure as Code (IaC) to Reduce Provisioning Time by 65% Credits Deepak Jayagopal Kanapathi Raja Sathya Narayanan Higher Elasticity And Scale of Infrastructure Has Made it Cumbersome to Manually Provision Even After The Adoption of Cloud Computing Legacy manual provisioning Cloud manual provisioning Evolution of of infrastructure infrastructure • Traditionally, Infrastructure provisioning has • Using cloud computing (Infrastructure as provisioning always been a manual process. a Service), an instant computing • Teams would rack and stack the servers and infrastructure could be provisioned and will manually configure them. managed over the internet. • Finally, they will install the application over • Cloud computing reduced the need for that hardware. high upfront capital expenditure as well • This used to be a slow process and there were as maintenance costs. a lot of accuracy and consistency issues. Infrastructure as Code (IaC) Infrastructure as Code IaC allows DevOps IaC takes cloud (IaC) is the process of engineers to view computing to its provisioning and complex maximum potential by managing the entire infrastructure in a automating the infrastructure through a codified way. manual, error-prone series of software. provisioning tasks. Cloud infrastructure solved many issues pertaining to the legacy provisioning methods. However, there are still issues persisting with manual provisioning of cloud infrastructure. Confidential & Restricted 2 Major Challenges with Manual Provisioning of Cloud Infrastructure DSPs across the globe have a Time consuming in Higher cost great necessity to adopt a provisioning infrastructure strong cloud strategy to deliver digital services across In the case of huge infrastructures, the time Cost is calculated per hour by taken to manual cloud provisioning gets cloud vendors.
    [Show full text]
  • Co-Evolution of Infrastructure and Source Code - an Empirical Study
    Co-evolution of Infrastructure and Source Code - An Empirical Study Yujuan Jiang, Bram Adams MCIS lab Polytechnique Montreal, Canada Email: yujuan.jiang,bram.adams @polymtl.ca { } Abstract—Infrastructure-as-code automates the process of have a high coupling with source code and test files, which configuring and setting up the environment (e.g., servers, VMs means that developers and testers need to perform a certain and databases) in which a software system will be tested and/or effort to maintain the build system files as the code and tests deployed, through textual specification files in a language like evolve. Based on these findings, we conjecture that IaC could Puppet or Chef. Since the environment is instantiated auto- run similar risks and generate similar maintenance overhead matically by the infrastructure languages’ tools, no manual as regular build scripts. intervention is necessary apart from maintaining the infrastruc- ture specification files. The amount of work involved with such In order to validate this conjecture, we perform an empir- maintenance, as well as the size and complexity of infrastructure ical case study on 265 OpenStack projects. OpenStack is an specification files, have not yet been studied empirically. Through ecosystem of projects implementing a cloud platform, which an empirical study of the version control system of 265 OpenStack requires substantial IaC to support deployment and tests on projects, we find that infrastructure files are large and churn frequently, which could indicate a potential of introducing bugs. virtual machines. The study replicates the analysis of McIntosh Furthermore, we found that the infrastructure code files are et al.
    [Show full text]