What Is the Relationship Between the Cloud and DevOps?

It’s fair to say that the cloud and DevOps are commonplace concepts at this point. In the accelerated timeline of the software industry, both have been around for quite awhile. Maybe they’ve been floating around in the back of your head as intriguing ideas for some time—and if you’re a CIO or director in your organization, maybe you’re researching them right now to understand how your company might adopt one or both. You might wonder: How do they relate to each other? To answer that, let’s start with some general definitions.

First of all, the cloud is an abstraction layer on top of physical machines that gives you on-demand, self-service-based resource management. It doesn’t matter if the underlying physical devices are in your data center or somewhere on the internet. This only defines what type of cloud you have—public, private or hybrid.

DevOps, on the other hand, defines how you work. It’s a loosely held set of best practices for your software development processes and teams. Jez Humble, the co-author of several influential books on DevOps, describes it as “a cross-disciplinary community of practice dedicated to the study of building, evolving and operating rapidly changing resilient systems at scale.” DevOps can help your teams improve the entire software development lifecycle (SDLC) through working together to automate as much as possible and increase overall software quality. 

So, strictly speaking, the cloud has nothing to do with DevOps. They are two distinct concepts. One term defines infrastructure and the other describes culture. But in this post, you’ll learn how the cloud can actually make DevOps implementation easier and how DevOps can help increase cloud efficiency.

Remember that we defined the cloud as an abstraction layer—it consists of abstracted physical devices for resource management. To really understand what “abstracted physical devices” means, we need to see how it compares to a “non-cloud” infrastructure. A traditional on-premise data center has a dedicated operations team to manage all the servers. Whenever the application development team needs some infrastructure changes, they send a ticket to the operations team and wait for a reply. The operations team will have to find which server can be reused, locate it in the data center, reinstall the operating system on it and sometimes move it to a different rack. Sometimes, the application development team might have to wait a few weeks, or potentially even a few months, if new hardware has to be ordered, installed and configured.

The “abstracted physical devices” approach makes that process easier and faster. It means you no longer assign individual servers to individual tasks or teams. You install some sort of cloud software on top of them and treat them all as part of one cluster (or a few clusters). Such cloud software then exposes a command-line interface (CLI) or web portal for application development teams to manage the infrastructure themselves. Instead of a few days or weeks, they’ll only have to wait a few minutes.

And that’s pretty much what cloud is: on-demand, automated infrastructure management. And because the cloud works this way, it enables operations teams to easily give application development teams more control over the infrastructure. As an operations team, you can preconfigure the virtualization software to work in a way you want so that, when you give application development teams the ability to manage their infrastructure, you’ll know exactly what they can and can’t do. 

Now that we’ve discussed the concept of a cloud, let’s talk about its symbiotic relationship with DevOps practices. The traditional “non-cloud” approach is to have an operations team managing servers and application development teams that don’t have much (if any) control over the infrastructure. Application development teams have to contact an operations team every time they need some change in the infrastructure—limited, of course, to what each operations team is willing to provide. It’s typically a slow process, because fewer people may work on infrastructure than on applications. Also, infrastructure decisions may be based solely on one team’s vision, without considering the needs of other teams.

With DevOps, these routine (and frustrating) experiences can transform. Instead of having separate, siloed teams that each control a phase of the SDLC or a branch of IT, DevOps promotes close collaboration among all teams. This approach has many advantages. For one, infrastructure decisions can be made with application development teams’ input. Usually, this drastically improves developer experience and allows them to deliver business value faster. Application development teams can also better understand why certain processes and limitations exist within your infrastructure.

Giving application development teams more control over the infrastructure doesn’t mean that developers will have to learn all about infrastructure provisioning. Thanks to infrastructure abstraction, operations teams can prepare easy-to-use, template-based solutions for application development teams. This means operations will still control how provisioned resources look, while application development teams will get provisioning solutions that are easy to understand and don’t require raw infrastructure knowledge to use. For example, when in need of a new database, the application development team won’t need to bother with things like where to download the database software from, where to install it, how to configure it or how to make sure that it’s secure. Instead, they’ll be able to simply open a web portal and click the “create new database” button, which will trigger a database creation process predefined by an operations team.

“This sounds great,” you may be thinking, “but what does it all mean for the business?” Cloud-powered DevOps makes developers’ lives easier, but the benefits also extend much further. Today’s market demands faster and faster time to value. When operations and application development teams work together in the DevOps way, they can be much more efficient in delivering fixes and new features to customers.

So, what is the relationship between the cloud and DevOps? As we discussed earlier, cloud computing and DevOps solve two entirely different problems—but they do complement each other.

