sommai - Fotolia
With cloud, DevOps becomes a populist movement. The tools have caught up with the mission of DevOps on cloud, and it's time to adopt them.
Complexity created during application deployment translates into increased costs and disruptive errors in production operations. The primary goal of the modern DevOps model has always been to automate deployment and operations lifecycle management for applications, thereby shrinking complexity and its ill effects.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
Unfortunately, culture clashes, a scarcity of DevOps-trained personnel and perceptions of limited benefits have hampered progress in the movement. Cloud computing is changing that.
DevOps tools unite very different constituencies, a change which creates technical divergence and organizational tension. Many development personnel think DevOps hinders control of applications; many operations staffers think DevOps gives developers too much influence over live production IT.
Tooling for the cloud you're on
In large organizations, pressure for continuous application delivery and faster IT responses breaks the tension inherent in DevOps. Accommodations are introduced in both imperative and declarative DevOps models to make them more appealing, and larger companies have, for the most part, accepted DevOps. For many small and medium-sized businesses (SMBs), though, the learning curve still seems too steep, particularly given that most SMBs use packaged software rather than developing software in-house.
The cloud creates another dimension of complexity. Even with fixed, packaged software, cloud-based deployment demands flexibility. IT teams need to assign software components to hosting resources as-needed -- with the proper network connections to connect back-end and front-end components.
Operations teams have a strong reason to want DevOps on cloud deployments, but choosing the right approach gets complicated.
Many cloud users expect to hybridize their applications between public cloud services and owned servers. Even more cloud adherents expect to use only public cloud services and desktop systems.
If there are no hybrid cloud needs, then the first choice to implement DevOps in cloud deployments should be a native tool or tools from the cloud provider in use. If no such tool is available, ask the cloud provider to offer some case studies on using DevOps with its cloud service.
For multicloud and hybrid cloud apps, don't decide on a utility until you're sure you understand how each DevOps tool candidate supports all deployment options for the application.
If the enterprise develops application is in-house, ask the development organization to review or suggest DevOps tool options. For self-developed software, the biggest issue is customizing a DevOps approach for each application. Developers must be confident this is possible without compromising efficiency and application stability. Operations should then sign off on the development choices and select a tool.
If you're not planning to develop applications in-house or you have development recommendations on DevOps, turn to in-house operations team to assess the DevOps choices that cloud providers support. If there is already experience in-house with cloud deployment, review the methodology used against the literature available on prospective DevOps tools to ensure that everything done currently can be accommodated -- or improved -- with DevOps on cloud architectures.
Dare to declare
There are two models of DevOps. The prescriptive or imperative approach describes the steps to take to deploy and manage applications and components. Pioneered by configuration management tool Chef, developers favor this approach. The other model, popularized by Chef's competitor Puppet, is called declarative. Instead of describing how to deploy something, the declarative model describes what a successful deployment would look like: an end-state model. IT operations tend to favor this model. Neither model, however, is exclusive to developers or IT operations.
Bridge, don't blend, dev and ops
DevOps inevitably will create conflicts within an organization, which will become most apparent when you try to harmonize the development and operations perspectives on the best tool for a task.
To limit debates, assign each camp its own responsibilities. Development groups are in charge of creating the code that the team deploys; operations teams are responsible for its deployment. Don't let either step into the other's area except to define specific requirements and constraints.
Requirements could include the need to support multiple clouds or to change cloud providers at will. Operations sets these requirements; meeting them requires finding which specific DevOps tools support your enterprise's public cloud initiatives or projects. If, in reviewing those requirements, the operations team learns that some accommodations are required to use DevOps on cloud provider X, communicate those to developers.
The emerging area of cloud-specific applications is an example of where development teams must provide requirements to operations. Cloud-specific applications will constrain the cloud provider choices available to the IT team: The cloud provider must work with a specific set of tools to deploy, run and support this application built solely on the chosen cloud provider's platform. These applications also require specific integration with cloud-hosted features, and this all needs to be communicated to operations staff to help those workers plan deployments and pick a DevOps and cloud path.
Get hybrid cloud implementation right the first time
Are a cloud's features enough to offset lock-in?
Advice for building portable clouds