New Relic has acquired CodeStream to bring observability directly into developer workflows in the IDE and help them build better software.
(New Relic CodeStream screenshot)
New Relic yesterday brought observability directly into developer workflows with the acquisition of CodeStream, a collaboration tool that sits inside popular Integrated Development Environments (IDEs) and also integrates to a range of other tools, from GitHub to Jira and Slack. A new version of CodeStream that integrates with the New Relic One observability platform is able to surface application telemetry data directly within the IDE at the relevant point in the code, so that developers can instantly get to work on resolving issues. We spoke to Peter Pezaris, CodeStream CEO and Founder, and Buddy Brewer, GVP and GM, New Relic, to find out more about the news.
The company believes the new product, along with a new pricing tier, will broaden New Relic’s appeal among developers whose primary role is coding, rather than the traditional users of monitoring and observability tools, who focus on operational uptime and reliability. Customers will also get extra value from their investment in collecting and analyzing telemetry data, as Brewer explains:
Especially with the shift to cloud, and decomposing monoliths into the containerization of software, there is so much telemetry out there, that it’s a massive investment that companies are making. The value of that investment can extend so much further than just utilizing that data when the software is on fire …
By bringing that telemetry data into the IDE — I think there’s like 14 IDEs that are supported by CodeStream — you can incorporate this data into your IDE. It allows those developers to access that data when they’re planning and they’re building software, not just when they’re running it. We think that’ll help them get a lot more value out of the investment in telemetry — and also help them build better software.
From error alert to IDE in a click
One of the most compelling examples of how the newly integrated product blurs the line between building code and running it in production is the integration with New Relic Errors Inbox. This recently introduced and already popular capability provides a single location for viewing and dealing with errors from anywhere across the application stack, with the ability to see detail down into the stack trace. But as Pezaris points out, for all its convenience, what do you do then? There’s a button to copy the stack trace to a clipboard, but it’s up to you to then work out where to go next. Whereas with the integration to CodeStream, all of those next steps are automatically done for you. He explains:
Now you’ll be able to click on that stack trace, and you’ll open it up right in your IDE. We’ll check you out to the right repo. We’ll open up the build SHA that was used to build that production artefact. And now that stack trace becomes clickable. So you can click through to all the stack frames, go right to the parts of the code where the problem’s happened.
Because CodeStream’s good at collaboration, every time you do that, we’ll tell you who wrote that code. You can easily bring them into the conversation, swarm the issue between production and non-production engineers, and get to the root cause of the problem faster. We’ll also keep track of who’s been assigned which errors. So now every time you open up your IDE, you get to see all the errors that are assigned to you, so you can investigate and solve those problems.
Another feature uses integration to Pixie, the technology acquired by New Relic last year, which automatically collects telemetry data from deep inside application code running in Kubernetes clusters. With dynamic logging, a developer who wants to instrument a particular function in their source code to see how it’s running in production, can invoke Pixie directly from their code editor to insert a probe and start logging straight away. Pezaris explains:
You can right-click on it and say, ‘Start instrumenting that thing.’ And then you will get feedback in real time in your editor, without having to do a deployment. You don’t have to commit code, you don’t have to change code, you don’t have to push code. Just immediately, you’ll start to get logging back for every call to that function.
As part of the announcement, New Relic highlighted its partnership with Microsoft around CodeStream, which works with the VS Code and Visual Studio IDEs, and also integrates to GitHub and Teams. Commenting in a joint press release, Scott Guthrie, Executive Vice President, Cloud + AI, Microsoft, welcomed the news of the acquisition, stating:
Tighter collaboration between development projects and improved connections between existing applications are just some of the benefits New Relic CodeStream will provide to the developer community.
To help encourage adoption, there will be a new Core user pricing option for New Relic One, starting at $49 per user per month, plus usage charges based on the volume of telemetry data. Developers can sign up for a free account for a preview period ending in January, after which some features will require a paid license.
Joining forces with CodeStream — which is effectively a Disrupt for coders, but with a lot of the integration chops of a Slack built in too — is a huge step up for New Relic in furthering its mission of data-driven software, which was a big theme of its FutureStack conference earlier this year. It helps to close the loop on ensuring that the people building software have as much access to telemetry about how it runs in production as those charged with running it. That can only improve quality and performance.
It’s also a great illustration of why collaboration inside of the applications where people spend much of their working day is just as important and valuable as collaboration around them in applications such as Teams and Slack — and highlights the value of integration that automates the futzing around that otherwise wastes people’s time they move information from one place to another and put it in the right context to then get to work on it. When I write about Frictionless Enterprise, this is exactly the kind of thing I’m talking about.