Application-First IaC with appCD’s Sachin Aggarwal

This is Textron tv. Hey guys, thanks for the throwaway here with Sasha Agaral, CEO for app cd, and we're talking about how AI is gonna get applied to infrastructure's code because, well, there's a lot of nuance here. Hey, Sasha, welcome to the show.

Uh, thank you, Mike for having me. Um, and, uh, thank, uh, and uh, also to your audience who's listening to us. We have seen code get generated by various AI tools, and generative AI is of course, the one that everybody knows, but how will this be applied to infrastructure is code because, well, um, our margin for errors may be smaller, and we already have a ton of problems with misconfigurations as it is.

So how will we get through this process? So that, that's a, uh, good question, Mike. Um, let's first understand what's happening with this whole GI code generation thing, and then we, we'll then move to what's gonna happen with the in code.

Uh, we know, and, you know, we have of course heard, uh, Nvidia and, uh, open AI and everybody talk about that coding is gonna be all automated and, you know, uh, you know, folks, there probably will not be very little human intervention, uh, required to generate code, uh, the application code itself, and there are copilots for it. There'll be probably a lot of advancements in that area. Uh, so we'll definitely see a lot of developer productivity go up, uh, in the next few years because of this, uh, advent of this, uh, gene AI based based s tools.

What's gonna happen is in the, when you throw that all those code into the pipelines, and now you want to deploy those applications at scale, uh, there, there, there are a lot of challenges there. The first is that infrastructure, as code, as we all know, is manual. Uh, it is time consuming.

It requires expertise and has always been error prone, right? Because you talked about misconfigurations. So what will be a right way where the DevOps and the platform engineering teams do not become a choke point or do not become, um, uh, a blocker in the process.

And as we see more and more microservices getting, uh, implemented in, in the cloud for, uh, for the business reasons, how do we ensure that that whole process is very seamless and automated? This is where infrastructure from code, uh, and that's a new term that we are defining, uh, and we are actually calling it generative infrastructure from code, um, will help. Uh, so it's, it's a, it's a, it was a supposed to be like a science thesis for us last year.

When you start thinking about the idea, now, it's a reality because now we have a product and we have, we are demonstrating how it can be applied. But, uh, what essentially we are doing is, uh, taking the application code as a source of throat, whether it is generated by gen ai or it is generated by human, we are using the application code itself as a source of throat taking it, uh, deep, doing a deep analysis of that code, applying, um, our own internal logic to a static code analysis, some AI reinforcements. And using that, we come up with the most optimal infrastructure architecture for that application, automatically auto gate.

And in doing so, we apply policies, we apply governance, compliance, uh, whatever the enterprises may need, or the platform union teams may set up as policy, as code or, or governance as code, uh, we or compliance as code. We apply those and, uh, and then generate your terraform or hand charts, uh, through the, through, through the, through the platform. So the, uh, in, in the, the nuance here is in the new world, when people are going to use Gen AI to do, you know, the code or coding, uh, and get to, uh, launch the business applications, uh, we want to be their partners and making sure that we are not, we are basically generating the code, but in doing so, applying the policies and the guardrails at source.

And so it's not after the fact, uh, scanning or it's not after the fact, um, uh, you know, analysis of what is the mis what is misconfigured and what's vulnerability in that code? How does the platform that you created know what to infer from the application to create the infrastructure as code? I mean, are we scanning that?

What does the app tell you that you can then use to create the code for the infrastructure? So app tells us a lot of things. It does not tell us everything.

Uh, what f will not tell us how the application would be packaged. Uh, where would it run, what the target cloud environment, whether it's serverless, whether it's ECS or whether it's in a container, whether it's on a Kubernetes, it'll not tell us few things. It'll not talk about a scaling and performance, but will tell us a lot of other insights.

It'll tell us the dependencies, it'll tell us the, um, uh, you know, the relationship between the microservices. It'll tell us the, um, the privilege requirements, the access requirements, uh, the API requirements, uh, app has all that context. App has a context on, uh, whether I need a database, if I need a database, is it only read right?

Uh, command, uh, or, or read access that I need to that database. So we can actually log down the privileges, we can log down the, the access to those dependencies, uh, and basically just allow for the lease permissions, uh, or, or, uh, permission that are, uh, are, are configured in a way where the, the privileges are, are at the minimum. You mentioned platform engineering.

