Shifting Observability Left – Elizabeth Lawler, AppMap

This is Textron TV. Hey guys. Thanks for the throw.

We're here with Elizabeth Lawler. Who's CEO for atmap? And we're gonna have a conversation about developer productivity and observability Elizabeth.

Welcome the show. Thank you very much for having me my Developer productivity has been an issue as long as anybody can remember but it seems like as of late. There's a lot more focus on it from your perspective.

What's driving that conversation? Well, you know, I think that this is a natural progression now that I think companies have finally gotten their arms around what they're trying to do with delivery, right? So if you think about the evolution of devops over the last decade A lot of focus has been on, you know, really the last the delivery of software into modern it infrastructure.

And so if you look at the theory of constraints, right and you say okay, what are we doing? Well, we can build our application we can test it. Essentially we can release it into protection really quickly high performance organizations can do this minute.

Where's the new constraint and really it's around? What do we build? How do we build it and unleashing the creativity of the developer?

And I think that's really where it's shifting that all of that attention to the new constraint. That's the furthest left. It's the code editor.

Me in to that point. It seems like a lot of investments in observability to help drive that are in the cicd platform and at the you know, we're kind of leaning it a little bit left, but we're not providing the developer themselves with much Insight. So do we need to strike a balance between what the developer can observe and what the rest of the devops engineers can observe and how do we get there?

Well, I think if you actually look at the types of Performing the issues which are now becoming more prevalent and production environments. They actually stem remove causes that are in code design. So if you look at for example at the oauth top 10 or the most recent leading cve their design in nature, they're things that you can only see when the codes running but they stem from code quality issues so such as inversion of authentication and authorization for example as a bad a bad design pattern for for security.

And so it's really I think it's really interesting how you know that being able to see runtime is not actually part of a typical developer developer experience when you write code right? It's like writing the novel and expecting the directors kind of the movie to come out the other side and be perfect. And so, you know, I think by bringing some of that information about code Behavior runtime performance Dynamic security analysis into the developers workflow where they're working inside the code editor we can unleash a lot of creativity which Sucking developer, you know time away into hunting down issues across the later stage sdlc products that you described describe described earlier.

Oh this get because a lot of times the developer even when presented with something doesn't always know exactly what they're looking at and they may not even know what questions to ask. So how do we kind of surface that in a way that is you know, as some people say the idiot taxes as low as possible. I think that's a really great point.

So, you know. observ The itself is almost like a data scientist art, right? Like it's giant amounts of information from from logging and tracing that you get to sift through to try and figure out things that how things are working by scoping information literally to the line of code.

You can bring the kind of you know, we we like to think about it kind of the Google Map problem, right? You don't want to map of every street and every city around the world. You just want an app from here to the next destination which might be a seven eleven.

So you really want to have just the information that's relevant to the code that's in progress the code that's being worked on and have all that observability scope down in a really nice way and link to those lines of code with you know, interactive dependency maps and Trace views and sequence diagrams and things that people can interact with and look at in the scope and localized way and I think that's really how the developer experience for observability is a shift from what you think about as typically like the It experience for observability which needs to be very broad spectrum and nature. And we do this across teams of developers because one of the things that we've encountered for example with security is everybody might scan their code for vulnerabilities, but then by the time you load everything up in the build all kinds of issues start to emerge. So how do we do that in a way that everybody can understand what their peace interacts with somebody else's peace and create some sort of suboptimal experience and can we get in front of that?

Totally I just I finally my code and you don't let yours then our code is not limited. Right? So so it's definitely important to have basically, you know, the first line of defense is to fix errors when they're cheapest to fix right when they're being introduced or when they're being written.

The second line of defense is to catch it at the CIA, you know at the CIA level the when you're when you're basically running everyone's changes in in a common staging environment or in test. So, you know at map itself Works in both environments one of the backstop, but then you know shifted the furthest left because actually, you know, that's where people are most inclined to make the changes. It's the pricing how many things that are flagged actually make it into into production based on we'll say like waited decision making right, you know, you could have things that have been flagged with security issues or flag this potential, you know potential issues.

You might want to have adjust but they'll still make it into production if you're under a deadline. You really want to catch it at the moment of creation and to your point There's an opportunity to use that data in the generative way to make more suggestions about how one might code better and I think that's really just improving the curve right bringing everybody up to having a natural method of coding that's more secure and more performant and helps them understand languages and Frameworks. They work better.

Oh helpful can again in this regard. Will it eventually surface and say hey we've noticed that this is the fifth time you've made the same mistake and perhaps you might want to take this training class to get product Yet it would probably pay extra for that. So but we do make suggestions about things like common, you know.

Common mistakes people make when writing prairies where they live or common mistakes people make in accidentally logging out secret information. And where the information is actually, you know, where the the secret is created and where the information is logged out is two different places in the codes. So, you know, you are it's a I'm not does servant strongly educational purpose around how your code is or how your code base?

It's organizing how it works when it runs and how you should think about working within it. So, I think that's really a really important key part of that man. All right, and how automatic and all this get I mean eventually a lot of developers I know are kind of like well, thanks for telling me but could you just fix that warming?

So can I close the loop on this and what might that look like? Yeah, I think that's definitely well. We obviously provide pop-ups and show you exactly the line of code.

You need to chase change but we haven't yet started writing for you. I think that's where the power of this data can go though, which is if you look at things like co-pilot, right? They it's generative.

It will tell you how to write, you know parts of code very well that's until you how to assemble it together and it doesn't tell you how to you know, how maybe your code will be interacting within with it with an endpoint service or an API or necessarily the database. There's missing piece of that data that that could be used to make those types of code recommendations help people stitch together the components of their application better. And that's something that we're certainly thinking about how we could use it to be more generative.

And who leads to charging kind of putting this kind of tool in place? Is it the developer or is it the devops engineer who got a vested interest in maybe fixing all this stuff and they show up at the end of the holiday year and say, hey look what I got you. Yes, I think that's a great point.

We actually have multimedal distribution of users everyone from new devs to Architects. They're often leading a charge around. Um, maybe they're working on institutionalizing some of their own design philosophy through app map and the ability to enforce even Custom Custom Design patterns in in the coding environment as well as Security Professionals who are looking to communicate better with the recipients of their of their recommendation and that's already who are looking to try and figure out that last mile connection between an existing observability tool or platform.

They might have like data dog or Diana trace and making the code recommendation to the actual development team for fix and so we kind of Play nicely with all of those tools. So I really think that any one of those individuals can could bring us in. I think we're most often adopted by developers because they're in the IDE and we distribute through the BS code and jump Rings marketplaces.

So they're usually the first ones to see it. Once you've missed advice to folks then what's that one thing you see development teams doing over and over again. That just makes you shake your head and go can't believe we're still having this conversation.

oh my I would say that the the ability to pre-preview how your software will behave for being changes. It is one of the most common things people spend their time around chasing down rabbit holes is unexpected behavioral changes. If you could if you run out in advance of of even committing your code to appear you can pre-play for certain types of breaking changes through behavioral differing and I think that is an incredibly powerful tool to be able to optimize your code before you submit it to the rest of the process of code quality like peer review and Central testing and stitching.

All right, cool. Hey Elizabeth. Thanks for being on the show and sharing your insects.

Thank you so much for having me. I appreciate it. All right guys back to you in the studio.