A “taxonomy” for Devops tools

During a recent discussion with a group of experienced Devops practitioners, we came up with the following “taxonomy” for the service delivery part of the Devops tooling landscape:

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.

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

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

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

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
• Providing out-of-the-box logic for application-tier tasks – Script It Yourself
• Providing a domain model that aligns with application delivery concepts

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.
• Providing 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