Without the cloud, giving application development teams more control over infrastructure would be really difficult. You would have to give them the ability to provision and manage the real servers, which means they would have to manage very low-level aspects of the infrastructure like networking, disk partitioning and so on. This would require application development teams to have deep knowledge in these areas, which just isn’t feasible at scale. It would also create a risk that two different application development teams would try to provision the same server or would break the whole storage array trying to partition the wrong disk. Since the cloud abstracts all these low-level aspects of the servers, it makes it much easier to adopt DevOps practices of collaboration across teams. 

Don’t get me wrong—you can still benefit from DevOps in an on-premise environment. Automated infrastructure provisioning is just one of the efficiencies that DevOps practices can introduce, if you choose to do so. DevOps is ultimately about people, and what’s most important is the collaboration among all IT teams. You can still have that cooperation in an on-premise environment, but without the cloud, every team will be limited in what they can achieve as a whole.

On the other hand, implementing the cloud without implementing DevOps also doesn’t make much sense. You’ll end up in a situation where the operations teams will have to do additional jobs for application development teams that they could easily do themselves. Having the ability to easily provision servers via a self-service web portal without giving application development teams access to that portal raises the question: What was the point of having that portal then? It’s called “self-service” for a reason. 

So, while both cloud and DevOps can be implemented separately, the benefits are greater when your organization chooses to adopt both together.

As mentioned in the previous section, you can implement DevOps whether you have adopted the cloud or not. There are, however, big differences in what DevOps can give you on-premise versus what it can give you in the cloud. The main business benefit of DevOps is speed: faster deployments, faster implementations of new features, faster bug fixing. So, while DevOps in a “non-cloud” environment can promote cooperation between operations and application development teams to find issues more efficiently, it won’t help you deploy or implement new features faster. If the server provisioning still takes days or weeks, you can’t do much to speed that up. Still, this doesn’t mean that practicing DevOps on-premise is pointless. Closer collaboration among teams is always a good idea.

You may be wondering whether the complexity of your infrastructure will affect DevOps adoption. Will it matter if your company is a start-up or an enterprise with well-established processes? Well, yes and no. No, because DevOps can be implemented in any environment, no matter how simple or complex. However, small start-ups and large enterprises will—of course—need different implementation approaches. In a small start-up with basic infrastructure, DevOps can be implemented in a matter of weeks. It may take an enterprise a few years to fully transition to DevOps, although the change is well worth it. An enterprise may manage this in steps. Small teams focused on innovation may adopt practices first, before other teams are introduced incrementally.

What else do you need to consider when adopting DevOps? 

Commitment is key. Implementing DevOps can sometimes meet with resistance. People don’t like change, and some operations teams are reluctant to give developers access to infrastructure. They know this would be chaotic in an on-premise environment, and they might not understand exactly how different the DevOps approach is. Therefore, implementing DevOps should include training to ensure all the parties involved understand the benefits to their own groups as well as the holistic impact of DevOps. 

Remember that DevOps is flexible. Its practices can accommodate your unique situations. DevOps is about processes, culture and mindset. It is not something that you simply install and configure. Therefore, it’s also very important that people who drive the whole DevOps movement really “get” DevOps and understand how to overcome obstacles regarding change management. 

Another thing to consider is how deep you want to go. You can adopt a few selective practices or you can completely transform software delivery at your organization. At any level, you can still realize benefits. Check out third-party solutions like the CloudBees Software Delivery Platform that can support your DevOps journey, helping you to release software faster and more predictably.

Of course, one of the main goals of DevOps—faster and automated deployments—raises some risks, too. You may have concerns that automated deployments could fail, leading to more outages. And, yes, automated deployments should include testing too, but even automated tests can sometimes miss some bugs. Some companies decide to entirely skip automated deployments to avoid that risk. But you can automate while de-risking—for example, CloudBees Feature Management, a capability of the CloudBees Software Delivery Platform, lets you change what your software can do without changing or redeploying your code. Your teams can simply “turn on” and “turn off” different parts of the application, making it easier to revert to previous versions or even test new features by only “turning on” the code for specific groups of people. So as soon as you see some issues, you can disable that feature without need for a rollback. 

As you can see, cloud and DevOps amplify each other’s benefits. You can use them separately, but you’ll get the most benefits by implementing them together. And if you want to make that implementation easier, don’t forget to check out the CloudBees Software Delivery Platform.

It’s important to understand that, at the end of the day, DevOps is about every team in IT cooperating with each other. Don’t let your teams work in separation—silos are the easiest way to sabotage productivity. 

• Understand how one company used CloudBees to go from seven deployments a month to 1,000 deployments a month

• Read about best practices to drive successful DevOps adoption

This post was written by Dawid Ziolkowski. Dawid has 10 years of experience starting as a network/systems engineer before moving to DevOps and more recently becoming a cloud native engineer. Nowadays he’s helping companies move to cloud and/or redesign their infrastructure for a more cloud native approach.