Container Crash Course. Bob Familiar Director, National Practice BlueMetal, An Insight Company

Transcription

1 Container Crash Course Bob Familiar Director, National Practice BlueMetal, An Insight Company

2 Welcome to the workshop! 9:00-9:10 AM: Welcome Yung Chou 9:10-9:45 AM: Vision and Roadmap of Containers, Microservices and DevOps Bob Familiar 9:45-10:30 AM: Getting Started With Docker Containers: It's Easier Than You Think Mike Coleman BREAK 10:45-11:30 AM: Managing Containers 11:30 AM -12:00 PM: Container Security Chenxi Wang LUNCH 1:00-1:45 PM: Working With Chef Containers JJ Asghar 1:45-2:30 PM: Working With IBM Containers -- Lin Sun BREAK 3:00-4:00 PM: Working With Microsoft Containers Kevin Remde 4:00-5:00 PM: Working With AWS Containers Brian Lewis

3 Methodology Waterfall Agile Lean Engineering Process Gated Scrum Continuous Delivery Patterns 2-Tier Monolithic 3-Tier Monolithic Microservice Architecture Platform Windows / *nix Windows / *nix Cloud IaaS / PaaS Device Desktop Browser 24/7 on Any Device

4

5 How Do We Achieve Velocity Methodology Process Architecture Platform

6 Core Principals LEAN ENGINEERING DEVOPS MICROSERVICES CLOUD Methodology Process Architecture Platform

7 Lean Engineering

8 What is Lean Engineering? Deliver high quality, valuable software in an efficient, fast and reliable manner through automation and increasing release cycles

9 Continuous Improvement Ohno saw a problem not as a negative, but, in fact, as "a kaizen (continuous improvement) opportunity in disguise." Whenever one cropped up, he encouraged his staff to explore problems first-hand until the root causes were found. Don't look with your eyes, look with your feet. Don't think with your head, think with your hands Taiichi Ohno

10 Continuous Innovation BUILD Code Faster - Minimal Viable Product - Continuous Integration MEASURE Analyze Faster - Continuous Delivery - Real-time Monitoring LEARN Adjust/Pivot Faster - Split Testing - Five Whys Root Cause Analysis Velocity through the cycle with a clear goal of what you are validating is the key measure of success

11 Learn Build Measure The Minimal Viable Product The minimum viable product is that version of a product which allows a team to collect the maximum amount of validated learning with the least effort.

12 DevOps

13 DevOps is development and operations DevOps is treating your infrastructure as code DevOps is using DevOps is feature switches DevOps is deployments Kanban for Ops?

14 Traditional Development and Operations

15 DevOps: A three part conversation

16 DevOps Maturity Model RELEASE MGMT CHANGE MANAGEMENT BUSINESS STAKEHOLDERS ARCHITECTS DEV TEAMS TESTING SHARED SERVICES TEAM (TOOLS/ DEVOPS ETC) OPERATIONS Delivery Approach Release Management & Governance Build Management & Continuous Integration Deployment & Platform Provisioning Continuous Delivery: QA & Testing Operations & Monitoring Platform

17 -1 AD-HOC 0 REPEATABLE 1 CONSISTENT 2 OPTIMISED 3 LEADING DELIVERY APPROACH RELEASE MANAGEMENT & GOVERNANCE BUILD MANAGEMENT & CONTINUOUS INTEGRATION DEPLOYMENT & PLATFORM PROVISIONING CONTINUOUS DELIVERY QA & TESTING OPERATIONS & MONITORING PLATFORM Release scope poorly defined; subject to catastrophic and ad hoc change requests No defined or consistent applied delivery approach No consistent use of version control builds cannot be traced back to source code Mostly manual deployments Releases duration exceeds business need; releases face disruptive change Project based initiatives; no long term structure or responsibility Source code consistently managed in VCS; releases traceable to source Some CIs automated, environment tailoring required, no enterprise tools Fully manual test scripts Testers run a harness / suite No monitoring tools Servers created on adhoc basis; no defined standards or platform Tools in place, but not configured beyond basic OS checks Servers created by hand, but to defined standard. Release cadences well defined but exceeds business need; Requirements are stable; Industrialised project delivery; long term platform ownership Developers integrate changes by checking into trunk on regular basis (daily) Fully automated Singletouch deployments into environments. Test harness / suite run automatically for some envs Configured by a tool and role specific checks added Servers provisioned on demand (e.g. Via a portal) Release on demand, multi-speed releases; time-box meets to business need (e.g.: monthly) Platform based capacity delivery model ownership of roadmap and CSI Build is typically green if build breaks developers do not make other changes until resolved Functioning environments can be build from nothing programmatically. Automated test suites enforce a quality gate Environment and application health monitored and proactively managed Servers created programmatically; all maintenance automated Small changes pushed through the pipeline ; Continuous deployment enables innovation Continuous Delivery / Deployment supporting agile business change Build is typically green if build breaks the CI tooling automatically reverses the failed change Zero-touch zerodowntime deployments OR Platform (PaaS) used Tests run as functional monitoring Service level monitoring (perf, usage) integrated with infrastructure Services distributed automatically with autocorrective mechanisms in place

18 Microservices

19 Layered Architecture Rich and/or Web/Mobile clients Web services used to define a set of API s that front bounded contexts and App services Domain Model Layer defines Domain Entities Tight Coupling between all Bounded Contexts, Domain Entities and Data Access Cross Cutting Concerns integrated using Assemblies and/or NuGet packages One large data store

20 Distributed Microservice Architecture Any client supported through ReST APIs ReST API s exposed through an API gateway that provides API proxy, policy injection, subscription services, throttling, etc. Each microservice is independently versioned, packaged, deployed through automation Data and Application Services are provided through ReST API s and/or SDKs in a shared or dedicated model

21 Containers

22 What is a container? Everything required to make a piece of software run is packaged into isolated run-time environments called containers Unlike VMs, containers do not bundle a full operating system - only libraries and settings required to make the software work are needed This makes for efficient, lightweight, self-contained systems and guarantees that software will always run the same, regardless of where it s deployed

23 Why do I need containers? Containers are a solution to the problem of how to get software to run reliably when moved from one computing environment to another This could be from a developer's laptop to a test environment, from a staging environment into production and perhaps from a physical machine in a data center to a virtual machine in a private or public cloud. As more and more software moves to the cloud, is designed and developed using a microservice architecture and business continues to demand fast time to market, high velocity release cycles and continuous delivery of updates, automating the packaging and deployment of our software products is paramount.

24 What you will learn today 9:45-10:30 AM: Getting Started With Docker Containers: It's Easier Than You Think Mike Coleman BREAK 10:45-11:30 AM: Managing Containers 11:30 AM -12:00 PM: Container Security Chenxi Wang LUNCH 1:00-1:45 PM: Working With Chef Containers JJ Asghar 1:45-2:30 PM: Working With IBM Containers -- Lin Sun BREAK 3:00-4:00 PM: Working With Microsoft Containers Kevin Remde 4:00-5:00 PM: Working With AWS Containers Brian Lewis

25 Bob Familiar Director, National Practice BlueMetal, An Insight Company THANK YOU!!