CloudBees Turning 10!

Today is a very unique day: CloudBees is turning 10! TEN! When my mind cruises through those 10 years, some flashes pop up. I remember very well leaving Red Hat in April 2009, three years after the JBoss acquisition, knowing intimately that I’d be restarting something, but I didn’t know exactly what…A few months after, François Déchery reached out to me, with a strong conviction: the cloud would redefine everything-IT. So we started working from that conviction and the market as we knew it from our JBoss days. I remember my first calls with Bob Bickel and David Skok, asking for their feedback on our first plans. A terrible meeting in Paris with Bob who had been sick all night long after eating non-properly cooked duck the night before. But actually a great meeting as this is when Jenkins was named for the first time! How Laurence Poussot, by then still living in Toulouse, accepted with not an ounce of hesitation to take on all administrative work to establish CloudBees and keep it clean (our co-founders were … on three continents from day one!).

Our first kick-off in Boston, at Matrix Partners’ offices with François, Michael Neale, Vivek Pandey, Ryan Campbell and Adrian Brock (remotely, his flight got stuck) while the Eyjafjallajökull eruption was locking the sky across Europe. Kohsuke joining us a few months later, same for Spike Washburn and Garrett Smith, shortly followed by the Hudson/Jenkins drama with Oracle, our PaaS years, our “Jenkins Enterprise Company” years, to today. Those are all great souvenirs! And this, not just because this has been a very unique entrepreneurship experience (I would have never believed anybody telling me that in 10 years, we’d be 4x bigger than JBoss!), but as importantly because those 10 years have been an amazing human experience. There were not many things I wanted with extreme conviction when we created CloudBees, but one of them was very clear: I didn’t want any diva. Building a company is hard, and anything you can do to have simple and quality human relationships, direct conversations and transparent agendas has no equivalent. Every day, I feel honored and lucky to work with such great Bees: you all rock!

That’s for some of my personal memories. But the CloudBees adventure is also an example of how you can stick to your ideals and vision, all while having to learn and adapt, sometimes in painful ways. I thought I’d share some of that journey with you…

When CloudBees was founded, we had a clear vision: to empower developers to have an impact by streamlining the path from idea to production. Our journey through that decade led us through different paths, but that initial vision never changed.

The first realization of this was through the development of a Platform as a Service (PaaS), which wasn’t just a deployment environment – what PaaS was back then – CloudBees was the first PaaS that encompassed the full application lifecycle, from Git to deployment. It obviously had Jenkins at its core!

From SVN to Git hosting, binary repositories, CI/CD, deployment to production to scaling and providing high-availability to your applications - we were a one-stop-shop!

The PaaS market was still young back then (Docker containers didn’t even exist yet) and enterprises were concerned about investing in a space with a clear lack of standards. As importantly, while individual teams liked this “one-size-fits-all” approach, as we were trying to broaden our usage within organizations, there was always something wrong with our offering: sometimes companies wanted to deploy another PaaS, or another cloud, or on-premise, or wanted to use some other repositories, etc. Ultimately, while a quick getting started experience was invaluable, freedom of choice and flexibility were much more important: companies had existing investments, and would continue to make investments, in lots of different areas and a one-size-fits-all approach was simply not feasible, they were looking for something much more adaptable.

Yet, there was one thing the market absolutely loved: the ability we offered to streamline the software delivery process! In that first phase, we learned that enterprises didn’t care so much about the destination we were offering (our runtime PaaS, RUN@cloud), but they really liked the process to automate the journey of their application to a destination, any destination. This is becoming a Continuous Economy, where all things are constantly in flux, and, logically, continuous integration and continuous delivery were the thing! So, in 2014, we made the difficult decision to get rid of all of our runtime PaaS and focus exclusively on Jenkins. Enter the “CloudBees 2.0” era, we became the “Enterprise Jenkins Company”!

That phase of CloudBees was, in some ways, pretty straightforward! There are millions of servers operating Jenkins workloads, and a number of them could benefit from some help: support, security, scalability/elasticity, certification, easy upgrades, management, etc. This gave birth to “CloudBees Jenkins Operation Center,” a key part of our subsequent offering (CloudBees Jenkins Platform, CloudBees Jenkins Enterprise and CloudBees Core). At that time, while CI/CD practices were definitively being adopted by organizations, the CI/CD market was relatively well-segmented among CI/CD vendors and other DevOps vendors were focusing on their birth market (Git, binary repositories, etc.). The market attention during that time was a war to own the next-generation data center: it saw the emergence of Docker, Swarm, Mesos, etc. to eventually land on Kubernetes. About when that topic was getting settled, the market came to realize that while the destination was critical (Kubernetes!), the journey to get there was as critical: if you can’t (continuously) deliver your applications efficiently, why bother having an efficient target? It’s about the journey as much as it is about the destination!

