Enhancing Code Reliability – Jason Turim, OpsCanvas

This is Textron tv. Hey guys, thanks for the throw. We're here with Jason Toum, who's CTO for Ops Canvas, and we're talking about generative AI and all the excitement that goes with that, but there's also other ways to accomplish some of the things that we're getting excited about that maybe are not quite nearly as heavy a lift.

Hey, Jason, welcome to the shop. Hi, Mike. Thanks for having me.

What's your sense of what's going on with generative AI right now? I think that it's clearly gonna be used in DevOps workflows, but to what degree is a question and are there other ways of thinking about this in terms of maybe generating scripts, code, whatever we need that doesn't require us nearly as much expertise? So generative AI is a very exciting technology that's really captured the imagination, I think, of developers, uh, and, you know, business people and really, uh, people not involved in tech at all.

And it, and it's an exciting technology that can, can do a lot and has enormous, uh, promise. But, uh, the issue that I find in, particularly in a DevOps sphere is that that's such a mission critical part of business that you can't, um, be at risk of the hallucinations that are associated with degenerative ai. So, so what Ops Canvas has, uh, developed is we've built a, um, a tool that can produce IAC, um, deterministically.

So that is that every time you generate your IAC, you know that you're gonna get the same thing, which is not what's the current state of the art in, uh, generative ai. And that's a subtle point. Um, the generative AI platforms, as far as I understand them, is gonna generate some code for you, but it will be based on the code it was trained with.

It's a general purpose platform, and not all that code is of the highest quality. So there might be vulnerabilities and you may not get the same answer twice, so you'll get different things and you won't know what the level of consistency is. So do you think people appreciate that little nuance just yet?

Uh, I mean, I think certainly certain people do. I think savvy people, people who are involved in the, in, um, technology and building solutions have a deeper appreciation for that than maybe, maybe some others. But, uh, but yeah, that, that, I mean, that is the, the core of the problem right now and why we don't suppose it's appropriate to turn over these mission critical, uh, tasks to a generative ai, um, you know, all together.

I mean, so the, the obvious answer to this is, well, let's put it, let, let the machine generate the code and then we'll have our people, um, you know, review it, which is fine, but when you're trying to, that's not really time savings at that point. In fact, you know, oftentimes, uh, have having to, um, review code is harder than, um, creating it, you know, as a, as a lifelong programmer, maintaining code is, is difficult, but writing code is easy. And, uh, so, so I think it's a, it's an idea that belongs in the lab to a large degree, uh, rather than at the front lines of business where, where I think things can go really wrong.

So you described your approach as deterministic. What does that mean exactly? How does it work?

What, what do I see and experience? Sure. Uh, well, it ops canvas platform, what we do is allow, uh, software teams to build their software diagram, and then we generate the IAC from a software diagram, uh, and a software diagram is made up of, uh, services in our world, and that is managed services provided by a cloud provider, the ones, you know, we rent.

Then you have public services, which are services that, uh, a third party may have written and, and post to a public, uh, container registry like Redis on, uh, Docker hub. And then they're the private services, which are the containerized services that your business has, uh, built, sort of encapsulate the, the value of, of one's business. And so assembling those into a, a diagram, um, showing sort of the data flow and how, how these services communicate with one another, we're able to, um, generate, interpret, and generate the IAC and put it in a GitLab Git ops workflow, sort of under the covers on behalf of our users.

And when we say deterministic, that means that every time the same set of, uh, services are on the diagram, uh, you will get the same, uh, source code every time or the same IAC code every time. So that is to say, obviously it's different per diagram, uh, and per service, but if it's the same services all talking to one another, you'll always get the same, which is something that can't be said for generative ai. How hard is it to set something like that up?

What's involved? Well, I mean, we try, we're making it easy, you know, uh, we want users to come in and be able to register their private services, and we provide a, a set of services for the cloud providers, the managed services. We give our users the opportunity to pick what they want from, uh, the, the list we have.

But it's, uh, a very straightforward diagramming process of, uh, you know, node nodes and nodes and edges, uh, just disks with lines between them. Hmm. And I get more consistent code because one of the issues that is out there is a lot of times developers are writing their own code to provision infrastructure, and surprise, surprise, there's a lot of misconfigurations and there's a lot of security issues.

So is this a way to kinda address that and without necessarily increasing the cognitive load on people? Yes. Uh, yeah, exactly.

