What's Up with Tech?
Tech Transformation with Evan Kirstel: A podcast exploring the latest trends and innovations in the tech industry, and how businesses can leverage them for growth, diving into the world of B2B, discussing strategies, trends, and sharing insights from industry leaders!
With over three decades in telecom and IT, I've mastered the art of transforming social media into a dynamic platform for audience engagement, community building, and establishing thought leadership. My approach isn't about personal brand promotion but about delivering educational and informative content to cultivate a sustainable, long-term business presence. I am the leading content creator in areas like Enterprise AI, UCaaS, CPaaS, CCaaS, Cloud, Telecom, 5G and more!
What's Up with Tech?
Generative Infrastructure: How StackGen is Simplifying Cloud Development
Interested in being a guest? Email us at admin@evankirstel.com
The complexity of infrastructure as code has become a significant bottleneck in modern software development. Developers struggle with learning Terraform and Helm, while DevOps teams are weighed down by template maintenance and compliance requirements.
Enter StackGen's "generative infrastructure platform" – a revolutionary approach that's changing how teams handle cloud deployments. In this enlightening conversation, founder Asif Awan explains how their dual-focused solution meets developers where they are while empowering DevOps teams with better governance tools. The platform intelligently understands application intent either through code analysis or visual design, then automatically generates fully compliant infrastructure code without requiring developers to become infrastructure experts.
What makes StackGen particularly powerful is its approach to AI implementation. Rather than just offering code suggestions that still require expert review, it provides deterministic infrastructure generation for developers who don't understand Terraform while giving DevOps experts AI-assisted tools for crafting sophisticated modules. This two-pronged strategy has attracted major enterprise customers including NBA, Nielsen, SAP, and Autodesk who are using the platform for infrastructure transformation, module lifecycle management, and complete IaC governance.
The vision extends beyond simplification toward truly autonomous infrastructure – self-provisioning, self-healing, and self-adjusting based on application intent and business requirements. For teams struggling with cloud complexity, security integration, or multi-cloud strategies, StackGen offers a glimpse into a future where infrastructure truly manages itself. Check out their integration with developer portals like Backstage or try them through Google Marketplace to experience how development can flow without infrastructure friction.
More at https://linktr.ee/EvanKirstel
Hey everybody, super excited to dive into the world of DevOps with a real innovator and leader in the field, xstackgen Asif. How are you?
Speaker 2:I'm doing well. Thanks for having me, Evan.
Speaker 1:Well, thanks for joining, really intrigued by the work you're doing at StackGen. You created something called a generative infrastructure platform, which I'm excited to learn about. It's a new term of art for me. Before that, maybe introduce yourself a little bit about your journey in bio. Really interesting story and what's the big idea behind StackGen.
Speaker 2:Absolutely. I'm Asif Awan. I've been in the enterprise product space for 30 plus years building various different enterprise products and solutions, out of which I've spent over two decades building security products. This is my fourth startup. The previous ones were in the security space and also in the machine learning ops space. Finally, this one is in the DevOps space. So what we are doing at Stack Gen 11 is, I find, it very interesting and exciting. We are taking a completely different approach to addressing the issues around infrastructure as code. There's a lot of time that the developers spend trying to learn and deal with infrastructure as code, such as Terraform and Helm. Primarily, those are the two most popular ones for the workloads that get deployed in the cloud, or for cloud-native applications or the workloads that get deployed in the cloud environments.
Speaker 2:Then there is the other side of the DevOps engineers having to deal with maintaining the templates. So what we have done is that we have come up with this, what we refer to as the generative infrastructure as code, whereby, in our solution, we make it absolutely simple and easy for the developers to not have to worry about infrastructure as code I'll get into the details in a moment and for the DevOps engineers, or the DevOps teams and the platform engineering teams, we provide a solution so that they can easily maintain the lifecycle of all of these generated IEC through the Stack Engine platform.
Speaker 1:That's a great proposition, and cloud development particularly migration, multi-cloud is famously painful. So how do you help companies support this complex cloud environment today without all the usual headaches?
Speaker 2:Yeah, so that's the beauty of generating the infrastructure as code, right? I mean so starting with understanding the intent of the application or the application developer. Right, I'll give you a very simple example. Let's say I've written a cloud application, a container, native Kubernetes, native cloud application, and that has dependency on a few cloud platform resources. Let's take the example of AWS. Right, I mean, my application could be dependent on RDS, a relational, as well as on a storage bucket, s3 storage bucket.
Speaker 2:Now, there are different ways of understanding that intent. Either you can understand that intent directly from the code, which is something that is referred to as infrastructure, from code, which Stack Gen also supports. Directly from the code. The developer doesn't even have to explicitly mention anything. What we do is we just go through, do the static code analysis and then of the application code and the corresponding configuration files, and we figure out that, hey, there is a dependency on these two resources. These resources need to be provisioned All the IAM roles, everything, all the policies, everything needs to be created and auto-generate the infrastructure as code, which are the Terraform files and then the corresponding Helm charts.
Speaker 2:The other way to understand the intent is where the developer, what we provide as the infra composer or a canvas where the developer can just drag and drop the resources, connect them to the compute module and just visually, not having to do anything or learn anything about the Terraform code or the infrastructure as code, just be able to generate the infrastructure. So when it is given these two specific ways, it does not matter where the application is getting deployed. It could be getting deployed simultaneously in two or three different Cloud environments, if the application is Cloud resource agnostic, or it could be getting deployed in various different regions within the Cloud. That is how we handle this complexity of multi-Cloud deployment. We also support Cloud migration which.
Speaker 2:I'll get into the details of in a moment. But from a developer perspective, from the DevOps engineers who have to manage this infrastructure or the deployment lifecycle of the application, they don't have to worry about it because we are auto-generating all of that infrastructure as code and managing the lifecycle of it going forward.
Speaker 1:Very cool. So the last couple of years, as you know, it's been pretty exciting around AI and agentic AI more recently, and it looks like you're using AI to help teams manage cloud infrastructure more autonomously. So how does that work? What's happening, sort of behind the scenes?
Speaker 2:Yeah. So let me start from the very top right. We are taking what I refer to as a two-step approach, right? Or sort of a two-rule approach to using agentic AI for generative infrastructure as code. For the users who do not have any understanding of infrastructure as code, I'll give a very specific example.
Speaker 2:Let's say I'm a software developer who doesn't know anything about Terraform, right? So majority of solutions that are out there, what they do is they just say, hey, there's a co-pilot, it can generate Terraform for you. But how useful is that generated Terraform for me? Because I have to review it and make sure that there aren't any due to hallucinations or there aren't any mistakes, right? And if I'm clueless about Terraform, that doesn't help me at all.
Speaker 2:So the approach number one that we have taken, or the rule number one that we have followed in our platform, is that for people who do not understand infrastructure as code, we just give them a very deterministic way, as I was explaining earlier. All you do is point us to the source code, point us to the Cloud for an existing application that has already been deployed, or you can drag and drop visually and create the deployment architecture. You don't ever have to look at or review or verify that the generated code is correct. Right For the experts. This answers your question more directly.
Speaker 2:For the experts, such as DevOps engineers, who are used to writing, crafting and maintaining Terraform templates and so on, what we do is we give them a generative, ai-based approach where they can create complex Terraform modules.
Speaker 2:I mean, we recently launched something called a Terraform module editor, using which the expert DevOps engineers can just go ahead create the Terraform code, but just through prompts, just quickly review it and then basically publish them as custom modules that are available to developers, either through policies that are enforced governance policies that are enforced or they're available through the canvas for them to track and draw. That's the approach that we are taking, a dual-pronged approach where different than the traditional copilot, where the users are left to their means or their expertise. But the key thing to remember is that developers they just do not want to deal with this entire problem of having to work with and having to learn and keep up with various different Terraform versions, how the different resource configurations work, and so on and so forth. So we have made it very simple for the developer while at the same time, we empower the DevOps team to continue to create and manage sophisticated Terraform modules and templates, and so on.
Speaker 1:That's fantastic. You do talk a lot about improving developer experience across the board. What's your philosophy about making life easier for developers and what's their feedback been using the platform?
Speaker 2:The feedback has been fantastic. Again, just to double click on that, the approach that we have taken in building the platform again a dual-pronged approach there as well. The first thing is meet the developers where they are. That is number one. And the second thing is and I'll get into giving a little bit more details regarding what I mean by that the second one is basically, don't ask them to learn anything that they do not want to learn, which is make the developers just do what they're good at doing, which is basically coding the application or the business logic. Right? I mean, let them go back to writing or spending 100% of their effort, whether using Cursor or Copilot or any of these tools, for building the business logic or coding the business logic through their applications, right, be it in Java, in Go, javascript, whatever language, right?
Speaker 2:So the way we again, the way we do the first part is meeting the developers where they are is through integration with internal developer platform or portal, such as Backstage. We recently launched an integration. We are in the process of actually launching that entire integrated solution. So if any large enterprise has rolled out internal developer portal, as a developer within that enterprise, I would not even know the existence of a Stack Gen. Stack Gen would be enabling all of those capabilities that I've been talking about through Backstab, meaning I just go to Backstab, I just pick up a template, I drag and drop whatever. I mean not drag and drop, but I select the resources that I need for my application and, behind the scenes, stack Gen will auto-generate the code and even deploy the auto-generated or the provisioned resources in the environment, and the developer can just start testing literally in a few minutes.
Speaker 1:Brilliant. And speaking of things, developers don't want to worry about all the time. You have lots of security requirements. New compliance requirements are important to the business but, you know, maybe not so much to the developers. How do you bake that into the infrastructure automatically?
Speaker 2:Yeah, so that's a very important point, right, I mean. So what we focus on going back to the previous point or your previous question as well is enable the developers and empower, while empowering the DevOps teams, right, so what it means is and how do we empower there? Also, we are focusing on the usability, because typically, what happens without Stack Gen in the picture, evan, that if there is a DevOps engineer, they have to. Not just, I mean they're used to manually handcrafting or whatever, even these days, using copilots or whatever right, generating the Terraform. I mean creating the Terraform code and ensuring that the Terraform code that they have written it complies with their enterprises policies, whether they're compliance, security policies, governance and so on and so forth.
Speaker 2:Right, what we do is we ask, or, within Stack Gen Platform, all they have to do is just go ahead and define or select that, hey, these applications that Evan's team is building, they need to be HIPAA compliant or FedRAMP compliant. That is all they have to do. They just have to select the framework and, based on that framework that they have selected and any other custom framework that they have selected and any other custom policies that are defined, stack Gen platform will automatically and in a fully compliant way, enforce it on every application that is being developed by Evan's team, and the reason I give the example of the team is because you can go down in terms of enforcement to that level of granularity within an enterprise.
Speaker 2:So it is completely different. Rather than being reactive is what I'm trying to say.
Speaker 1:No, I love it. Great, great opportunity. Let's talk about your momentum. You've been fundraising, which is, you know, great to see in this environment. You're also on the Google Marketplace. I'm sure you have other partnerships. Talk about your growth and market momentum at the moment.
Speaker 2:Yeah, so this has been a breakthrough year for us, evan. You know we have signed a lot of big marquee enterprise customers NBA, nielsen, lexmark, sap, autodesk, just to name a few. We have a double team size, given the fact that we are continuing to build a lot of capabilities. We are continuing to hire in engineering, but we have started strengthening and hiring a lot of people in our go-to-market team as well, in the marketing again, account executives also in the product team and my team as well. So, yeah, I mean overall fantastic growth. It's been very exciting for us, you know. And then we continue to look forward and as a startup, right, I mean you are never fundraising or you're always fundraising, right.
Speaker 2:That's one of the things right, but really exciting times looking forward to and I can't take the names of some of the large prospective customers that we are working with, but very exciting time. This quarter and the next quarter are going to be breakout quarters for us.
Speaker 1:Amazing, Well done. You mentioned some great blue chip customers and I'm sure they're notoriously secretive, those kind of customers, but can you talk about any of the results they're seeing or how they're using you to transform their infrastructure at the moment?
Speaker 2:Correct. So, without taking the specific, I mean the use cases that the specific customers, for the right reason, as you mentioned, right, that they are getting the benefit from. But there are three broad areas that all of these customers are finding Stack Gen to provide a lot of value and address their pain points right. The first thing is the infrastructure as code, what we refer to as the transformation, right?
Speaker 2:I'll give a very quick example of the use case right that they are finding the value in. So they have these applications, pretty much all of these customers. They have these cloud applications that have been deployed and running for quite some time, right? They must have been provisioned either through custom scripts or through ClickOps, through the cloud console or through some Terraform scripts or IAC files that have not been maintained over a period of time. So the use case number one is they point us to a cloud environment. We just do the entire cloud asset discovery and we auto-generate the code for them and then we manage the entire lifecycle of the code of IAC. From then onwards. They are finding a lot of value in it. The fact that we are showing them the discovery, or that giving the entire inventory of all the Cloud resources, with all their details, the information about their cross dependencies and so on, in and of itself is very useful. After that, the fact that we are able to auto-generate and let them carve out various different Terraform templates or code from that information right, I mean the cloud asset inventory information that we are providing, and do so completely automatically, as well as ensuring that, as we were talking about a minute ago, all the policies governance policies that need to be built in is of a lot of use and from then onwards, they'd never have to worry about managing the lifecycle of their Terraform. That is use case number one, right, that very strong use case that majority of our customers are finding value in. The second one is what we refer to as the module lifecycle management, which is bringing your existing Terraform templates or you can create new ones using our generative AI assistant that we provide, like I said, for expert DevOps engineers. Or the third one is, basically, they may have something that is really old and they may want to edit it, so what we do is, once they have been brought on to Stack Gen, then we completely manage the lifecycle of those custom Terraform modules. In terms of managing the versions, in terms of ensuring that, let's say, evan's team is using the latest version of the module, asif's team, because we are working on some of the critical stuff they should not be using the latest version, but a version before that, so you can get down to that level of granularity in terms of enforcing the governance and compliance policy.
Speaker 2:The third thing is what the industry defines, evan, as the IAC lifecycle management right. So once the Terraform code is generated, obviously our initial customers. They started asking us the question lifecycle management, right? So once the Terraform code is generated obviously our initial customers they started asking us the question what next? Right? You have generated the code, but what does it even mean for us, right? I mean, we understand that there is a lot of value. Then the very next thing is okay, execute the code, which means you get into that entire IAC lifecycle management. So we do your typical Terraform command runs, we do state management, we do drift detection the whole nine yards right. So we are completing the loop, starting from the left, going all the way to the right in a very logical and very intuitive way, while still focusing on the DevOps, keeping it simpler for the developers, while giving all kinds of governance and enforcement empowerment to the DevOps engineers.
Speaker 1:Fantastic Sounds amazing, so I'm almost reluctant to ask. You have so much going on, but what's next? What are you excited about over the next 12 months? And you must have quite a roadmap of capabilities you're looking at.
Speaker 2:Absolutely so. The vision, right from day one, or in fact, even before we started, the company, has always been the same, evan, which is autonomous infrastructure. Right, the North Star for us is that, as a developer or anybody who is responsible for creating, like I said earlier, right, the business logic of an application, right, All they have to do is just do that and not ever have to worry about managing the infrastructure. Now, what does it mean? What we refer to as autonomous infrastructure? Right, or you can call it, I mean to use the automobile term right, I mean fully self-driving or FSD, right, so we are sort of getting there, right, I mean, and the ultimate end goal has always been a fully autonomous infrastructure.
Speaker 2:Now, what does that mean? It means that understanding the intent of the application and the users of the application and when I say the users of the application, that is where you get into SLAs, slos and so on right, I mean, what is the objectives? What are the commitments that have been made from a business perspective? Understanding that intent, the second thing is self-provisioning infrastructure for that application, self-healing if there are issues, it will be and self-adjusting, right, and with a feedback loop, right. So that is the vision. So, now that we have all of these building blocks, we are doubling down. In fact, now we have a dedicated team that is working on building that AI control plane and the agentic AI workflows based on all the various different ground-level operators or the foundational operators that we have built, as I was just talking about.
Speaker 1:Fantastic. Well, what a great education into the future of generative infrastructure, something I was very unfamiliar with. Congratulations on all the success, asif, onwards and upwards, thank you so much. Thanks everyone for listening, watching and, as always, sharing. Take care.
Speaker 2:Thank you.