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 ExecutionWhat 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
- One-off or regular maintenance, "cleanup" or management activity (e.g. clearing caches, killing stale processes)
- Think "cron++"
- 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
- 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 ManagementWhat 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
- 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
- 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
- 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 & ConfigurationWhat 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
- 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
Application IntegrationWhat 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
- 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
Application DeploymentWhat 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
- 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
- Providing out-of-the-box logic for application-tier tasks – Script It Yourself
- Providing a domain model that aligns with application delivery concepts
Pipeline OrchestrationWhat 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
- 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
- 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
We then tried to place these tools in relation to
- Which part(s) of the system stack they address
- Where in the end-to-end/"code-to-cache" spectrum they fall
and came up with the following diagram:
What do you think? Which of these categories of tools do you use? Do you have your own categorization?
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)