So, so the, the, we believe that standardization of IC is incredibly important in an organization. And, uh, oftentimes IAC is just written by, not just written, is written by the people, obviously, who are available to do so. And, um, you know, it's up to a discipline on the team to make sure standards are followed.

And that sometimes, uh, especially in the heat of the moment, is difficult to, uh, adhere to. Um, so the, the, the IAC that we produce is, uh, you know, it's always the same. And, um, that's sort of a key to standardization.

It's a key to being able to read it and understand it in different environments. And of course, in our platform, the same, in the same diagram can be deployed to different environments with different settings, which is something that might have to go back to the team to be written or, or worked on in a more, more sort of traditional, uh, DevOps shop. Particularly around, I mean, we're talking about the deployment of software, you know, not, not automating every single DevOps task.

We have seen the rise of platform engineering in DevOps environments. So are they the folks that are gonna have the keenest kind of interest in this capability? Uh, it's the DevOps folks and as well as the engineering team at large.

I mean, one of the big, big problems that we're trying to solve and that we've heard from, uh, you know, our, our colleagues in the industry is that it's still a bottleneck. And that, and that the promise of DevOps was that the, the, so the people building the software would be able to manage their software, uh, and the deployment process. And what we've found is that often the, the, there's a, you know, there's a new team and, and it's the DevOps team who knows how to get the software to the cloud and monitor the software and observe the software and that.

And you might have a development team that's building the software. And we still have, uh, the silos that, uh, we were trying to sort of, uh, tear down with the, with the whole philosophy of DevOps. And what our platform is, is doing is, uh, giving a lot of the deployment control back to the engineering team.

So they're the ones who know the software, they know what, um, which of these services they need. This diagram that I was describing that exists, either it's drawn somewhere in a diagram somewhere, or it's in, uh, the heads of the team that's working on it. But this is, uh, a tool that, so the software teams like it because they can draw this diagram that they have already, uh, and deploy from it.

And then, uh, the DevOps engineers themselves will like it because this is not the, really, the fun work of DevOps is, um, writing IAC and, and getting environments up. There's more, more pressing issues, uh, that need to be attended to often, you know, often DevOps, uh, you know, practitioners have a laundry list of, of stuff to work on, and they're caught at the, the top of that list. So we're, we're trying to address sort of both, both sides of the house.

I think the cybersecurity folks have a vested interest in this conversation. 'cause it's usually them that wind end up cleaning up the mess, right? Yeah, right.

For sure. I mean, cyber cybersecurity folks have an interest in every conversation, I think. Um, but, uh, largely the, the standardization really speaks to them, right?

So we produce, as I say, deterministically produce this sort of vetted known good IAC that a security engineer can review and that can be stamped out every time an environment is created. And so, you know, this is in the deployment effort, this is how we can sort of speak to that, uh, segment of an, an engineering team. Can I reuse the code that gets generated and do I put that where in a GI repository somewhere?

Or? 'cause I think one of the things You, well, we do all that. I'm sorry, Mike.

We do all of that. So we're, we, we generate the code, we run the GI ops and we allow, you know, we have me emerging versions and all of this on behalf of our users. Um, so over time, uh, you know, we will expose the underlying IAC back to our users.

Mm-Hmm. So where do we go from here? What's next from you guys?

Well, uh, I mean, we're, we're a young company with, uh, with a lot, lot of opportunity out in front of us. So, uh, you know, I think that, um, we're looking at, uh, partnerships, uh, as a way to incorporate, we think that we've have a really strong story for deploying software to the cloud and we think we can make it very easy to integrate with existing, uh, tools that, uh, work with your, the software company provides. And we can make the deployment of both quite simple.

So, so that's, uh, sort of one area that we're looking at. Um, I, you know, we have a long roadmap of features that we feel we're, you know, a particularly good position to deliver. Having worked on software for so long, there's always a lot of, uh, tools, uh, for software teams, internal tools that a team rarely has time to build themselves.

'cause they're focused on, uh, you know, building the business, uh, value and not necessarily the tooling that a team would like. And, uh, so we have some ideas about, uh, what we could release to sort of help help the, the core teams, uh, build, build their products. All right, folks.

Well, you heard it here. Generative AI is cool, but it may not be the be all and end all. 'cause it turns out there's other ways to solve these issues and problems.

We just have to explore them and maybe get somewhere that doesn't require a data scientist to sit at your elbow to figure out what's going on. Jason, thanks for being on the show. Thank you, Mike.

All right, back to you guys in the studio.