By Dalibor Siroky
DevOps was created to reduce many of these same conflicts and while DevOps has had several high-profile successes it still presents a challenge for larger organizations. Large enterprises managing mission-critical systems still have separate silos for development and operations. In this post I discuss how DevOps fits into the enterprise and what release managers can do to adapt and extend DevOps to meet the challenges present in larger businesses.
First, I'm going to define DevOps. Then I'm going to discuss the impedance mismatch between DevOps and a larger enterprise. In conclusion I'm going to make some suggestions for how people practicing DevOps can adapt DevOps practices to these larger enterprises.
What Is DevOps?
To understand what DevOps is you have to understand the fundamental disconnect between development and operations. Development teams create and change software while operations teams are tasked with ensuring the stability of systems they maintain. The accepted metaphor was put forward by Andrew Shafer in 2009 and it is that there is a "Wall of Confusion" between Development and Operations.
Businesses have two competing motivations: delivery and stability. The business needs to be able to deliver software changes frequently while also maintaining 100% availability for the end user. Traditional approaches to IT emphasize strict separation of concerns between Dev and Ops, forcing the business to choose either delivery or stability. You can either deliver software changes constantly and sacrifice stability or you can emphasize stability and make it next to impossible for software to change.
Most define DevOps as a set of tools and technologies, but DevOps (like it's cousin Agile) is more a set of common approaches and a set of shared values:
DevOps (like Agile) defies easy explanation, but those who practice it can recognize it. While I don't think it makes sense to define DevOps as a set of tools, there are several that are associated with the movement: Chef and Puppet. Similar to Agile, it's also easy for organizations to adopt components of the approach a la carte.
Challenges in an Enterprise
Let's define what we mean by enterprise. We're not using this as a catch-all phrase to talk about all businesses; when we say "enterprise" we mean it. These are companies like international banks moving billions a day or massive retailers tracking inventory in the hundreds of billions.
In these environments a good metaphor to describe the difference between Development and Operations is a satellite. Development groups are busy manufacturing satellites in a hangar while operations is responsible for maintaining these systems in orbit.
In these enterprises the following concerns are a given:
Scaling Devops to the Enterprise: Enterprise DevOps
DevOps as commonly practiced has some blind spots in the previous list.
From the perspective of IT a DevOps project gives off all the signs of increased risk and maintenance. In the next section, we define what it takes to bridge the gap between DevOps and IT.
What Is Enterprise DevOps?
Yes, DevOps is about automation and technology, but it's mostly about communication. It's about making communication between development and operations non-adversarial and less formal. Enterprise DevOps is a bit different. You can think of Enterprise DevOps as "DevOps when your IT department is still focused on ITSM and ITIL." Enterprise DevOps shifts some of the infrastructure automation requirements out of the Dev side of DevOps and into the Ops side of DevOps.
Center of Gravity Shifts from Development Release Management
With Enterprise DevOps, your development teams are still delivering early and often, they may still be using Puppet and Chef to automate deployments, but they are taking an extra effort to address the information requirements of the IT group and they will continue to be entirely disconnected from the production deployment process. Where the center of gravity in a smaller DevOps approach is squarely on the side of developers, in Enterprise DevOps the responsibility for coordination is with the release managers.
In an Enterprise DevOps approach your application teams should be standardizing on a common set of automation tools and approaches. It is impossible to scale DevOps to the level of a large enterprise if every team and application group feels enabled to craft a unique interpretation of DevOps. Within each group it should be difficult to tell the difference between DevOps and Enterprise DevOps. For a developer, the experience should be the same since code is being delivered to a shared reference system for testing on a continuous basis.
Enterprise DevOps Respects Change Management
Enterprise DevOps is a form of rapid software delivery that still needs to respect the formalities present in a large organization's IT department. If operations uses BMC Remedy or ServiceNow to model a release as a change request, your release process needs to comply with that policy. While many view DevOps as getting rid of unnecessary processes, Enterprise DevOps preserves that formal interface between development and operations and isolates both sides from heavy process-oriented interactions.
Enterprise DevOps Reduces Risk Associated with Environments
When you practice Enterprise DevOps you train your operations group to use DevOps tools to automate and stand up common environments for teams to use interchangeably. For example, if you have 40 groups in your company all developing applications on Apache Tomcat, an Enterprise DevOps approach to this would be to have the central IT group create a set of Puppet or Chef scripts to be used as a baseline for other groups.
In an Enterprise DevOps approach your operations teams supply a common set of VM images or environments that development groups can automate. Where, in a smaller DevOps approach, your development teams would be writing tools to automate deployment to production. In an Enterprise DevOps approach your applications teams will stop at testing and staging environments and operations will still be responsible for translating the automation work done in staging to a production environment.
Enterprise DevOps Enables Orchestration
When all teams have standards on the same flavor of DevOps and release managers understand that software deployment and releases are standardized they can more accurately predict timelines. In a large organization this is critical for on time delivery.
Plutora Enables Enterprise DevOps
When we created Plutora we did so with the idea that bridging the information gap between different groups involved in a release reduces the friction and risk associated with releases. If you've been involved in a big release you'll appreciate that releases are all about conflict - conflicting release timelines, conflict between development and operations, and conflicting tools used to model releases. If you can understand and anticipate these conflicts you can manage them and releases can be more predictable.
The DevOps approach is about breaking down the boundary between Development and Operations and aligning both groups to meet the same objectives. If the Operations group still has to perform some of the procedural tasks associated with a heavy process like ITSM, you can still have a development team that targets a DevOps style deployment that retrofits this new process for the interface that the IT department expects.
Plutora can do just that. It provides an interface to development teams focused on DevOps technologies and isolates them from having to deal with ITSM. You can configure Plutora to feed information from JIRA and other tools directly into tools like BMC remedy. Plutora is the tool that will give project managers the tools they need to apply the right kind of pressure on operations groups to adapt to development teams using Agile and DevOps-style automation.
With Plutora we're trying to address the real challenge of deploying software - the communication gap between operations and development. Think of Plutora as the tool that tears down Shafer's Wall of Confusion and replaces it with a tool that can give you great visibility while reducing risk.