Moving to an integrated and automated DevOps deployment model can take a long time. It will depend on team maturity, tooling knowledge and platform skills of course.
1. Analyze cloud, data centre 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 centre 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 centre deployments and hybrid cloud. If a company has little interest in changing hosting and deployment in the data centre, then it’s likely that cloud provider tools, such a 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 centre vendor changes, mergers and acquisitions, or special application requirements resulting in a more diverse server deployment model.
If there’s little variability in data centre hosting platforms, it’s usually easier to make configuration management the centrepiece of your plan. For hybrid cloud users, upward-facing IaC tools can be very helpful in normalizing deployments across multiple clouds and the data centre. 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.