Revolutionizing Infrastructure Management with StackGen | KubeCon SLC 2024

This is Textron tv. Hey everybody. Welcome back to CubeCon plus Cloud Native Con in Salt Lake City.

We're here with Azi Wan and Daniel Cook from Stack Gen, and we're talking about, well, a different way of thinking about infrastructure's code. Hey guys, welcome to the show. Thanks For having Us.

Thanks for having us. Everywhere I turn around, there's somebody talking about infrastructures code and there's a lot of debate in this community now and some people are unhappy with other folks, but, um, I guess I'm gonna ask the question to you. Is there a whole other way of thinking about this thing that we're kind of missing?

Absolutely. And that is what we have come up with and that we refer to it Stack Gen as infrastructure from code because, uh, the past 10 years or so, right, seven to 10 years, uh, Terraform has reached its maturity. It has become overly complex.

So all the arguments and the discussion that you hear about, uh, about how to make infrastructure as code, they're primarily talking about Terraform and how to streamline it, how to just deal with that complexity. And we strongly believe that every enterprise and every organization that is dealing with and using and managing infrastructure as code, primarily the Terraform files and so on, and the templates, they should be thinking about infrastructure from code. We're here at CubeCon.

Um, how does that thought process apply to cloud native applications and Kubernetes and, you know, 'cause we're all in love with those ammo files, right? Well, Yes. Um, so, you know, we asked this community what they thought about infrastructure as code and they all said it was hard.

And you know, in this community specifically, they're looking at Helm charts going, wait, what? So, you know, we wanted to remove all of that problem and we actually asked the community what they thought, like, is infrastructures code easy? Is it hard?

And only 13% of them said it was actually reached a mature level in their organization. People are struggling with it. And 97% of the people we asked are like, it's hard.

It's hard to write it, it's hard to manage it. Like we don't know what to do. So when we looked at it, and you know, the reason we're here is because, you know, we wanna make it easy.

We wanna make, you know, your helm chart creation, your infrastructure code easy. And we don't want you to have to be working through your YAML files to figure out how to deploy an application. One of the dirty little secrets of it is that a lot of the security issues we deal with are directly related to Misconfigurations that resulted from somebody who didn't really know how to use the tool in the first place.

So if I'm gonna do, um, infrastructure from the application rather than me the developer can, will it be better outcome? Will I have a better implementation in a more secure configuration? Absolutely.

So there are two problems, uh, associated with people handcrafting infrastructure as code and managing them over a period of time manually or through using some clergy tools, if I can call it that, right? The way infrastructure from code addresses that problem is that rather than taking a reactive approach to scanning the infrastructure as code after it has been written and it has been reiterate or corrected, infrastructure from code basically takes into account the policies that need to be applied and builds in those policies in the form of specific configuration. So as a developer, just to be very specific, I don't even need to care about what kind of security or in compliance policies my application deployment needs to adhere to and in first place as a developer, most developers do not, not just care about it, they do not also know about them.

You know, so that is how infrastructure from code solves a problem, making it built in rather than be reactive and do this post scanning and then remediating and fixing all of those issues. I think we skipped one step here. How exactly does the thing work?

'cause a lot of people are gonna be like, well that sounds great, but you know, is that magic or what? Uh, there is a bit of magic and there is a bit of a lot of hard work as you can imagine. So when we talk about infrastructure from code, let me start by defining it, right?

So code is when, when we say from code, code is not just the application code, code could be from our perspective, there are four different things that we support as infrastructure from Code One is the application code itself doing the static code analysis, which is what Stack Gen platform does, infers the, uh, the infrastructure related dependency that an application has, generates the topology, presents it to the user. And then once the user is confirmed that the deployment topology looks, looks right, stack Gen goes at and auto generates the deployment files or the IAC files with built-in policies like I just mentioned. The second flow is that the user could be a DevOps engineer, may just say that, Hey, I do not have access to the application code because I'm not an application developer, but I would still like to create the infrastructure.

Those DevOps engineers or such DevOps engineers or users could actually go and use our canvas, which we call as the visual builder, and drag and drop all the resources that they need with all the iams and the rules and the policies built in and generate the corresponding infrastructure as code for them. The third approach that we support is, uh, you could already have application that are deployed and resources provisioned in the cloud, and those resources could be provisioned from, uh, the cloud console like AWS cloud console and so on. We can reverse engineer or the Stack Gen platform can reverse engineer the, uh, those deployed resources and configured resources and generate the infrastructure as code for you.

The fourth, uh, flow that we support, uh, sorry, please bear with me as I lay out all the details. Um, the fourth flow that we support is, uh, you may have used Terraform for provisioning the resources in the cloud, but those Terraform templates on your files would've gone out of date, right? I mean, they're outdated because they were created and never managed, and the users were going directly to the cloud and making the changes and so on.

So if you give us the state file, right, we can reverse engineer your Terraform State file, getting into specific details here, and also generate the latest and greatest compliant security and governance policy compliant Terraform code or IIC code for you. I'm curious, based on what he just said, there's a lot of people talking about platform engineering here at this conference. Where does that fit in your construct a little bit?

'cause as I understood what he just said, well, if I do that, then maybe I don't need this massive cultural change to make the entire environment work. Or, you know, am I, is that overkill or is it a response to a problem that we can solve another way? You're, you still need your platform teams, right?

The platform teams are creating that paved road, you know, they're helping developers with their experience, their velocity and whatnot. But this is one slice of that puzzle, right? Developers are slowed down because they're having to write their infrastructure as code and the platform teams with the DevOps teams, they're having to audit those things and, and, and support their developers when they're going, I can't get this out and I'm delayed and the business wants me to be deploying this new feature, this new application, but I can't do it.

