CI/CD Magic Quadrant
Today, the CI/CD market has roughly 35+ vendors all claiming to do the same thing. In fact, some of these vendors will sell you lunch if you strongly believe that every developer needs lunch in order to deliver software faster.We've spoken with thousands of customers over the past two years, and it's fair to say that most customers are confused around CI/CD, its processes, core use cases, and tools.We thought it was about time to put some facts on the table and clear up the confusion. I mean, why let facts get in the way of a good story?
Fact 1: Continuous Integration != Continuous Delivery
Spoiler alert: CI and CD are not the same thing.Continuous Integration (CI) is about taking code to artifact. Think of this as the building and testing of code.Continuous Delivery (CD) is about delivering those artifacts to production in a safe, quick, repeatable way. Think of this as the deployment of code to your customers.Right then, here are the top 5 CI tools we've heard the most from customer meetings:
- Jenkins
- CircleCI
- Atlassian Bamboo
- TravisCI
- ConcourseCI
We actually use Jenkins at Harness for CI, and I would say 90% of our customers use it too.Right, that's CI settled. Now, let's focus on taking those beautiful artifacts into production.
Fact 2: Application Release Orchestration != Continuous Delivery
17 years ago in 2002, a vendor called Electric Cloud was born, who over the years began to automate the delivery of application software into production. Today, that same vendor appears in the Gartner Magic Quadrant for Application Release Orchestration (ARO) as a leader with revenue of approximately $15-20 million.Electric Cloud isn't alone as a leader. XebiaLabs (founded in 2008) is up there with revenue of $30-$35m, IBM UrbanCode Deploy (founded 1996) is there with $35-40m, and finally, Broadcom/CA/Automic Software (founded 1985) is up there with $50-55m revenue.All these on-premises solutions were founded and architected around the concept of a "release"—meaning, a big life-changing event that requires project management of requirements, timelines, change control, modeling of static infrastructure, and finally management of software artifact dependencies. Why? Because from 1985 to 2008, that's exactly what we did as software professionals. We had project managers who meticulously worked with engineering and IT Operations to coordinate releases once, twice, or four times a year (if you were lucky).A few things have changed since the 80s and 90s. I will agree that pop music, in general, has declined to new levels of despair. However, many things in IT have changed for the better.For example, pioneers like Jez Humble and Dave Farley started evangelizing the concept of Continuous Delivery in 2010. Amazon Web Services (AWS) did the same with cloud computing around the same time, and Patrick Debois/John Willis challenged the status quo of Dev/IT Ops culture with DevOps.None of the ARO solutions mentioned above were founded, designed, or architected around the birth of Continuous Delivery, Cloud, or DevOps. They were built for the previous generations of applications, infrastructure, and IT organizations.These vendors themselves do not even practice Continuous Delivery, despite marketing themselves as a DevOps or CI/CD platform/solution.A few weeks back, CloudBees acquired Electric Cloud to complement their portfolio. So now you've got on-premises CI + ARO being pitched as if it's a game changer.
Fact 3: DevOps != Continuous Delivery
DevOps is about team mindset and alignment to achieve a set of business ideas, goals, or outcomes—that mindset being defined by culture, automation, measurement, and sharing (CAMS).The vast majority of DevOps teams we engage with at Harness are responsible for owning automation and tooling so they can empower developers with self-service capabilities to increase developer velocity.The last thing you want in an org is DevOps owning automation AND every deployment; otherwise, you've just created another IT Ops silo and bottleneck.Continuous Delivery is a process or pattern that software engineers (not DevOps) follow so they can deliver software artifacts more frequently and faster for the business.CD can be perfected with a DevOps culture, but DevOps is not mandatory for CD to happen within an organization.CD is what teams practice; DevOps is the culture/environment they practice it in.Sure, DevOps and Continuous Delivery are a winning combination—but don't confuse the two.
Fact 4: Very Few Continuous Delivery Vendors Actually Exist
Up until a few years ago, the only viable solution was to build CD capabilities yourself by extending your CI tool with bash scripts.Netflix did just that and open-sourced parts of their Spinnaker platform in 2016.Around the same time, we founded Harness to offer a Continuous Delivery as-a-Service.In our first year (out of stealth), Harness partnered with over 50 customers that included the likes of OpenBank (Digital Bank of Santander) and SoulCycle. We were also fortunate recently to have Google Ventures and ServiceNow invest in our Series B.Being true to our cause and vision, Harness also practices Continuous Delivery with daily production deployments to our SaaS and on-premises customers. I mean, how could we convince customers to do Continuous Delivery if we didn't eat our own dog food?Harness also recently became part of the CNCF and CD Foundation to help drive standards and APIs for our industry. We'll see you next week at KubeCon in Barcelona!Cheers,Steve.