Logically, this is when DevOps vendors started thinking about the bigger picture, moving from their birth “feature” (which are always at risk of being wrapped by some broader concept) to a true, more global solution. This is also when Cloud adoption started drastically accelerating, including SaaS adoption.

Is this the moment when the story jumps to CloudBees 3.0? Not so fast… Remember, it is about the journey… for us as well!

What followed was a period of transition for CloudBees. We recognized that the surge of DevOps, cloud, containers and “cloud native” development would require extending both our breadth and depth, to opinionated tools developed specifically for the cloud era (hence the birth of Jenkins X), that SaaS would matter (CloudBees CodeShip, CloudBees Rollout), that companies would need to be able to effectively measure and optimize their DevOps initiatives (CloudBees DevOptics), that they would need to orchestrate not just their new, cool cloud native applications but wanted to extend the benefits of continuous integration to continuous delivery even for their more classic applications (Electric Flow!), and in doing so – and observing our most leading-edge customers get successful – that there was a need to establish software delivery as a true business practice – not just as a boiling ocean of local experiments. Furthermore, what we learned during our CloudBees 1.0 days would remain true: companies are looking for adaptable solutions, solutions that embrace their reality rather than replace all they’ve built for a long time.

Much like a painting in progress, elements were starting to make sense individually, but the overall picture took some time to get clarity.

This eventually leads us to where we are today – CloudBees 3.0…

I’m very excited by this next chapter of CloudBees, one where after much discovery, our picture is extremely clear and makes sense of our assets in a unified way, from on-premise to cloud to SaaS, from CI to CD, from heritage to cloud native apps, from software delivery automation to raising software delivery to a business concept.

CloudBees 3.0 is built on a common platform, one that shares concepts that have been existing in individual products until now (as most joined from acquisitions), putting more weight behind a single arrow. Our vision to manage software delivery as a business process and to empower developers to have an impact, including in large organizations, has never been so tangible. Through our work at CloudBees, we all have a very unique opportunity to impact the world by enabling developers, any developers, anywhere, from any background, to maximize the weight behind their punches.

At a time when software is eating the world, “Software Delivery” becomes a critical concept. More than individual tools being used to achieve said delivery, there is an immense value that lies in the processes and data that sustain that delivery. This is where CloudBees reigns as an absolute leader: no other company is better positioned than CloudBees to orchestrate such delivery in a holistic fashion with as much depth and breadth, collecting associated data, extracting insights and, in turn, providing control over this process – all while embracing the reality of customer environments, not trying to replace it. CloudBees is the leader in Software Delivery.

Like in many other domains, some teams are responsible for doing things, while others are responsible for managing the “doing” of these things. The most obvious example of this are factories producing goods. An equivalence can be made with software, replacing goods with electronic goods.

This leads to Software Delivery being composed of two layers: the automation of software delivery (i.e. the factory where the goods are being produced) and the management (and control, and optimization) of that process. Welcome to Software Delivery Automation (SDA) and Software Delivery Management (SDM). You don’t have to pick your team, it is not one vs. the other, both are indispensable: you can’t reliably deliver quality software that creates real value without proper management and you can’t manage something that doesn’t exist. SDA and SDM are the yin and yang of Software Delivery.

SDA is the box that contains all of the assets that have made CloudBees successful to date: from Jenkins, Jenkins X, CloudBees Core, CloudBees Flow and CloudBees Accelerator to CloudBees Rollout, this is where continuous integration, continuous delivery/deployment and feature flags reside. This is about making software. In the next few days, we will be updating our website with updated positioning to reflect a number of evolutions. I’ll be blogging about it then. But the net of it is that the entireCloudBees SDA offering will be available both as software and as a SaaS , and will be able to satisfy both cloud native and classic applications. This will hugely simplify our positioning: from classic projects to cloud native, from a software offering to a SaaS offering, we will have the right integrated offering for you, around a unified platform..

With SDA we confirm our belief that organizations want a unified approach to orchestrate their software delivery, but want freedom of choice when it comes to the specific tools they will be using as part of specific steps along their orchestration: tools come and go, different teams will make vastly different (and opinionated!) choices on what tools to use, nobody wants to be locked into specific feature tools. Our strategy is not to offer an average pre-integrated solution that might fit everybody in a one-size-fits-all approach, our approach is to embrace diversity and freedom of choice for our customers, today and tomorrow.

