Is rapid application development important to your business goals? Are you trying to develop new products, applications, or customer experiences that will drive revenue, deliver efficiencies or improve customer satisfaction?

Are there competitive threats and is the time to release new features to the market important? Is the overall quality of your development including functionality, data integrity, performance, and security critical to validate?

It’s a tough job being a developer. There’s pressure to fix customer issues with existing applications, build new innovative experiences, ensure that code meets architecture and quality standards, respond to QA when defects are identified, answer questions from management about how applications function, train new developers on the team, and perform code reviews.

Agile Development Takes On The Cloud

But what’s the hardest part of a developer’s job? Before the cloud, it was often the infrastructure.  

Developers were asked to have shippable code ready every 2-week sprint, yet infrastructure moved at a quarterly or yearly pace. It forced developers and architects to specify infrastructure needs months before they were ready to build and deploy applications and to go through often-difficult change requests for infrastructure or configuration changes. For many developers working with infrastructure engineers felt like they were hitting a brick wall.

Things changed when the cloud emerged as an enterprise ready infrastructure option. You ordered infrastructure through web interfaces. You dove into configuring servers, storage, and networks yourself and deployed applications to them. No more waiting for someone in operations to make a requested change. You did it yourself!

And then it got easier as more cloud automation tools came to market. Continuous integration tools that allowed you to fully automate builds and continuous delivery tools to push code to development, staging, and production environments. Infrastructure as Code (IaC) tools allowed you to define and automate building and configuring the infrastructure. Other tools enabled you to scale the environment up and down based on computing demands.

Perhaps you dove into using some of these tools because they are in your wheelhouse of developing scripts and configuration files. Maybe you have part of the automation completed and are looking for management to give you the authorization to automate more aspects of the infrastructure.

Sounds great unless you take an honest retrospective and realize that as a developer, you’re moving away from your primary mission. Your business needs you to improve customer experiences, add functionality, and deliver new products. How much of your time are you or will you be spending on cloud automation?

What is a DevOps Cloud Strategy?

Strong software developers are often one of the earlier groups to recognize the value and importance in cloud automation. They are often under time pressure with too many priorities on their plate, so finding ways to automate steps is in their nature. That is changing today as more technology leaders are becoming aware of cloud automation tools and their business benefits. Once a cloud vendor is selected, leaders and their teams often come together to determine how best to operate these environments.

This is the beginnings of a DevOps cloud strategy. This strategy often includes the overall governance, architecture, security, practices, operational procedures, and responsibilities on managing the cloud environment. Operationally, it often starts with specifying how accounts are configured, environments structured, security enabled, redundancy configured, and access enabled. In large enterprises, it also factors in how costs will be monitored and allocated to consumers. In other words, a DevOps cloud strategy often starts with governance, architecture, and practices similar to how traditional infrastructure is configured.

You can’t ignore execution when defining any strategy and that’s where things become interesting for a DevOps cloud strategy. Most of the execution can be automated and so leaders and teams immediately jump into the debate over what tools should be used, what methodologies to standardize on, what areas of automation to focus on, and most importantly, whose responsibility it is to implement the automation.

Developing this strategy can often lead to debate within the IT organization especially when developers and engineers are asked to get involved in formulating it. They are coming at it from their traditional responsibilities and principles at a time when IT is being asked to do more with less. In a recent survey, 63% of technology respondents saw their workloads increasing, but only 44% expect an increasing in developers and only 33% expect an increase in operational teams. In fact, the trend is toward leaner, faster software development teams especially as organizations look to microservices architectures to accelerate their application portfolios.

Aligning DevOps With Development and Operations

If this is happening in your organization, it’s an opportunity for leadership to take a step back and realign everyone’s mission and principles. I like starting at the beginning:

“If DevOps is about anything, it’s about communications and sharing, collaboration and accountability to yourself and your team.” – Andi Mann from DevOps: It’s an Ongoing Culture, Not a Project

This is a great starting point to breakdown the traditional silos of development and operational responsibilities and begin thinking through how best to collaborate in a smarter faster world. This doesn’t necessarily mean a departmental reorganization, but should go into realigning disciplines, objectives and responsibilities.  Once operating principles are laid out, a strategic team – or a Cloud Center of Excellence (CoE) – should work collaboratively to propose an execution plan. The table below is a suggested starting point.

From DevOps Strategy to Execution

Teams that work on this collaboratively often reach a common conclusion, specifically, that the traditional charter for developers and operations hasn’t changed much, but the technologies have. Regardless of how the organization elects to assign responsibilities and priorities, there are new tools to learn that require a stronger collaboration between those that build applications and those that ensure they are performing.

For developers, I like to remind them of their primary mission of developing products, applications, and experiences. If they are focused on this mission, they should elect to partner and collaborate with others on the team and with service providers on executing the DevOps strategy.