Are we trying to centralize the management of infrastructure as code more? It used to be something that pretty much each individual developer did with varying quality on their own, but how do you see this whole process maturing? So platform engineering today has been tasked, uh, to create developer productivity, developer experience, uh, governance at scale, you know, resiliency and all those things that they want to centralize.

Uh, they want to offer DevOps as a product to this developer community. Um, so there are two ways we can see how app CD could be used. If the individual developer in an enterprise is empowered and one to create his own cloud cloud infrastructure, uh, they cannot do so automatically without requiring any, any help from the DevOps.

And, uh, in doing so, like I said again, and reinforce that in doing so, they can, they'll still be able to apply all the cost and the policy guard rails that the enterprise would set at the enterprise level. So when they actually deploy their code, it all comes automatically, uh, uh, in a secure fashion. The platform engineering teams, on the other hand, can actually incorporate this as part of their DevOps offering or as part of their platform offering, where I think they're, they can do, do three things with it.

One is they can, they, they can ensure that they can give a terraform or a ham chart or an infrastructure code, um, to the developers or to those teams without delays. Uh, second thing is they can ensure consistent and, uh, uh, uh, consistent and, uh, unfragmented governments at scale and put all the policy guardrails and what policy code into the engine. And third thing is that they can ensure reliability and eliminate drips by establishing application as a source of code, uh, uh, source of truth and, and, and, and use application source of truth.

Can I lock down more controls this way as well? Because I think a lot of times things get updated during the course of the life cycle of an application, or if somebody comes along and changes something in a setting, and, um, next thing you know, we got issues. So, uh, how, I guess, for lack of a better phrase, immutable, can we make things?

And that is, that was the whole thesis behind it, right? You know, I, I don't know, I don't know if you recall, but you know, I had spoken to your folks, I think I spoke to Ellen last during my last startup, uh, at qx. And, uh, we were solving, uh, the problem that you just mentioned, right?

That, uh, the misconfigurations happened in the infrastructure score. The cloud is being built on the left. We are still doing security on the right.

So ACU was built on the thesis that, uh, if the cloud is being built on the left, can we move SEC security left? We were, I think, probably the flag bearers of talking about breach part predictions and talking about can we find those early? Can we have early signals on what is being misconfigured in the cloud by looking at your infrastructure as code before the code goes into production.

And, uh, when we were talking to some of our customers, our, our early customers at Acura, like Nasdaq and Blackstone and some of the other folks that you were talking to, it was pretty apparent that why do we have to repeat these mistakes? And why do these mistakes get repeated over and over? Um, why can there be a better solution?

Can there be a better way that people can consume infrastructure as code as part of their pipelines? Um, is there a, is there a way that we can automate that and uh, uh, and, and therefore eliminate the need for someone to write infrastructure as code? What most companies have done, they created templates, or they create what they call as golden paths or golden templates.

But again, the templates are good for that point in time, right? For that point in time for that particular version or, um, the stage of the company that it is in, uh, they get dated, right? Because the versions change, the policies change, and then, and, and in two years, fast forward, you know, then you are realizing those templates are dated, but the people who wrote those templates are not within your organization.

So then you have to go back and rewrite those and, you know, take the whole attack debt again on your head. And there's a cognitive load. Cognitive pressures are to learn new things and to apply new policies.

So, you know, learning from those past experience, um, that's where the concept of FCD was born that, hey, you know, we don't have to do this today. I mean, there, there must be a better way to solve this problem at scale and, and, and make sure that when as people think of deploying their application at scale, uh, they're incorporating some of the best practices by default. It almost sounds like to me at least that that reduces the requirement to have cybersecurity people part of the workflow because, um, the developers can handle more of this stuff.

'cause it'll be baked into the process versus today there just aren't enough security people that participate in any kinda application security workflow as far as I can tell. Yeah. So, you know, uh, DevSecOps, right?

I mean, we've been always talking about integrating security into the DevOps processes, right? Again, my last data was, uh, after the fact, even though we said shift left security because we were not scanning the code versus the cloud, but it was not integrated into the development process. Uh, security did not be afterthought.