They, it's taking away from the platform teams actually making the platform better. So we're just eliminating that burden to all of the teams by going, Hey, we got you. We're gonna make you more secure.

We're gonna standardize this and you're not gonna have to serve as this help desk for the devs and they're gonna be happier. Yeah. The other thing everybody's talking about is, you know, ai, so where does AI fit in your mindset in terms of this construct?

Is it have a role? Am I gonna use agents at some point or? Absolutely.

Uh, it, it does have a, the short answer to your question is that it does have a role. We are already using Gen AI capabilities for some features within our platform. Uh, what I just talked about, the canvas to code feature, the users can just use our gen AI prompt and basically just describe in natural language.

Currently only English is what is supported for prompts. Um, they can describe their entire topology, uh, in, in natural language and get that entire topology diagram be presented to them on canvas and auto generate, or get the IC files that are autogenerated in terms of, uh, using gen AI based agents for analyzing the source code. We constantly experiment with various different LLM models that are out there and both open source alama and the closed source ones, right?

Like the ones from OpenAI and such. What we have realized is that they hallucinate big time, you know, and so what we are talking about is the problem that we are trying to address is, hey, developer, you do not, one of the flows that we were talking about earlier from an infrastructure, from code perspective, you do not have to wait for the DevOps, uh, uh, engineers or the DevOps team to be creating the Terraform files for you. What that means is whatever is the replacement for that existing process has to be reliable.

Okay? If we were to use gen AI tools the way they exist and create something which are let's say 99% accurate, which means for the one per percent, the remaining 1% of the confirmation, the developer would still have to go back to the dev DevOps engineer. And then we are back to square, uh, uh, square one where the deployments are getting delayed and fingers are pointed or blame being passed around as to what caused the delays.

This is the difference between probabilistic and deterministic, right? Absolutely. Absolutely.

That is, I'm so glad that you brought it up because our approach is completely deterministic. You run it and it is item Putin, which mean you run it 100 times, you're going to get exact 100 the same result 100 times, or the Terraform files with the same set of configurations. You've had a number of customers do this at this point.

What have you seen them do? Well, what are they, you know, what's your advice based on what you've seen these people kinda learn and, you know, what's the thing you wish people who might do this would learn earlier and avoid? Well, I think it's a crawl, walk, run approach.

You know, we are disrupting the infrastructure as code industry. So when we have customers, they might not be ready for the full generative infrastructure from code, but they do need help and they need, you know, help with their state files and they need help with, you know, what, what exists in the cloud and what doesn't. And we're able to support them on that journey to go, let's start here.

Let's clean up what you already have as infrastructure, as code, and then let's create views that your teams can easily use, and then we're going to get you to generative infrastructure from code, because that is where the market's changing. What do the cloud service providers say about all this when you present it to 'em? So a lot of the, a lot of the vendors are in support of it.

So we work with AWS, we work with Azure, uh, we work with GCP and you know, for those, the, for the vendors, like they're a, people are consuming more of their cloud resources, but also a lot of them want you to move from one cloud provider to another. And we can help that because we can translate one language, you know, one infrastructures code that might be deployed in one provider to the next one. So we make that migration easier for companies who, you know, maybe they're wanna reduce their cost or maybe one provider's paying them to move there, Maybe, heaven forbid they want to go back to an on-premise environment because the workload changed, right?

Mm-Hmm. Yeah. Actually it is interesting that you brought it up, uh, because, uh, our recent, uh, support for OpenShift, uh, is to support that, those kinds of use cases that, um, there could be workloads, application workloads running without taking the name of any specific public cloud service providers in the managed Kubernetes service.

And if certain customers are enterprises, they want to bring it, bring those workloads, application workloads onto Kubernetes clusters, um, especially managed by OpenShift that they're running on-prem. That's the use case that we currently added the support For. And to your point, despite everything being open source, those configurations are not very portable unless I have some tool that runs back off the software rather than the developer.

I mean, loads of people talk about a multi-cloud and we wanna move from this cloud to this side, but the reality is it's hard. And so, you know, unless there's a compelling business reason, which we know, you know, the cloud providers all want that money, uh, so they might entice the company to move. Well then at that point, you know, people don't do migrations from cloud to cloud every day, but we just translate, you know, from one provider to another and it's, it's almost like a translation layer.

All right, we are coming up on 2025. What's next for you guys? We just keep building and keep selling.

You know, We are very happy with, uh, all the traction and the interest that we are getting. Uh, and the way actually we are thinking about it, one of the thing that instantly resonates in the very first meeting with any of the prospective customers, and we are targeting large enterprises, is the vision that we are carrying. You know, and as I laid it out and as Daniel just laid it out, that, uh, we are giving them an approach.

There are two distinct things. One is they can adopt stack Gen in a crawl, walk, run kind of approach. And we have built a platform that meets them where they exact they, they actually are today, which means we have the support for custom resources, bring your own terraform modules, bring your own helm charts, right?

Bring your own policies. So we are literally taking the platform to where they are and then slowly, metaphorically speaking, uh, we are handholding them and taking them to the promised land, right, which is infrastructure from code so that they don't ever have to worry about the Terraform files and hand charts going forward. All right.

Cool. Hey guys, thanks for stopping by. Thanks for Having us.

Good, thank you so much. Nice. Say if you can see your process, it's probably broken.

Infrastructure's code is probably broken. We'll be back in a minute, guys, and stay tuned for the next episode.