Understanding the DevOps Tooling Landscape

1,573 views

Published on

Slides from the April 10th, 2014 XebiaLabs webinar "Understanding the DevOps Tooling Landscape"

Published in: Technology

Understanding the DevOps Tooling Landscape

  1. 1. Understanding the DevOpsTooling Landscape Andrew Phillips, VP Products | 10 April 2014
  2. 2. 2 Copyright 2014. About Me ▪ VP Products for XebiaLabs ▪ Lots of enterprise software development on high-performance systems ▪ Been on both sides of the “Dev…Ops” fence ▪ Active open source contributor and committer: jclouds, Akka, Gradle and others ▪ Cloud, PaaS & Scala fan ▪ Regular meetup, conference etc. presenter
  3. 3. 3 Copyright 2014. About XebiaLabs ▪ Leading provider of delivery automation software focused on helping companies deliver higher quality software faster. ▪ Reduce development applications costs ▪ Accelerate application time to market ▪ Bridge the gap between Development and Operations Global Customers, Global Success and more…
  4. 4. 4 Copyright 2014. Housekeeping ▪ This webinar is being recorded ▪ Links to the slides and the recording will be made available after the presentation ▪ You can post questions via the GoToWebinar Control Panel
  5. 5. 5 Copyright 2014. Agenda • Lightning DevOps Recap • What is a “DevOps Tool”? • 5 Common Tool Categories • Which Tool(s) Are Right for Me? • Q & A
  6. 6. 6 Copyright 2014. Lightning DevOps Recap ▪ “Extending Agile Principles to Operations” ▪ “Breaking down the wall between Dev & Ops” ▪ Integrated teams, shared goals and improved understanding across the build & run cycle
  7. 7. 7 Copyright 2014. Lightning DevOps Recap ▪ “Extending Agile Principles to Operations” ▪ “Breaking down the wall between Dev & Ops” ▪ Integrated teams, shared goals and improved understanding across the build & run cycle ▪ Not: Creating a “DevOps Center of Competence” ▪ Not: Running a particular set of Flavour of the Month tools
  8. 8. 8 Copyright 2014. What is a “DevOpsTool” ▪ Didn’t you just say “it’s not about running any particular set of tools”? ▪ Yes! Tooling is not the goal of DevOps…but certainly a powerful means!
  9. 9. 9 Copyright 2014. What is a “DevOpsTool” ▪ Didn’t you just say “it’s not about running any particular set of tools”? ▪ Yes! Tooling is not the goal of DevOps…but certainly a powerful means! ▪ Many, many different types of tools and services mentioned
  10. 10. 10 Copyright 2014. What is a “DevOpsTool” ▪ Didn’t you just say “it’s not about running any particular set of tools”? ▪ Yes! Tooling is not the goal of DevOps…but certainly a powerful means! ▪ Many, many different types of tools and services mentioned − Communication & Collaboration
  11. 11. 11 Copyright 2014. What is a “DevOpsTool” ▪ Didn’t you just say “it’s not about running any particular set of tools”? ▪ Yes! Tooling is not the goal of DevOps…but certainly a powerful means! ▪ Many, many different types of tools and services mentioned − Communication & Collaboration − Monitoring & Alerting
  12. 12. 12 Copyright 2014. What is a “DevOpsTool” ▪ Didn’t you just say “it’s not about running any particular set of tools”? ▪ Yes! Tooling is not the goal of DevOps…but certainly a powerful means! ▪ Many, many different types of tools and services mentioned − Communication & Collaboration − Monitoring & Alerting − System Testing & Disruption
  13. 13. 13 Copyright 2014. What is a “DevOpsTool” ▪ Didn’t you just say “it’s not about running any particular set of tools”? ▪ Yes! Tooling is not the goal of DevOps…but certainly a powerful means! ▪ Many, many different types of tools and services mentioned − Communication & Collaboration − Monitoring & Alerting − System Testing & Disruption − Logging & Log Analysis
  14. 14. 14 Copyright 2014. What is a “DevOpsTool” ▪ Didn’t you just say “it’s not about running any particular set of tools”? ▪ Yes! Tooling is not the goal of DevOps…but certainly a powerful means! ▪ Many, many different types of tools and services mentioned − Communication & Collaboration − Monitoring & Alerting − System Testing & Disruption − Logging & Log Analysis − Task Execution
  15. 15. 15 Copyright 2014. What is a “DevOpsTool” ▪ Didn’t you just say “it’s not about running any particular set of tools”? ▪ Yes! Tooling is not the goal of DevOps…but certainly a powerful means! ▪ Many, many different types of tools and services mentioned − Communication & Collaboration − Monitoring & Alerting − System Testing & Disruption − Logging & Log Analysis − Task Execution − Cloud & Container Management
  16. 16. 16 Copyright 2014. What is a “DevOpsTool” ▪ Didn’t you just say “it’s not about running any particular set of tools”? ▪ Yes! Tooling is not the goal of DevOps…but certainly a powerful means! ▪ Many, many different types of tools and services mentioned − Communication & Collaboration − Monitoring & Alerting − System Testing & Disruption − Logging & Log Analysis − Task Execution − Cloud & Container Management − System Provisioning & Configuration
  17. 17. 17 Copyright 2014. What is a “DevOpsTool” ▪ Didn’t you just say “it’s not about running any particular set of tools”? ▪ Yes! Tooling is not the goal of DevOps…but certainly a powerful means! ▪ Many, many different types of tools and services mentioned − Communication & Collaboration − Monitoring & Alerting − System Testing & Disruption − Logging & Log Analysis − Task Execution − Cloud & Container Management − System Provisioning & Configuration − Application Integration & Deployment
  18. 18. 18 Copyright 2014. What is a “DevOpsTool” ▪ Didn’t you just say “it’s not about running any particular set of tools”? ▪ Yes! Tooling is not the goal of DevOps…but certainly a powerful means! ▪ Many, many different types of tools and services mentioned − Communication & Collaboration − Monitoring & Alerting − System Testing & Disruption − Logging & Log Analysis − Task Execution − Cloud & Container Management − System Provisioning & Configuration − Application Integration & Deployment − Pipeline Orchestration
  19. 19. 19 Copyright 2014. What is a “DevOpsTool” ▪ Didn’t you just say “it’s not about running any particular set of tools”? ▪ Yes! Tooling is not the goal of DevOps…but certainly a powerful means! ▪ Many, many different types of tools and services mentioned − Communication & Collaboration − Monitoring & Alerting − System Testing & Disruption − Logging & Log Analysis − Task Execution − Cloud & Container Management − System Provisioning & Configuration − Application Integration & Deployment − Pipeline Orchestration − …
  20. 20. 20 Copyright 2014. What is a “DevOpsTool” ▪ Didn’t you just say “it’s not about running any particular set of tools”? ▪ Yes! Tooling is not the goal of DevOps…but certainly a powerful means! ▪ Many, many different types of tools and services mentioned − Communication & Collaboration − Monitoring & Alerting − System Testing & Disruption − Logging & Log Analysis − Task Execution − Cloud & Container Management − System Provisioning & Configuration − Application Integration & Deployment − Pipeline Orchestration − … ▪ The vendor bandwagon isn’t making things any easier here…
  21. 21. 21 Copyright 2014. What is a “DevOpsTool” ▪ Confusing?!? You bet! − Well, certainly for me it’s confusing…and I’ve been doing this for years now! ▪ Will focus here on the tooling related to application & service delivery − Our specialist area of expertise − Accelerating application time-to-market is regarded as the key business driver for DevOps (check our “State of Software Delivery 2014” survey!)
  22. 22. 22 Copyright 2014. 5 CommonTool Categories ▪ Communication & Collaboration ▪ Monitoring & Alerting ▪ System Testing & Disruption ▪ Logging & Log Analysis ▪ Task Execution ▪ Cloud & Container Management ▪ System Provisioning & Configuration ▪ Application Integration & Deployment ▪ Pipeline Orchestration ▪ …
  23. 23. 23 Copyright 2014. 5 CommonTool Categories ▪ Communication & Collaboration ▪ Monitoring & Alerting ▪ System Testing & Disruption ▪ Logging & Log Analysis ▪ Task Execution ▪ Cloud & Container Management ▪ System Provisioning & Configuration ▪ Application Integration & Deployment ▪ Pipeline Orchestration
  24. 24. 24 Copyright 2014. 5 CommonTool Categories ▪ Communication & Collaboration ▪ Monitoring & Alerting ▪ System Testing & Disruption ▪ Logging & Log Analysis ▪ Task Execution ▪ Cloud & Container Management ▪ System Provisioning & Configuration ▪ Application Integration & Deployment − we’ll actually discuss these two separately ▪ Pipeline Orchestration
  25. 25. 25 Copyright 2014. 5 CommonTool Categories Bare Metal Application/ Service Build RunGo-live
  26. 26. 26 Copyright 2014. 5 CommonTool Categories Bare Metal Application/ Service Build RunGo-live Task Execution
  27. 27. 27 Copyright 2014. 5 CommonTool Categories Bare Metal Application/ Service Build RunGo-live Cloud & Container Management Task Execution
  28. 28. 28 Copyright 2014. 5 CommonTool Categories Bare Metal Application/ Service Build RunGo-live System Provisioning & Configuration Cloud & Container Management Task Execution
  29. 29. 29 Copyright 2014. 5 CommonTool Categories Bare Metal Application/ Service Build RunGo-live System Provisioning & Configuration Cloud & Container Management Application Integration & Deployment Task Execution
  30. 30. 30 Copyright 2014. 5 CommonTool Categories Bare Metal Application/ Service Build RunGo-live System Provisioning & Configuration Application Integration & Deployment Pipeline Orchestration Cloud & Container Management Task Execution
  31. 31. 31 Copyright 2014. Category:Task Execution ▪ What do these tools do? − Allow you to run arbitrary commands or scripts on one or multiple target systems − Depending on the tool, not just ad-hoc, but also or on a regular basis ▪ What are they good at? − One-off or regular maintenance, “cleanup” or management activity (e.g. clearing caches, killing stale processes) − Think “cron++” ▪ What are they not so good at? − Coordinating processes across multiple machines − Targeting hybrid environments (e.g. support for Windows varies widely between tools) − Providing out-of-the-box logic – Script It Yourself ▪ Remarks − Most of the other tool categories include a “task execution framework”, since they also need to run commands on many servers. Just a question of how easy it is to leverage that framework.
  32. 32. 32 Copyright 2014. Category: Cloud & Container Management ▪ What do these tools do? − Cloud Management: Allow you to manage virtual machines, networks, storage, routing, load balancing etc…basically, manage virtual datacenters − Container Management: Allow you to define and manage “runtime containers” or “runtime environments”, which may be virtual machines, networks etc., or a tool-specific container type ▪ What are they good at? − Providing on-demand environments and resources for your delivery pipelines and runtime environment − Depending on the tool, providing a definition model for environments or containers that can be instantiated on a developer’s laptop as well as in the production environment ▪ What are they not so good at? − Portable definition models are limited and too restrictive, flexible ones are not portable enough − Often require an application architecture geared to the container model – not easy to adopt for existing applications − Limited or no support for “Role-based Definition Control”, e.g. ensuring certain parts of the container or environment definition are fixed
  33. 33. 33 Copyright 2014. Category: Cloud & Container Management ▪ What are they not so good at? (ctd.) − Management of persistent data and linking to externally consumed services hardly ever covered − Container and environment definition still generally a manual process – Script It Yourself ▪ Remarks − Providing lightweight containers (typically, based on LXC) as a “development deliverable” is currently a fashionable idea − Whether this can work for you depends largely on whether you can (re-)architect your applications to work in this model − Load balancing, scaling, “A/B pool management” etc. are still things you need to solve (effectively, this is the difference between a PaaS and a “container” or “environment” pool)
  34. 34. 34 Copyright 2014. Category: System Provisioning & Configuration ▪ What do these tools do? − Allow you to define the desired state of a system, often in a declarative manner − Ensure a target system is brought to the desired state, and stays there − Via their underlying task execution frameworks, allow for the execution of ad-hoc commands on a server ▪ What are they good at? − Ensuring many machines are in a known state and kept in that state − Providing a lot of out-of-the-box content for system configuration and service installation tasks − Depending on the tool, reporting on differences between the intended and actual states of a machine ▪ What are they not so good at? − Coordinating an action sequence across multiple machines − Providing out-of-the-box logic for application-tier tasks – Script It Yourself − Providing a domain model that aligns with application delivery concepts
  35. 35. 35 Copyright 2014. Category: Application Integration ▪ What do these tools do? − Take source code and other development artifacts and turn them into a versioned deliverable that is a candidate for release − Run extensive code-level and integration tests, code analysis tools etc. for validation − Depending on the tool, performing this validation on candidate code changes before integration into the main branch ▪ What are they good at? − Providing a lot of out-of-the-box integrations with build and code-level testing and –analysis tools − Chaining and distributing build and testing tasks for efficiency − Maintaining the “releasability” of your main branch ▪ What are they not so good at? − Coordinating an action sequence across multiple machines − Providing out-of-the-box logic for tasks beyond the construction and archiving of the deliverable – Script It Yourself − Depending on the tool, providing a domain model that represents the delivery process
  36. 36. 36 Copyright 2014. Category: Application Deployment ▪ What do these tools do? − Take a new version of a deliverable (typically, an application) and get it running in a target environment (i.e. a set of target systems) − Depending on the tool, optionally create target environments for the new version on demand ▪ Why are they good at? − Coordinating actions across multiple target systems − Ensuring deliverables are environment-independent and handling any required environment-specific configuration − Providing a lot of out-of-the-box content for application-tier tasks ▪ What are they not so good at? − Providing out-of-the-box logic for system configuration & service installation tasks − Supporting build, validation and packaging of the deliverable − Providing a domain model to support the entire delivery process, esp. including team-based tasks
  37. 37. 37 Copyright 2014. Category: Pipeline Orchestration ▪ What do these tools do? − Allow you to define the sequence of tasks that make up your delivery/release process, i.e. your “delivery pipeline” − Depending on the tool, support processes that combine manual and automated tasks − Depending on the tool, show features are currently at which stage of the process ▪ Why are they good at? − Providing visibility into the end-to-end delivery process − Depending on the tool, allow drill-down into not just which applications are where, but which features those applications implement, which code versions were used to build the applications etc. − Provide an end-to-end audit trail for each application running in production ▪ What are they not so good at? − Providing out-of-the-box logic for tasks carried out in the pipeline – Script It Yourself or Invoke Other Tools − Depending on the tool, supporting team-based tasks and variable processes − Depending on the tool, supporting process improvement
  38. 38. 38 Copyright 2014. 5 CommonTool Categories Bare Metal Application/ Service Build RunGo-live System Provisioning & Configuration Application Integration & Deployment Pipeline Orchestration Cloud & Container Management Task Execution
  39. 39. 39 Copyright 2014. WhichTool(s) Are Right For Me? 1. Focus on Goals, not Tools − What are we actually trying to get out of DevOps? 2. Identify biggest pain points 3. If you’re looking at the delivery process, decide which delivery model is most suited to your team/organization − From “Dev team supplies the full container/environment” to “Dev team provides minimal code package to run on an Ops-provided platform/PaaS” to something in between 4. There is no One Tool To Rule Them All − Even though most of the tools can be made to do most of what the other tools can do
  40. 40. 40 Copyright 2014. Next Steps ▪ Get started with XL Platform today! go.xebialabs.com/XL-Platform-Trial.html ▪ Learn more about XL Platform: www.xebialabs.com/products/ ▪ Stay informed: blog.xebialabs.com @XebiaLabs vimeo.com/xebialabs
  41. 41. Thank You!

×