Understanding the DevOps Tooling Landscape

Understanding the
DevOpsTooling Landscape
Andrew Phillips, VP Products | 10 April 2014

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 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 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 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 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 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 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 Copyright 2014.
▪ Many, many different types of tools and services mentioned

10 Copyright 2014.
− Communication & Collaboration

11 Copyright 2014.
− Monitoring & Alerting

12 Copyright 2014.
− System Testing & Disruption

13 Copyright 2014.
− Logging & Log Analysis

14 Copyright 2014.
− Task Execution

15 Copyright 2014.
− Task Execution
− Cloud & Container Management

16 Copyright 2014.
− Task Execution
− System Provisioning & Configuration

17 Copyright 2014.
− Task Execution
− Application Integration & Deployment

18 Copyright 2014.
− Task Execution
− Pipeline Orchestration

19 Copyright 2014.
− Task Execution
− …

20 Copyright 2014.
− Task Execution
− …
▪ The vendor bandwagon isn’t making things any easier here…

21 Copyright 2014.
▪ 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 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 Copyright 2014.
▪ Task Execution

24 Copyright 2014.
▪ Task Execution
− we’ll actually discuss these two separately

25 Copyright 2014.
Bare Metal
Application/
Service
Build RunGo-live

26 Copyright 2014.
Bare Metal
Application/
Service
Build RunGo-live
Task Execution

27 Copyright 2014.
Bare Metal
Application/
Service
Build RunGo-live
Cloud & Container Management
Task Execution

28 Copyright 2014.
Bare Metal
Application/
Service
Build RunGo-live
System Provisioning & Configuration
Task Execution

29 Copyright 2014.
Bare Metal
Application/
Service
Build RunGo-live
Application Integration & Deployment
Task Execution

30 Copyright 2014.
Bare Metal
Application/
Service
Build RunGo-live
Pipeline Orchestration
Task Execution

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 Copyright 2014.
Category: Cloud & Container Management
− 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
− 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
− 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 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 Copyright 2014.
Category: System Provisioning & Configuration
− 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
− 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
− 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 Copyright 2014.
Category: Application Integration
− 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
− 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
− 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 Copyright 2014.
Category: Application Deployment
− 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
− 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 Copyright 2014.
Category: Pipeline Orchestration
− 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
− 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 Copyright 2014.
Bare Metal
Application/
Service
Build RunGo-live
Pipeline Orchestration
Task Execution

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 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

Understanding the DevOps Tooling Landscape

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (10)

Similar to Understanding the DevOps Tooling Landscape

Similar to Understanding the DevOps Tooling Landscape (20)

More from XebiaLabs

More from XebiaLabs (20)

Recently uploaded

Recently uploaded (20)

Understanding the DevOps Tooling Landscape