3 key steps when creating a DevOps implementation plan

1. Analyze cloud, data center and application requirements

Any DevOps implementation plan must reflect the constraints associated with broad business directions in IT. In particular, it's critical to understand two points:

• First, how is cloud use developing for your company? Are you aggressively deploying application components in the cloud or contemplating only specialized cloud use?
• Second, what direction is your company taking in data center virtualization? Some companies plan extensive use of containers, others are happy with VMs or even bare metal, and some anticipate having a mix of all three.

DevOps, in its broadest form, is most applicable to data center deployments and hybrid cloud. If a company has little interest in changing hosting and deployment in the data center, then it's likely that cloud provider tools, such as managed hosting services, will dominate the organization's DevOps implementation. On the other hand, hybrid cloud puts a significant focus on DevOps planning and tends to preference containers and orchestration via Kubernetes over traditional DevOps tools.

Another consideration in this first step is application dynamism. Applications that need to be tuned rapidly and frequently to address changes in business conditions usually require a CI/CD framework. In such cases, the organization's DevOps strategy has to be adaptive and designed to avoid errors, given that the time to address them is limited.

To understand your organization's requirements, review the options for CI/CD pipeline practices and tools. If they seem like overkill for your organization's development pace, then you're looking at a simpler DevOps implementation plan.

2. Examine infrastructure and resource needs

The second key step in creating a DevOps implementation plan is to match applications to deployment resources efficiently. There are two basic approaches:

• The first option is a unified, upward-facing model: using infrastructure as code (IaC) tools such as Terraform to provision infrastructure to support applications.
• The second is a downward-facing configuration management approach: using traditional DevOps tools such as Ansible, Chef and Puppet to configure applications to run on infrastructure.

Upward-facing DevOps planning is best where there's already extensive infrastructure variability -- perhaps because of data center vendor changes, mergers and acquisitions, or special application requirements resulting in a more diverse server deployment model.

If there's little variability in data center hosting platforms, it's usually easier to make configuration management the centerpiece of your plan. For hybrid cloud users, upward-facing IaC tools can be very helpful in normalizing deployments across multiple clouds and the data center. Review the capabilities of all the major public cloud providers before making a decision.

The most flexible approach is to adopt elements of both strategies. Provision servers and software in a standardized way using IaC, then apply configuration management to match the applications to that model. Pick an approach that balances the complexity of your DevOps implementation plan against the benefits it can deliver in operational efficiency.

Finally, review the differences between containers and Kubernetes versus Ansible, Chef or Puppet. If you plan to use containers for hosting, particularly in a hybrid cloud environment, Kubernetes orchestration is often the best option.

DevOps platforms vs. best-fit software

Another critical question is whether to adopt a best-fit approach -- using separate, specialized software for specific tasks -- or choose a full-stack provider of DevOps tools.

Generally speaking, only organizations with significant in-house DevOps skills should consider the former approach. Integrating multiple tools from multiple sources into a cohesive plan without missing important issues and limitations is highly challenging.

Even businesses with in-house DevOps expertise might find that a full-stack approach better suits their needs. Full-stack providers rarely choose individual components that lag behind the market in capabilities, and the collection they select has the advantage of a large user base to test out tool quality and ease of integration.

For those who do choose the best-fit option, consider fleshing out your basic DevOps plan by researching the capabilities of full-stack providers. Compare several full-stack options against the basic strategy you defined in the first step to determine whether any existing platforms are an ideal fit.

If none will do, zero in on the specific tool that's responsible for the fit problem. Consider switching that tool out for another option rather than undertaking a project to individually select every component you might want to use throughout the full tech stack.

3. Decide how to document and communicate your DevOps implementation plan

The final step in a DevOps implementation plan is deciding how to document and communicate it. This task is much more complex than it might seem.

Any DevOps plan has multiple stakeholders, each of whom must understand and support the plan and the specific role they've been assigned. For most organizations, the best strategy includes a high-level master plan designed to link all the pieces, combined with more specific role-based plans that lay out the tasks each stakeholder or area is expected to perform.