Here is the summary for those who don’t like to read articles.
Crash Override creates a single source of truth and a complete change ledger for DevOps, by connecting the dots across all your code, cloud infrastructure, tools, builds, deployments and engineering activity, so you can see clearly and work smartly.
Here is the article for those that do.
From the very first days of starting the company, we always knew that we wanted to build solutions to the biggest unsolved problems people had. We started on the journey with the CSO interviews that I wrote about in September 2022, and over the last two plus years, we have worked with a set of incredible design partners ranging from modern technology companies with a few hundred employees, to iconic Fortune 50 companies with hundreds of thousands of employees.
While it's true to say the fundamental problem of visibility that we set out to solve remains the core of what we do today, what we have built is very different to early prototypes, in fact even quite different from those of a year ago. That's what happens when you listen to users rather than try and tell them what they need.
Along the journey we first learned that code-to-cloud visibility, understanding exactly what code was running in production, was a pressing issue that resulted in us developing Chalk, an open-source project we continue to maintain. People were trying to maintain manual records of what was where, and who put it there, something that many products, particularly ASPM, tries and fails to solve today.
Chalk can now be found on its own site at chalkproject.io.
As design partners came onboard and started to utilize Chalk in their production environments, we collectively realized it could do far more than we initially expected, uncovering and collecting hidden data as code flowed over DevOps pipelines, and building up a rich data source about the code changes, developer activity, deep telemetry about the builds, the containers being used and the deployments taking place. It could even be used to beacon back from production, closing the visibility gap in the final mile of the code-to-cloud path.
When we started to connect all of this data together, we had a graph of all of the relationships across DevOps, and then, when our technology was deployed in a CI/CD pipeline, we had a complete change ledger of everything that had happened.
Design partners started asking us to use this data to solve specific use cases, such as knowing who owns the code running in production, and no, if you have ever tried to keep codeowners files up-to-date you know they don’t work. We were asked to develop solutions to identify shadow engineering infrastructure that was burning money, hard to support and didn't have the right security controls. They wanted us to identify which tools were effective and which ones weren't, so they could retire them or migrate them to best-of-breed open-source ones, and again significantly reduce their budgets. One design partner is on a fast path to reduce their appsec tools spend by almost $2 million dollars, to a level that is just 10% of what it was a year ago.
Along the way, we learned that the underlying solutions we built were proving to be as useful to software engineers as they were to security engineers, in fact today we think of what we have built as a platform for devops engineers that also has security use cases. This is important, because it turns out that most of the problems people are solving are just two sides of the same coin.
Let's take shadow engineering. Software development leaders want a sanctioned set of developer tools that they can support, security leaders want to know that they have the right controls in the right place. Let’s take language runtimes like Python or the notorious open-source libraries. Engineering leaders want versions they know they can support, software engineers want versions they know their code will run on, and security people want versions that are free of vulnerabilities.
Late last year we came to a point where we all agreed that we understood enough about the problems, and had feedback from our design partners that we had complete solutions to a number of their most important unsolved problems, that it was time to bring the technology to the wider market. We have spent the last 6 months doing that, and today we are opening up the platform for others to try.
Our vision of enabling visibility, prioritization and strategic fixes for everyone in DevOps, that enables a more effective, efficient and cheaper way for teams to work is called Engineering Relationship Management or ERM. In many ways it's just like SalesForce for software engineering teams hence the cheeky image that comes with this post. When we went back over the history of why CRMs like SalesForce came about, it was the same root problems, data was in peoples heads, spreadsheets, tools that didn't work together and none of it was connected. Nobody knew what was going on. No one had visibility. Nobody knew who to talk to, who had done what and what to focus on. It’s history repeated, but now in the DevOps domain it is more than just customers, its code, cloud infrastructure, tools, builds, deployments and engineers.
You can learn more about ERM today on our new web site - https://crashoverride.com
ERM is for any organization with a sizeable cloud computing footprint and a desire for greater clarity on (and control over) DevOps. It’s for businesses of all sizes, across almost any industry, but it appeals most to those companies with complex infrastructure and production environments. If critical information is stored in various spreadsheets and silos, your software consists of code drawn from multiple sources, or you use a host of DevOps tools and services, ERM will benefit your business. And if your DevOps teams have lost track of how everything fits together, it will change the way you work forever.
Over the coming days and weeks we will be sharing a lot of information about the Crash Override ERM platform.
For engineering leaders we will explain how the single source of truth and a strategic approach to DevOps results in less waste, reduced exposure to risk, and greater cost-efficiency.
For engineers we will explain how a single source of truth and a strategic approach to DevOps means less noise, busy work, and frustration. Instead, it gives teams the information and automation they need to work smartly and efficiently. ERM means there’s more time to build and innovate.
We will also cover detailed walkthroughs to solutions such as code ownership, shadow engineering and migrating to container gold images, and technical posts about inspecting the gory details of what happens inside of builds, and how our inferred code ownership technology works.
You may be asking yourself ‘Is Crash Override for me?
Honestly? We don’t know until we sit down to talk, but we’re not going to bend your ear or twist your arm to sell you a solution you don’t need. Instead, we’ll take 30 minutes to demonstrate what Crash Override can do and how it solves DevOps difficulties and we would love to show you around.