As stated above, Software Delivery without a management layer can only be successful as a “local” phenomenon i.e. within a small environment. As the usage of modern software delivery and CI/CD practices scales within an organization, both in terms of users/projects but also in terms of pace, the ability for organizations to make sense of what’s happening tends towards zero. SDM is what makes software delivery scale and be part of a positive feedback loop.

Companies now clearly understand that becoming good at producing business value through software is key, to achieve this they need to go faster, be more reliable and so they engage on DevOps initiatives and CI/CD – that’s where SDA obviously comes into the picture. It starts with PoC (proof of concept) within small teams and it expands from there. Pumped by their first successes, they expand adoption throughout their organization, success breeds success! What were yearly releases become quarterly releases, weekly releases and, in some cases, we see more leading-edge teams start pushing changes straight to production: those are not just team-synchronized releases that make it to production at a regular interval, but a constant stream of parallel changes hit production at any point in time. Step back and visualize not just one team but the organization overall: you are suddenly facing what seems like an uncoordinated storm of changes flying left-to-right, right-to-left, a storm you can’t make sense of at this altitude. The good news? You wanted speed, you wanted increased velocity, and you got it! Change is now everywhere. The bad news? You feel like you have no visibility, or control whatsoever on what your organization is doing anymore; gone is your peace of mind. When your leading-edge team did the first high-velocity DevOps PoC, all was fine: you trusted that team, these were your best elements, they knew exactly what kind of scrutiny they were getting and were careful to be successful without appearing as a danger to the organization. But now? These are not a dozen people anymore, we are talking about hundreds of developers, dozens of projects in a constant state of change, hundreds of different DevOps tools! How do you manage this maze? How can you detect areas of optimization? How can you make sure that your policies are satisfied at all times, while not impeding velocity? How do you not end up on CNN for the wrong reasons? This is where SDM starts to come into the picture. SDM offers this eagle-like view of this ocean of changes, captures all of these signals and not only stores them in a system of record but, because teams will be using different systems and tools, normalizes them along a unified DevOps data model so you can then “query your organization” without having to care about the specifics of each individual team. With this data, the sky's the limit: you might care about team productivity, detecting complicated inter-team bottlenecks, predicting the ETA of releases, analyzing where specific code fragments or libraries currently are in production, etc.

Based on this data, you also get to validate in real-time whether what’s happening in your organization satisfies the rules and compliance you are subject to. Front-end banking applications need to go through specific security checks before they can hit production – you don’t care how and when but they have to? One way is to pause any release and check what’s happening. That’s what a lot of companies currently do with ServiceNow/ITSM today, but this is a clear DevOps anti-pattern: you’ve worked hard to get velocity within your team and now you are going to gate all changes before they hit production? What are you expecting to do within that gate that will increase your sense of safety? With SDM and its eagle-like view of the signals, we get to validate in real-time that policies are respected at any point in time, and, if that’s not the case, take action. You might want to stop a release, or maybe you are fine to let it go if such a security check took place in the last seven days, or you might want to raise an alert but not block the release. The point is that you are not slowing down any of the hard-won velocity, the SDM eagle is observing any signal in real-time and only acting as needed, this is a complete paradigm shift that’s very much required for this new era.

And then the real nirvana with SDM is how it connects the entire business to the software delivery function, and enables organizations to truly maximize the impact of their software value creation efforts. Recall part of the CloudBees vision "...a million parallel threads of creativity all safely and successfully make their way from idea to value." "Value" is the key word here. There is an analogous phrase:

"If a tree falls in a forest and no one is around to hear it, does it make a sound?"

Similarly, software teams can create the best products the world has ever known, but if they are not adopted, and their users and customers don’t effectively realize the value of those products, then the software might as well not exist.

SDM enables walls between functions across an entire business to be dissolved – again “EMBRACE!”, gives everyone the visibility and means to collaborate around the software delivery efforts so that businesses are able to not only deliver software with improved efficiency, but also improved efficacy - that is to say that the software they create is aligned to overall business strategy and goals, and teams from every function are all working together seamlessly to drive continuous improvement in value and impact.

This is what we mean when we say that SDM turns software delivery into a core business process.

All companies we are talking to either need SDM today or know they will need SDM once they’ll be past their SDA discovery: there is no way any company can manage that complexity, get smarter about their delivery, and turn software into their unfair advantage, all while getting peace of mind, without SDM.

CloudBees, with SDM, is truly defining a new market, one that will be perceived as being as obvious as CRMs or ERPs are today. SDM also makes it possible for us to “move up” in organizations, by providing insights and value to higher-level management that was either very tedious or simply not possible before.

Onward!
Sacha