I think what the, the, the CSO organizations or the security organizations should focus on is setting the policies and the framework and the compliance guardrails. Um, and then once they do that, I think we incorporate that into our engine and we know that there will, there will not be any fragmented governance. We know that what we generate will be always compliant with the enterprise standards.

So, so you are absolutely right. I think this will reduce the need for the cyber security folks to be attached to the engineering teams to see what they're doing is right. Um, get out of the way.

Uh, just, just provide the policy framework, uh, and not, not have to worry about the remediation, take the remediation cycles out, not worried about, um, you know, looking at the misconfiguration of scanning their Terraform files or infrastructure files. Uh, and then point out, and then, you know, when they point out those, those, those misconfigurations people don't even know what the right configuration is, right? I mean, sometimes they don't understand, and, and people like people tools, se secure tools will take a lot of pleasure in saying, oh, they are 200 violation, they are 500 violations, but that's what they can make money, right?

But nobody fixes those many violations because nobody has time to fix everything, right? So, yeah, so you're right. I mean, this is, this is one of the benefits of, of, of incorporating security guard rails into the process.

So what's your best advice to folks about how to get started down this path? 'cause I think a lot of folks have terraform, they got all kinds of stuff in place already. So how do I get from, uh, you know, the quote unquote mess I have today to something that's a little more reasonable and centralized and simpler to manage?

So, uh, the two ways to, uh, to get, uh, app sharing. One is that if you already have your infrastructure being built using infrastructure as code, like Terraform or cloud formation or M charts, you can actually use app CD to, um, uh, import, if that's the right word, those artifacts or those, those, uh, code into or, or, or your cloud environment into app cd. And we will regenerate your Terraform code, uh, in the best practice well architected framework, uh, applying all the policies, which is, which means this now code is fully intermediated from any misconfigurations that your security tools may have alerted to, uh, that will put you on the right path, uh, with your existing environment.

But then when, when the new release of the same app comes in through the pipeline, that's because every two weeks people are changing their application and they're modifying it. Uh, they're writing new, new code, uh, even adding new functionalities. So when we see the new version of the code coming through the pipeline, we will of course, analyze that code, compare it to what is running in the infrastructure, and then point out whether it was right sized, which means what did you actually over provision in the past?

Uh, did you give ex more commissions than required? Because we will do principles of these privileges and also say that now look, your, your whole infrastructure is not misconfigured at all because it's secured by default. So it's fairly simple for people to get started.

If you have a Java to, uh, in the current version of the quarter, we already support Java and Python. We are adding support for Java script, TypeScript and, and, uh, dotnet very shortly. We already support AWS and Azure as cloud environment.

You'll be adding GCP, uh, as a, as a third cloud very soon. So it's fairly simple to start. If you have a Java code, just download our CLI version, which will be available, um, uh, which is available through our website.

Uh, you can integrate into your CI pipeline. You can also use our SaaS version developer edition, which is free to use. Uh, just link your repo, get a Java code link there, and you can get your Terraform files and tester applications and tester environments.

Are we in danger at the top of the interview? You kind of alluded to this, but, uh, we have too much code, the coming through the pipelines, the builds are too big, and we're gonna basically just choke on all our bottlenecks. I mean, what are we supposed to do as we kind of can see over the horizon that developers are writing more code than ever?

So what's gonna happen with the, the poor DevOps people on the receiving end of all that? Yeah, and I think, um, uh, that's the problem we're solving. That's the pain point we're solving.

And our idea is to remove those bottlenecks, uh, enable those people to do better work and not get bogged on in the middle of the night that they need this environment to be set up to test this application or to stage this application, or to put this application to production. Uh, the, the, the starting point is, is, uh, you know, we give them like a, like a, a shrink wrap, if that's the right word, right? Uh, uh, cloud environment.

And they can then, uh, you know, have the, if they have the right privilege and right permissions to deploy that for the developers and their engineering groups and come out of the way and, you know, get out of the way, right? And that is the, the holy grail, right? And that is where we are.

This is what we're solving for, right? All right folks, what you heard in here, we're gonna need more automation to deal with all the automation. So at the end of the day, um, you gotta get in front of this now because as far as I can tell, all that code is maybe, it may not all make it into the build, but boy, there's a lot more of it coming.

Hey, Sasha, thanks for being on the show. Uh, thanks Mike. Fabulous.

Thank you. Bye. All Right.

And back to you guys in the studio.