Don’t Make DevOps the New Web 2.0

Back in the early 2000s, I was a freshly minted engineer eager to learn about everything and anything, but a number of topics resisted me. These topics were often pretty abstract which made any presentation or discussion on the topic deeply philosophical. Essentially, you were always wrong . The best example of this was probably “Web 2.0.” What was it, really? Anytime I thought I had it, there was a voice out there, a blog, an interview, an opinion piece, that would claim that everything you thought you knew about Web 2.0 was wrong, because “the real” Web 2.0 wasn’t this trivialized “thing the average Joe was talking about,” “it was much more subtle…” What generally followed was a word soup either aimed at pitching a vendor uniqueness or raising the profile of a sophisticated speaker more so than really clarifying what Web 2.0 was about. It took me to become more secure in my expertise to essentially call BS on most of it. And more importantly, to move on.

Increasingly these days, I feel the same about the DevOps space. Don’t get me wrong, I love DevOps. But almost every day I find a piece that tells us that “This is NOT DevOps” and “You don’t get it, DevOps is not about this!” “This is not how you do continuous delivery,” etc. While I’m sure those people are well-intentioned and have a super precise mental model in mind, the reality is that they are not really helping, but just creating more confusion at a time when – if anything – companies need to grow their confidence in their ability to drive digital transformation. And I actually see that most people I talk to tend to actually have a pretty good view on what it means.

So let me make it very simple for all of you.

DevOps. DevOps is about breaking the silos that exist in IT and in the business. Visualize old style vertical teams and departments: engineering, QA, IT Ops, product owners, etc. Each department has its own policy and well-defined “interfaces” that define how a development team pushes new code to QA environments, how and when that code can be pushed to production, etc. Now, visualize horizontal slices of these teams, one slide per product. Team A is focused on the success of product A, they define ONE way to work together for that success and share expertise to get there. Some companies will merge some roles, others will keep distinct roles, it doesn’t matter: you are living DevOps when your cross-functional teams feel their “first home” is their product team, NOT their department. From there you can use tool A or tool B, you can use this or that methodology, it doesn’t matter. Picking the right one, the one that fits your company’s DNA and helps reinforce your right DevOps motion is the right one. Don’t let people tell you something “is” or “is not” DevOps, what matters is the change of behavior you are driving.

Continuous integration / continuous delivery (CI/CD ). Where does CD start and CI end? What is “true” CD? Again, it doesn’t really matter. Being “continuous” is about iterating fast, and since iterating fast and having friction lead to heat, you logically need to remove that friction, which leads to automation. In Continuous XYZ, automation is key. But unless you are the happy owner of a fresh “Hello World” project, chances are that you won’t start with a fully automated process.

This will be a journey, almost always.

Sometimes because your project is hard to automate, sometimes because your organization has some cross-departmental hand-off friction wired in its system (i.e., they still have work to do on their DevOps journey - which is not just fine, but to be expected - you are never really “done,” and having that mindset means you’re constantly striving to find improvements), so you’ll automate in steps.

Frequently, it is easier to automate to the “left” of the process, this is because we have been doing this for more than a decade, development tools are all created so as to be automated. The left part is referred to as “continuous integration” or “CI.” The further you get to the right, the more you get to “continuous delivery” (CD). Continuous delivery technically means “you are always in a release-ready stage .” It means you can push new bits to productionif you want . If you don’t want to, don’t do it. It might not add anything to your business to push more frequently, or it is simply not possible because of the domain (such as uploading an application to an app store, or updating physical devices such as medical equipment).

But the point is that you get to automate as much as you can up to the point you get to final bits. If you want to go even further, you can get to continuous deployment (note the subtle change: from Delivery to Deployment), where the actual bits are put “in production” (can be on a server, on a device, on an app store) with every validated commit. Continuous deployment will actually require your system to know how to deal with that “last mile” to the target server/device/store, measure the impact and rollback in case things go wrong, etc. There is no right or wrong, this is a journey.

What about application release automation (ARA) or application release orchestration (ARO)? Are those the same as CD or not? You can approach CD in many different ways: using Chef/Puppet, using home-grown scripts, etc. ARA is another way to approach continuous delivery and continuous deployment (Forrester calls ARA “Continuous Delivery and Release Automation” – CDRA), one that makes it possible to bring CD to organizations where operations tend to be more formal, require not just predictability but complete auditability and the ability to have formal sign-offs, coordination among multiple teams. ARA/ARO tends to be preferred in organizations where the “Ops” side of the house is in charge of the release, while in organizations where “Dev” is more in control, solutions à la Jenkins X will be preferred. Leadership from Right vs. Left. Both are OK and complementary.

In conclusion, don’t let those mostly useless discussions hurt the confidence in what you are trying to build. If you focus on continuous improvement through collaboration, fast iteration and automation, you are going in the right direction, however you want to call it.

Onward,
Sacha

Additional resources

• Get started with CI/CD best practices

• Download the eBook on DevOps

• Listen to the podcast with Anders Wallgren , CloudBees vice president of technology strategy

A native of Switzerland, Sacha graduated from EPFL in 1999. At EPFL, he started Cogito Informatique, an IT consulting business. In 2001, he joined Marc Fleury’s JBoss project as a core contributor, implementing JBoss’ original clustering features. He went on to become general manager for JBoss Europe, leading strategy and helping to recruit partners that fueled JBoss’ growth. In 2005, he became CTO, overseeing all of JBoss engineering. When Red Hat acquired JBoss in 2006, Sacha played a crucial role in integrating and productizing the JBoss software with Red Hat offerings. Sacha went on to become co-general manager of Red Hat’s middleware division. He left Red Hat in 2009 and founded CloudBees in March 2010. Follow Sacha on Twitter .