Features Hub

Don’t make DevOps the new Web 2.0

Wed 14 Aug 2019 | Sacha Labourey

The internet is awash with useless discussions that overcomplicate DevOps and its key concepts. If we don’t keep DevOps simple, it will knock team confidence and limit progress

Back in the early 2000s, many freshly minted engineers were eager to learn about everything and anything. The advent of the new technological world meant that there were a few topics that were rather abstract and made any discussion on the topic deeply philosophical.

The best example of this was probably “Web 2.0”. What was it, really? There was always 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 was not this trivialised “thing the average Joe was talking about”. What generally followed was a word soup either aimed at pitching vendor uniqueness or raising the profile of a sophisticated speaker, rather than really clarifying what Web 2.0 was about.

Increasingly these days, the same seems to be happening in the DevOps space. On a near daily basis, new articles are published claiming “This is NOT DevOps” and “You don’t get it, DevOps is not about this!” or “This is not how you do continuous delivery,” and so forth.

While well-intentioned and often with a precise mental model in mind, the reality is that these articles 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. What’s more, people seem to actually have a pretty good view on what it means already.

Keep DevOps simple

So, let’s make it very simple. DevOps is about breaking the silos that exist in IT and in the business. Visualise 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, and so on.

Now, visualise horizontal slices of these teams, one slice 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: Businesses are living DevOps when their cross-functional teams feel their “first home” is their product team, not their department.

From there, either tool A or tool B can be used with whichever methodology is preferred, it does not matter. The right methodology is the one that fits with the company’s DNA and helps reinforce the right DevOps motion. Companies do not need to worry about whether something “is” or “is not” DevOps, as what matters is the change of behaviour that is being driven.


The next area of conversation revolves around continuous integration / continuous delivery (CI/CD). Where does CD start and CI end? What is “true” CD? Again, it does not really matter. Being “continuous” is about iterating fast which naturally causes friction, therefore it is only logical to remove that friction through automation.

In Continuous XYZ, automation is key. However, unless a company is owning a fresh “Hello World” project, chances are that it will not start with a fully automated process.

“If businesses focus on continuous improvement through collaboration, fast iteration and automation, they are going in the right direction, no matter what they call the process”

This will be a journey, almost always. Why? Sometimes because a project is hard to automate, sometimes because the organisation has some cross-departmental hand-off friction wired in its system (i.e., it still has work to do on its DevOps journey, which is to be expected given there is no “endpoint” in the DevOps journey but a constant striving for improvements), so automation will be done in steps.

Frequently, it is easier to automate to the “left” of the process, this is because businesses have been doing this for more than a decade, development tools are all created to be automated.

The left part is referred to as “continuous integration” or “CI.” The further automation leans to the right, the more it becomes “continuous delivery” (CD). Continuous delivery technically means businesses are constantly in a release-ready stage. It allows teams to push new updates to production if they want. However, if businesses do not want to push to production, then they do not have to. It might not add anything to a 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).

The point is that teams are able to automate as much as they want up until the final stage. To go even further, businesses can get to continuous deployment (note the subtle change: from Delivery to Deployment), where the actual pieces are put “in production” (e.g. on a server, on a device, on an app store) with every validated commit. Continuous deployment will actually require a 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.

Different approaches

What about application release automation (ARA) or application release orchestration (ARO)? Are those the same as CD or not? It’s important to remember that CD can be approached in many different ways: from using Chef/Puppet to using home-grown scripts.

In a nutshell, 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 organisations 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 organisations where the “Ops” side of the house is in charge of the release, while in organisations where “Dev” is more in control, solutions à la Jenkins X, will be preferred.

In conclusion, there are a plethora of useless discussions out there that can hurt the confidence of what a team is trying to build. If businesses focus on continuous improvement through collaboration, fast iteration and automation, they are going in the right direction, no matter what they call the process.

Experts featured:

Sacha Labourey

CEO and Founder


developer development
Send us a correction Send us a news tip