Linux Patch Management: Comparison of Practical Implementations

Total Page:16

File Type:pdf, Size:1020Kb

Linux Patch Management: Comparison of Practical Implementations l Linux Patch Management: Comparison of Practical Implementations Teemu Pulliainen 2016 Master’s Degree Programme in Information Technology Author Type of publication Date Pulliainen, Teemu Master’s thesis May 2016 Language of publication: English Number of pages: 71 Permission for web publication: x Title of publication Linux Patch Management: Comparison of Practical Implementations Degree programme Master’s Degree Programme in Information Technology Supervisors Rantonen, Mika Häkkinen, Antti Assigned by Maatalouden Laskentakeskus Oy Abstract Recent public, high-profile vulnerabilities in widely used IT architecture components pose a sig- nificant risk to IT systems. As far as public vulnerabilities are concerned, In most cases a mitiga- tion is readily available in a form of a software patch. The remaining issues are thus how to get informed about released patches, how to deploy them in a timely manner and how to ensure the patches are applied to all affected targets. The answer is usually some form of a patch man- agement system. Within a heterogeneous Linux Linux environment no established, industry standard way of de- ploying a patch management system exists. The objective was to study different deployment methods and select the most appropriate one according to the employer requirements, but also to give an insight on the others for the general public. An example implementation of three dif- ferent patch management approaches was carried out in a test environment and each one re- searched and compared to the others. The first approach was creating a system from scratch the second using general-purpose configuration management software and the last was using a ded- icated patch management software. The research was successful. A functional implementation was accomplished with each ap- proach and valuable experience was gained on each one. The positive and negative aspects of all alternatives were examined and recommendation for the overall best solution based on the em- ployer requirements was also given. One should note, however, that such a recommendation is heavily dependent on the environment. The actual implementation to employer environment was not covered. Keywords Patch management, Configuration management, Linux Tekijä Julkaisun laji Päivämäärä Pulliainen, Teemu Opinnäytetyö, ylempi AMK 05 2015 Sivumäärä Julkaisun kieli englanti Verkkojulkaisulupa myönnetty: x Työn nimi Linux Patch Management: Comparing by Practical Implementations Tutkinto-ohjelma Master’s Degree Programme in Information Technology Työn ohjaajat Rantonen, Mika Häkkinen, Antti Toimeksiantaja Maatalouden Laskentakeskus Oy Tiivistelmä Viimeaikaiset laajaa julkisuutta saaneet haavoittuvuudet kriittisissä tietoteknisten jär- jestelmien komponenteissa aiheuttavat merkittävän riskin tietojärjestelmien toiminnalle. Yleiseen tietoon tulevien haavoittuvuuksien osalta korjauspäivitykset ovat useimmiten saatavilla. Jäljelle jäävät kysymykset koskevat siis sitä, kuinka saada tieto päivitysten julkaisemisesta, kuinka päivitykset asennetaan järkevässä ajassa ja kuinka varmistua päivi- tysten asentumisesta. Usein vastauksena toimii päivitysten hallintajärjestelmä. Useita jakeluversioita käsittävien Linux-ympäristöjen osalta ei ole olemassa vakiintunutta tapaa ottaa käyttöön järjestelmä päivitysten hallintaa varten. Tavoitteena oli tutkia erilaisia tapoja hallintajärjestelmän käyttöönottoon ja valita niistä toimeksiantajan kriteereihin parhaiten sopiva toteutus. Toisena tavoitteena oli tarjota suurelle yleisölle tietoa eri tavoista päivitysten hallintaan Linux-ympäristöissä. Kolme erilaista esimerkkitoteutusta otettiin käyttöön testiympäristössä. Eri toteutustapoja tutkittiin ja verrattiin muihin. Ensim- mäisenä toteutustapana toimi täysin itse kehitetty järjestelmä, toisena yleisten asetusten- hallintatyökalujen käyttöön perustuva järjestelmä ja kolmantena nimenomaan päivitysten hallintaan tarkoitettu järjestelmä. Tutkimus onnistui ja jokaisella tutkitulla toteutusvaihtoehdolla saatiin otettua käyttöön mekanismi päivitysten hallintaan. Vaihtoehdoista saatiin kerättyä hyödyllistä tietoa, niiden hyviä ja huonoja puolia punnittiin ja toimeksiantajan vaatimusten perusteella saatiin aikaan suositus toteutettavasta järjestelmästä. Myös yleistä tietoa ja suosituksia eri järjestelmien soveltuvuudesta erilaisiin ympäristöihin saatiin tuotettua. Avainsanat (asiasanat) Linux, muutoksenhallinta, konfiguraation hallinta, tietoturvapäivitys 1 Contents 1 Introduction.......................................................................................4 1.1 Assigner................................................................................................................4 1.2 Motivation and Background.................................................................................4 1.3 Thesis Execution Phases.......................................................................................5 1.4 Objectives and Methods of the Research............................................................5 1.5 Research Scope, Delimitation and Known Challenges.........................................7 2 Background to the Research................................................................8 2.1 Vulnerabilities and Attack Vectors.......................................................................9 2.2 Theory and Processes of Patch Management....................................................10 2.3 Architecture of Patch Management Software...................................................16 2.4 Introduction to Linux Software Management....................................................21 3 Test Environment..............................................................................22 3.1 Overview............................................................................................................22 3.2 Internal Software Repository.............................................................................22 4 Implementation Options...................................................................24 4.1 Self-created........................................................................................................24 4.1.1 Preparation.........................................................................................................................24 4.1.2 Testing Patch Automation on Command Line.....................................................................25 4.1.3 Patch automation on CLI: an interactive approach.............................................................26 4.1.4 Creating a Proof-of-Concept Web Interface.......................................................................29 4.1.5 Creating the Patching Application.......................................................................................31 4.2 Automatizing with Configuration Management Software.................................39 4.2.1 Introducing Configuration Management Systems..............................................................39 4.2.2 Deploying Ansible...............................................................................................................41 4.3 Patch Management Software.............................................................................50 4.3.1 Introduction to Spacewalk..................................................................................................50 4.3.2 Installing and Configuring Spacewalk.................................................................................50 4.4 Comparison........................................................................................................57 5 Conclusions.......................................................................................59 5.1 Self-Created PatchApp.......................................................................................59 2 5.2 Configuration Management Approach..............................................................61 5.3 Spacewalk...........................................................................................................62 5.4 Final Conclusions................................................................................................63 5.5 Reflections on the Research and Further Study.................................................64 References...........................................................................................66 Appendices..........................................................................................68 Figures Figure 1. Architecture proposal (Nicastro, 2011, Chapter 3)........................................12 Figure 2. Architecture proposal from White (2004, 2).................................................19 Figure. 3. Test network topology...................................................................................23 Figure 4. Running apt-get on Debian cluster................................................................28 Figure 5. Running uname on all clusters.......................................................................28 Figure 6. Initial PSSH output on browser......................................................................31 Figure 7. Front page with host listing...........................................................................36 Figure 8. Confirmation dialog before update...............................................................37 Figure 9. Deploying updates.........................................................................................38 Figure 10. Semaphore hosts definition.........................................................................48
Recommended publications
  • Quick-And-Easy Deployment of a Ceph Storage Cluster with SLES with a Look at SUSE Studio, Manager and Build Service
    Quick-and-Easy Deployment of a Ceph Storage Cluster with SLES With a look at SUSE Studio, Manager and Build Service Jan Kalcic Flavio Castelli Sales Engineer Senior Software Engineer [email protected] [email protected] Agenda Ceph Introduction System Provisioning with SLES System Provisioning with SUMa 2 Agenda Ceph Introduction SUSE Studio System Provisioning with SLES SUSE Manager System Provisioning with SUMa 3 Ceph Introduction What is Ceph • Open-source software-defined storage ‒ It delivers object, block, and file storage in one unified system • It runs on commodity hardware ‒ To provide an infinitely scalable Ceph Storage Cluster ‒ Where nodes communicate with each other to replicate and redistribute data dynamically • It is based upon RADOS ‒ Reliable, Autonomic, Distributed Object Store ‒ Self-healing, self-managing, intelligent storage nodes 5 Ceph Components Monitor Ceph Storage Cluster Object Storage Device (OSD) Ceph Metadata Server (MDS) Ceph Block Device (RBD) Ceph Object Storage (RGW) Ceph Clients Ceph Filesystem Custom implementation 6 Ceph Storage Cluster • Ceph Monitor ‒ It maintains a master copy of the cluster map (i.e. cluster members, state, changes, and overall health of the cluster) • Ceph Object Storage Device (OSD) ‒ It interacts with a logical disk (e.g. LUN) to store data (i.e. handle the read/write operations on the storage disks). • Ceph Metadata Server (MDS) ‒ It provides the Ceph Filesystem service. Purpose is to store filesystem metadata (directories, file ownership, access modes, etc) in high-availability Ceph Metadata Servers 7 Architectural Overview 8 Architectural Overview 9 Deployment Overview • All Ceph clusters require: ‒ at least one monitor ‒ at least as many OSDs as copies of an object stored on the cluster • Bootstrapping the initial monitor is the first step ‒ This also sets important criteria for the cluster, (i.e.
    [Show full text]
  • Spacewalk 2.0 for Oracle® Linux 6 Release Notes
    Spacewalk 2.0 for Oracle® Linux 6 Release Notes E51125-11 August 2017 Oracle Legal Notices Copyright © 2013, 2017, Oracle and/or its affiliates. All rights reserved. This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited. The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing. If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, then the following notice is applicable: U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S.
    [Show full text]
  • Installation Guide: Uyuni 2020.05
    Installation Guide Uyuni 2020.05 May 19, 2020 Table of Contents GNU Free Documentation License 1 Introduction 8 Installing Uyuni . 8 General Requirements 9 Obtain Your SUSE Customer Center Credentials . 9 Obtain the Unified Installer . 9 Supported Browsers for the SUSE Manager Web UI . 10 Partition Permissions . 10 Hardware Requirements . 11 Server Hardware Requirements . 11 Proxy Hardware Requirements . 12 Network Requirements . 13 Network Ports . 14 Public Cloud Requirements . 19 Instance Requirements. 20 Network Requirements . 20 Separate Storage Volumes. 20 Installation 22 Installing Uyuni 2020.05 Server. 22 Uyuni 2020.05 Proxy . 25 Install SUSE Manager in a Virtual Machine Environment with JeOS. 27 Virtual Machine Manager (virt-manager) Settings . 27 JeOS KVM Settings . 28 Preparing JeOS for SUSE Manager . 28 Install Uyuni Proxy from packages. 30 SLES KVM Requirements. 30 Change SLES for SUSE Manager Proxy . 31 Installing on IBM Z . 32 System Requirements . 33 Install Uyuni on IBM Z . 34 Setting Up 35 SUSE Manager Server Setup . 35 Set up Uyuni with YaST . 35 Creating the Main Administration Account . 37 Synchronizing Products from SUSE Customer Center. 38 SUSE Manager Proxy Registration . 40 SUSE Manager Proxy Setup. 44 Copy Server Certificate and Key . 44 Run configure-proxy.sh. 45 Enable PXE Boot . 46 Replace a Uyuni Proxy . 47 Web Interface Setup . 48 Web Interface Navigation . 49 Public Cloud Setup. 51 Account Credentials . 52 Setup Wizard . 53 Configure the HTTP Proxy . 53 Configure Organization Credentials. 53 Configure Products . 54 GNU Free Documentation License Copyright © 2000, 2001, 2002 Free Software Foundation, Inc. 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
    [Show full text]
  • IBM Red Hat Ansible Health Check Is Your Red Hat Ansible Environment Working As Hard As You Are?
    IBM Red Hat Ansible health check Is your Red Hat Ansible environment working as hard as you are? Highlights Your journey to cloud has many stops along the way. And, as with all journeys, it’s crucial to know where you want to be and how you’ll get there. No one solution is perfect without some tweaking of the software and tools. And, not all individuals Understand your progress and have experience in Red Hat® solutions and cloud environment management to align to your vision and roadmap. finetune tools as they progress. And, that’s where IBM can help. IBM Services® offers IBM Red Hat Ansible Health Check service to help you get Work to further achieve the goals the most from your Red Hat Ansible®, Ansible Tower and cloud investments by of Ansible and Ansible Tower— highlighting areas for you to adjust. The IBM specialists perform an assessment simplicity, security and stability. based on common challenges, such as provisioning, orchestration, automation, playbooks and processes, including continuous integration or continuous delivery Gain operational efficiencies (CI/CD). Following the 2.5-hour assessment session, you’ll receive a report that with Ansible in the areas of: will identify areas of concern, provide recommendations and help you make more – Infrastructure as code informed decisions for your enterprise and cloud environment. and provisioning – Compliance as code, Helping understand the complexities of automating, configuration management and security automation optimizing and allocating resources – Application deployment, While Ansible is incredibly flexible and adaptable, automation and provisioning orchestration and CI/CD can be complex with the number of technologies that are required to complete the tasks across multiple vendor environments, operating systems, hybrid clouds, – Network automation networks, plugins, modules and APIs.
    [Show full text]
  • Release 3.11.0
    CEKit Release 3.11.0 May 17, 2021 Contents 1 About 3 2 Main features 5 3 I’m new, where to start? 7 4 Releases and changelog 9 5 Contact 11 6 Documentation 13 6.1 Getting started guide........................................... 13 6.2 Handbook................................................ 19 6.3 Guidelines................................................ 61 6.4 Descriptor documentation........................................ 75 6.5 Contribution guide............................................ 137 7 Sponsor 143 8 License 145 i ii CEKit, Release 3.11.0 Contents 1 CEKit, Release 3.11.0 2 Contents CHAPTER 1 About Container image creation tool. CEKit helps to build container images from image definition files with strong focus on modularity and code reuse. 3 CEKit, Release 3.11.0 4 Chapter 1. About CHAPTER 2 Main features • Building container images from YAML image definitions using many different builder engines • Integration/unit testing of images 5 CEKit, Release 3.11.0 6 Chapter 2. Main features CHAPTER 3 I’m new, where to start? We suggest looking at the getting started guide. It’s probably the best place to start. Once get through this tutorial, look at handbook which describes how things work. Later you may be interested in the guidelines sections. 7 CEKit, Release 3.11.0 8 Chapter 3. I’m new, where to start? CHAPTER 4 Releases and changelog See the releases page for latest releases and changelogs. 9 CEKit, Release 3.11.0 10 Chapter 4. Releases and changelog CHAPTER 5 Contact • Please join the #cekit IRC channel on Freenode • You can always mail us at: cekit at cekit dot io 11 CEKit, Release 3.11.0 12 Chapter 5.
    [Show full text]
  • Spacewalk + Fedora = 42
    Spacewalk + Fedora = 42 What is Spacewalk? A systems management platform designed to provide complete lifecycle management of the operating system and applications. ● Inventory your systems (hardware & software information) ● Install and update software on your systems ● Manage and deploy configuration files ● Collect and distribute custom software packages ● Provision (Kickstart) your systems ● Monitor your systems ● Provision/Manage virtual guests Life Cycle of a System ● Provision a new system (on hardware or virt) ● Install software/updates ● Configure software ● Continued management of system ● Re-provision for a new purpose How can I manage my custom software? ● Create custom channels ● Allows control over latest software a system can install ● Store custom software within custom channels ● Easily install/update/remove packages from web interface How can I configure my software? ● Built in configuration management ● Rank configuration channels based on priority ● Can be deployed at provisioning/registration time ● Local overrides for individual systems ● Supports multiple revisions of files/directories ● Import existing files from systems ● Diff configuration files between actual and stored revisions How can I manage these systems across my organizations? ● Completely separate content and systems ● Manage entitlements across organizations ● Restrict entitlement usage ● Upcoming features – Custom Channel Sharing between orgs – Migrate registered systems between orgs Check out the MultiOrg Best Practices Whitepaper: https://www.redhat.com/f/pdf/rhn/Multiorg-whitepaper_final.pdf
    [Show full text]
  • Spacewalk 2.4 for Oracle® Linux Concepts and Getting Started Guide
    Spacewalk 2.4 for Oracle® Linux Concepts and Getting Started Guide E71709-03 January 2017 Oracle Legal Notices Copyright © 2017, Oracle and/or its affiliates. All rights reserved. This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited. The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing. If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, then the following notice is applicable: U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S.
    [Show full text]
  • Automating the F5 BIG-IP Platform with Ansible | F5 Technical White
    + TECHNICAL WHITE PAPER Automating the F5 BIG-IP Platform with Ansible TECHNICAL WHITE PAPER Automating the F5 BIG-IP Platform with Ansible Contents Introduction 3 The programmable network 3 A comprehensive joint solution 4 Use case: configure an HTTPS application on the BIG-IP platform 4 Conclusion 9 2 TECHNICAL WHITE PAPER Automating the F5 BIG-IP Platform with Ansible Introduction “The key drivers for the use of DevOps-related frameworks and toolsets remain scalability and reduction of operational expenses.”1 Traditionally, organizations deploy infrastructure and applications using a combination of various documents such as deployment guides along with many manual processes and operations. It’s a time-consuming approach that doesn’t align with ever-increasing requirements for speed and agility. The need to deploy full application stacks and services more quickly and more often in a repeatable manner has driven both development and operational teams toward automation and orchestration. In addition to enabling organizations to better manage applications, infrastructure deployments, and the process of provisioning and de-provisioning, automation reduces the amount of IT resources required and ensures increased reliability, efficiency, and agility. The programmable network Through a deep understanding of best practices for networking and application delivery, F5 empowers organizations to take advantage of the benefits of automation and programmability as they configure and manage devices on the BIG-IP platform. Both the hardware and virtual editions of F5 Application Delivery Controllers (ADCs) feature flexible and programmable management, control and data planes. F5 ADCs achieve programmability through the following features: 1. Traffic Management Shell (tmsh): Allows complete access to configure system features and set up and manage network elements.
    [Show full text]
  • Ceph – Software Defined Storage Für Die Cloud
    Ceph – Software Defined Storage für die Cloud CeBIT 2016 15. März 2015 Michel Rode Linux/Unix Consultant & Trainer B1 Systems GmbH [email protected] B1 Systems GmbH - Linux/Open Source Consulting, Training, Support & Development Vorstellung B1 Systems gegründet 2004 primär Linux/Open Source-Themen national & international tätig über 70 Mitarbeiter unabhängig von Soft- und Hardware-Herstellern Leistungsangebot: Beratung & Consulting Support Entwicklung Training Betrieb Lösungen dezentrale Strukturen B1 Systems GmbH Ceph – Software Defined Storage für die Cloud 2 / 36 Schwerpunkte Virtualisierung (XEN, KVM & RHEV) Systemmanagement (Spacewalk, Red Hat Satellite, SUSE Manager) Konfigurationsmanagement (Puppet & Chef) Monitoring (Nagios & Icinga) IaaS Cloud (OpenStack & SUSE Cloud & RDO) Hochverfügbarkeit (Pacemaker) Shared Storage (GPFS, OCFS2, DRBD & CEPH) Dateiaustausch (ownCloud) Paketierung (Open Build Service) Administratoren oder Entwickler zur Unterstützung des Teams vor Ort B1 Systems GmbH Ceph – Software Defined Storage für die Cloud 3 / 36 Storage Cluster B1 Systems GmbH Ceph – Software Defined Storage für die Cloud 4 / 36 Was sind Storage Cluster? hochverfügbare Systeme verteilte Standorte skalierbar (mehr oder weniger) Problem: Häufig Vendor-Lock-In 80%+ basieren auf FC B1 Systems GmbH Ceph – Software Defined Storage für die Cloud 5 / 36 Beispiele 1/2 Dell PowerVault IBM SVC NetApp Metro Cluster NetApp Clustered Ontap ... B1 Systems GmbH Ceph – Software Defined Storage für die Cloud 6 / 36 Beispiele 2/2 AWS S3 Rackspace Files Google Cloud
    [Show full text]
  • Be Prepared for the SAP Digital Core
    White Paper Digital Be Prepared to Transform the SAP Core Infrastructure White Paper Be Prepared for the SAP Core Infrastructure Introduction What does a move to SAP HANA mean for your infrastructure? If you want to get the most from your HANA migration, pay attention to the the foundation for your SAP environment. The SAP HANA database and business applications offer a powerful path to increased efficiency and better business intelligence, but SAP’s software products are only part of the solution. Your SAP environment rests atop a core set of services and infrastructure. If you want your transition to SAP HANA to go smoothly, you’ll need to be prepared with a versatile and well-integrated infrastructure that includes operating systems, drivers, virtualization tools, orchestration and management components, plus all the rest of the software infrastructure underpinning your SAP environment. Getting Started Software-defined infrastructure The starting point for your SAP core infrastructure is Linux because Application delivery SAP HANA only runs on Linux systems. Choose an open source Lifecycle management vendor with a good reputation for SAP support but then take a closer High availability look at the surrounding landscape. Advanced data tools Automation SAP’s HANA environment is an advanced database solution that SAP affinity leverages a diverse combination of data sources and deployment technologies. You’ll need an infrastructure that supports the full If you are thinking about implementing SAP HANA, or if you are range of SAP features and leaves room for future expansion and upgrading to HANA from a legacy SAP configuration, prepare for evolution.
    [Show full text]
  • Ansible in Depth
    ansible.com WHITEPAPER ANSIBLE IN DEPTH “Ansible is quite fun INTRODUCTION to use right away. As Ansible is an open source IT configuration management, deployment, and orchestration tool. It is unique from other management tools in many respects, aiming to provide large productivity gains to a wide soon as you write five variety of automation challenges as a more productive drop-in replacement for many core capabilities lines of code it works. in other automation solutions. Furthermore, Ansible seeks to solve major unsolved IT challenges such as With SSH and Ansible clear orchestration of complex multi- tier workflows and cleanly unifying OS configuration and application I can send commands software deployment under a single banner. to 500 servers without Ansible is designed to be minimal in nature, consistent, secure, and highly reliable, with an extremely having even used the low learning curve for administrators, developers, and IT managers. Ansible seeks to keep descriptions servers before.” of IT easy to build, and easy to understand - such that new users can be quickly brought into new IT projects, and longstanding automation content is easily understood even after months of being away from a project. Ansible seeks to make things powerful for expert users, but equally accessible for all skill MARK MAAS UNIX/LINUX SYSTEMS levels, ensuring a quicker time to market for IT projects and faster, less-error prone turnaround on IT ADMINISTRATOR configuration change. BINCKBANK ARCHITECTURE, AGENTS, AND SECURITY One of the primary differentiators between Ansible and many other tools in this space is its architecture. Ansible is an agentless tool that runs in a ‘push’ model - no software is required to be installed on remote machines to make them manageable.
    [Show full text]
  • Microservices June 5Th and 6Th, 2017
    RHUG – MicroServices June 5th and 6th, 2017 1 Free download @ http://developers.redhat.com EVENT DETAILS: Date: June 11, 2017 Time: 8:30am - 1:30pm Location: Coors Field: 2001 Blake St., Denver, CO 80205 https://www.redhat.com/en/about/events/denver-culture- containers-and-accelerating- devops?sc_cid=701600000012CIoAAM Agenda ● What are Microservices? ● What are the benefits of Microservices? ● What is Microservices Architecture (Patterns to consider) – MSA? ● Enablement – Where to Start? ● Demo Microservices is about Agility/Speed Continuous Delivery, Deployment, Improvement Microservices Definition According to Wikipedia… • Communicate over a Network ● Services are small in size, messaging • Services in a Microservice architecture enabled, bounded by contexts, should be independently deployable autonomously developed, • The services are easy to replace independently deployable, • Services are organized around decentralized and built and released capabilities with automated processes • Services can be implemented using ● Naturally enforces a modular structure different programming ● Lends itself to a continuous languages, databases, hardware and delivery software development software environment, depending on process. what fits best Microservices Definition According to Martin Fowler … ● Componentization via Service ● Decentralized Governance and Data ● Organized Around Business Management Capabilities ● Infrastructure Automation ● Products not Projects ● Designed to be Evolutionary ● Services are organized around ● Design for Failure capabilities ● Smart Endpoints and Dumb Pipes Microservice Principles/Characteristics 1. Deployment Independence: updates to an individual Microservice have no negative impact to any other component of the system. Optimized for Replacement. 2. Organized around business capabilities. Products not Projects 3. API-Focused 4. Smart endpoints and dumb pipes 5. Decentralized Governance 6. Decentralized Data Management 7. Infrastructure Automation (infrastructure as code) 8.
    [Show full text]