Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Speaker 1 (00:01):
Hey everybody, super
excited to dive into the world
of DevOps with a real innovatorand leader in the field,
xstackgen Asif.
How are you?
Speaker 2 (00:11):
I'm doing well.
Thanks for having me, Evan.
Speaker 1 (00:14):
Well, thanks for
joining, really intrigued by the
work you're doing at StackGen.
You created something called agenerative infrastructure
platform, which I'm excited tolearn about.
It's a new term of art for me.
Before that, maybe introduceyourself a little bit about your
journey in bio.
Really interesting story andwhat's the big idea behind
StackGen.
Speaker 2 (00:35):
Absolutely.
I'm Asif Awan.
I've been in the enterpriseproduct space for 30 plus years
building various differententerprise products and
solutions, out of which I'vespent over two decades building
security products.
This is my fourth startup.
The previous ones were in thesecurity space and also in the
(00:58):
machine learning ops space.
Finally, this one is in theDevOps space.
So what we are doing at StackGen 11 is, I find, it very
interesting and exciting.
We are taking a completelydifferent approach to addressing
the issues aroundinfrastructure as code.
There's a lot of time that thedevelopers spend trying to learn
(01:19):
and deal with infrastructure ascode, such as Terraform and
Helm.
Primarily, those are the twomost popular ones for the
workloads that get deployed inthe cloud, or for cloud-native
applications or the workloadsthat get deployed in the cloud
environments.
Then there is the other side ofthe DevOps engineers having to
(01:40):
deal with maintaining thetemplates.
So what we have done is that wehave come up with this, what we
refer to as the generativeinfrastructure as code, whereby,
in our solution, we make itabsolutely simple and easy for
the developers to not have toworry about infrastructure as
(02:02):
code I'll get into the detailsin a moment and for the DevOps
engineers, or the DevOps teamsand the platform engineering
teams, we provide a solution sothat they can easily maintain
the lifecycle of all of thesegenerated IEC through the Stack
Engine platform.
Speaker 1 (02:18):
That's a great
proposition, and cloud
development particularlymigration, multi-cloud is
famously painful.
So how do you help companiessupport this complex cloud
environment today without allthe usual headaches?
Speaker 2 (02:33):
Yeah, so that's the
beauty of generating the
infrastructure as code, right?
I mean so starting withunderstanding the intent of the
application or the applicationdeveloper.
Right, I'll give you a verysimple example.
Let's say I've written a cloudapplication, a container, native
Kubernetes, native cloudapplication, and that has
dependency on a few cloudplatform resources.
(02:58):
Let's take the example of AWS.
Right, I mean, my applicationcould be dependent on RDS, a
relational, as well as on astorage bucket, s3 storage
bucket.
Now, there are different ways ofunderstanding that intent.
Either you can understand thatintent directly from the code,
which is something that isreferred to as infrastructure,
from code, which Stack Gen alsosupports.
(03:19):
Directly from the code.
The developer doesn't even haveto explicitly mention anything.
What we do is we just gothrough, do the static code
analysis and then of theapplication code and the
corresponding configurationfiles, and we figure out that,
hey, there is a dependency onthese two resources.
These resources need to beprovisioned All the IAM roles,
(03:41):
everything, all the policies,everything needs to be created
and auto-generate theinfrastructure as code, which
are the Terraform files and thenthe corresponding Helm charts.
The other way to understand theintent is where the developer,
what we provide as the infracomposer or a canvas where the
developer can just drag and dropthe resources, connect them to
the compute module and justvisually, not having to do
(04:04):
anything or learn anything aboutthe Terraform code or the
infrastructure as code, just beable to generate the
infrastructure.
So when it is given these twospecific ways, it does not
matter where the application isgetting deployed.
It could be getting deployedsimultaneously in two or three
(04:26):
different Cloud environments, ifthe application is Cloud
resource agnostic, or it couldbe getting deployed in various
different regions within theCloud.
That is how we handle thiscomplexity of multi-Cloud
deployment.
We also support Cloud migrationwhich.
I'll get into the details of ina moment.
(04:46):
But from a developerperspective, from the DevOps
engineers who have to managethis infrastructure or the
deployment lifecycle of theapplication, they don't have to
worry about it because we areauto-generating all of that
infrastructure as code andmanaging the lifecycle of it
going forward.
Speaker 1 (05:03):
Very cool.
So the last couple of years, asyou know, it's been pretty
exciting around AI and agenticAI more recently, and it looks
like you're using AI to helpteams manage cloud
infrastructure more autonomously.
So how does that work?
What's happening, sort ofbehind the scenes?
Speaker 2 (05:20):
Yeah.
So let me start from the verytop right.
We are taking what I refer toas a two-step approach, right?
Or sort of a two-rule approachto using agentic AI for
generative infrastructure ascode.
For the users who do not haveany understanding of
(05:41):
infrastructure as code, I'llgive a very specific example.
Let's say I'm a softwaredeveloper who doesn't know
anything about Terraform, right?
So majority of solutions thatare out there, what they do is
they just say, hey, there's aco-pilot, it can generate
Terraform for you.
But how useful is thatgenerated Terraform for me?
(06:01):
Because I have to review it andmake sure that there aren't any
due to hallucinations or therearen't any mistakes, right?
And if I'm clueless aboutTerraform, that doesn't help me
at all.
So the approach number one thatwe have taken, or the rule
number one that we have followedin our platform, is that for
people who do not understandinfrastructure as code, we just
(06:22):
give them a very deterministicway, as I was explaining earlier
.
All you do is point us to thesource code, point us to the
Cloud for an existingapplication that has already
been deployed, or you can dragand drop visually and create the
deployment architecture.
You don't ever have to look ator review or verify that the
(06:43):
generated code is correct.
Right For the experts.
This answers your question moredirectly.
For the experts, such as DevOpsengineers, who are used to
writing, crafting andmaintaining Terraform templates
and so on, what we do is we givethem a generative, ai-based
approach where they can createcomplex Terraform modules.
(07:04):
I mean, we recently launchedsomething called a Terraform
module editor, using which theexpert DevOps engineers can just
go ahead create the Terraformcode, but just through prompts,
just quickly review it and thenbasically publish them as custom
modules that are available todevelopers, either through
(07:24):
policies that are enforcedgovernance policies that are
enforced or they're availablethrough the canvas for them to
track and draw.
That's the approach that we aretaking, a dual-pronged approach
where different than thetraditional copilot, where the
users are left to their means ortheir expertise.
(07:47):
But the key thing to rememberis that developers they just do
not want to deal with thisentire problem of having to work
with and having to learn andkeep up with various different
Terraform versions, how thedifferent resource
configurations work, and so onand so forth.
So we have made it very simplefor the developer while at the
same time, we empower the DevOpsteam to continue to create and
(08:11):
manage sophisticated Terraformmodules and templates, and so on
.
Speaker 1 (08:15):
That's fantastic.
You do talk a lot aboutimproving developer experience
across the board.
What's your philosophy aboutmaking life easier for
developers and what's theirfeedback been using the platform
?
Speaker 2 (08:28):
The feedback has been
fantastic.
Again, just to double click onthat, the approach that we have
taken in building the platformagain a dual-pronged approach
there as well.
The first thing is meet thedevelopers where they are.
That is number one.
And the second thing is andI'll get into giving a little
bit more details regarding whatI mean by that the second one is
(08:52):
basically, don't ask them tolearn anything that they do not
want to learn, which is make thedevelopers just do what they're
good at doing, which isbasically coding the application
or the business logic.
Right?
I mean, let them go back towriting or spending 100% of
their effort, whether usingCursor or Copilot or any of
(09:13):
these tools, for building thebusiness logic or coding the
business logic through theirapplications, right, be it in
Java, in Go, javascript,whatever language, right?
So the way we again, the way wedo the first part is meeting the
developers where they are isthrough integration with
internal developer platform orportal, such as Backstage.
(09:37):
We recently launched anintegration.
We are in the process ofactually launching that entire
integrated solution.
So if any large enterprise hasrolled out internal developer
portal, as a developer withinthat enterprise, I would not
even know the existence of aStack Gen.
Stack Gen would be enabling allof those capabilities that I've
(09:59):
been talking about throughBackstab, meaning I just go to
Backstab, I just pick up atemplate, I drag and drop
whatever.
I mean not drag and drop, but Iselect the resources that I
need for my application and,behind the scenes, stack Gen
will auto-generate the code andeven deploy the auto-generated
(10:21):
or the provisioned resources inthe environment, and the
developer can just start testingliterally in a few minutes.
Speaker 1 (10:29):
Brilliant.
And speaking of things,developers don't want to worry
about all the time.
You have lots of securityrequirements.
New compliance requirements areimportant to the business but,
you know, maybe not so much tothe developers.
How do you bake that into theinfrastructure automatically?
Speaker 2 (10:48):
Yeah, so that's a
very important point, right, I
mean.
So what we focus on going backto the previous point or your
previous question as well isenable the developers and
empower, while empowering theDevOps teams, right, so what it
means is and how do we empowerthere?
Also, we are focusing on theusability, because typically,
what happens without Stack Genin the picture, evan, that if
(11:12):
there is a DevOps engineer, theyhave to.
Not just, I mean they're usedto manually handcrafting or
whatever, even these days, usingcopilots or whatever right,
generating the Terraform.
I mean creating the Terraformcode and ensuring that the
Terraform code that they havewritten it complies with their
enterprises policies, whetherthey're compliance, security
(11:34):
policies, governance and so onand so forth.
Right, what we do is we ask, or,within Stack Gen Platform, all
they have to do is just go aheadand define or select that, hey,
these applications that Evan'steam is building, they need to
be HIPAA compliant or FedRAMPcompliant.
That is all they have to do.
(11:54):
They just have to select theframework and, based on that
framework that they haveselected and any other custom
framework that they haveselected and any other custom
policies that are defined, stackGen platform will automatically
and in a fully compliant way,enforce it on every application
that is being developed byEvan's team, and the reason I
give the example of the team isbecause you can go down in terms
(12:14):
of enforcement to that level ofgranularity within an
enterprise.
So it is completely different.
Rather than being reactive iswhat I'm trying to say.
Speaker 1 (12:24):
No, I love it.
Great, great opportunity.
Let's talk about your momentum.
You've been fundraising, whichis, you know, great to see in
this environment.
You're also on the GoogleMarketplace.
I'm sure you have otherpartnerships.
Talk about your growth andmarket momentum at the moment.
Speaker 2 (12:43):
Yeah, so this has
been a breakthrough year for us,
evan.
You know we have signed a lotof 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
(13:05):
continuing to build a lot ofcapabilities.
We are continuing to hire inengineering, but we have started
strengthening and hiring a lotof people in our go-to-market
team as well, in the marketingagain, account executives also
in the product team and my teamas well.
So, yeah, I mean overallfantastic growth.
It's been very exciting for us,you know.
(13:27):
And then we continue to lookforward and as a startup, right,
I mean you are neverfundraising or you're always
fundraising, right.
That's one of the things right,but really exciting times
looking forward to and I can'ttake the names of some of the
large prospective customers thatwe are working with, but very
(13:49):
exciting time.
This quarter and the nextquarter are going to be breakout
quarters for us.
Speaker 1 (13:56):
Amazing, Well done.
You mentioned some great bluechip customers and I'm sure
they're notoriously secretive,those kind of customers, but can
you talk about any of theresults they're seeing or how
they're using you to transformtheir infrastructure at the
moment?
Speaker 2 (14:12):
Correct.
So, without taking the specific, I mean the use cases that the
specific customers, for theright reason, as you mentioned,
right, that they are getting thebenefit from.
But there are three broad areasthat all of these customers are
finding Stack Gen to provide alot of value and address their
pain points right.
The first thing is theinfrastructure as code, what we
(14:34):
refer to as the transformation,right?
I'll give a very quick exampleof 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 cloudapplications that have been
deployed and running for quitesome time, right?
They must have been provisionedeither through custom scripts
(14:56):
or through ClickOps, through thecloud console or through some
Terraform scripts or IAC filesthat have not been maintained
over a period of time.
So the use case number one isthey point us to a cloud
environment.
We just do the entire cloudasset discovery and we
auto-generate the code for themand then we manage the entire
(15:17):
lifecycle of the code of IAC.
From then onwards.
They are finding a lot of valuein it.
The fact that we are showingthem the discovery, or that
giving the entire inventory ofall the Cloud resources, with
all their details, theinformation about their cross
dependencies and so on, in andof itself is very useful.
(15:38):
After that, the fact that weare able to auto-generate and
let them carve out variousdifferent Terraform templates or
code from that informationright, I mean the cloud asset
inventory information that weare providing, and do so
completely automatically, aswell as ensuring that, as we
were talking about a minute ago,all the policies governance
(15:58):
policies that need to be builtin is of a lot of use and from
then onwards, they'd never haveto worry about managing the
lifecycle of their Terraform.
That is use case number one,right, that very strong use case
that majority of our customersare finding value in.
The second one is what we referto as the module lifecycle
management, which is bringingyour existing Terraform
(16:21):
templates or you can create newones using our generative AI
assistant that we provide, likeI said, for expert DevOps
engineers.
Or the third one is, basically,they may have something that is
really old and they may want toedit it, so what we do is, once
they have been brought on toStack Gen, then we completely
(16:44):
manage the lifecycle of thosecustom Terraform modules.
In terms of managing theversions, in terms of ensuring
that, let's say, evan's team isusing the latest version of the
module, asif's team, because weare working on some of the
critical stuff they should notbe using the latest version, but
a version before that, so youcan get down to that level of
(17:05):
granularity in terms ofenforcing the governance and
compliance policy.
The third thing is what theindustry defines, evan, as the
IAC lifecycle management right.
So once the Terraform code isgenerated, obviously our initial
customers.
They started asking us thequestion lifecycle management,
right?
So once the Terraform code isgenerated obviously our initial
customers they started asking usthe question what next?
Right?
You have generated the code,but what does it even mean for
us, right?
I mean, we understand thatthere is a lot of value.
(17:27):
Then the very next thing isokay, execute the code, which
means you get into that entireIAC lifecycle management.
So we do your typical Terraformcommand runs, we do state
management, we do driftdetection the whole nine yards
right.
So we are completing the loop,starting from the left, going
all the way to the right in avery logical and very intuitive
(17:47):
way, while still focusing on theDevOps, keeping it simpler for
the developers, while giving allkinds of governance and
enforcement empowerment to theDevOps engineers.
Speaker 1 (17:59):
Fantastic Sounds
amazing, so I'm almost reluctant
to ask.
You have so much going on, butwhat's next?
What are you excited about overthe next 12 months?
And you must have quite aroadmap of capabilities you're
looking at.
Speaker 2 (18:15):
Absolutely so.
The vision, right from day one,or in fact, even before we
started, the company, has alwaysbeen the same, evan, which is
autonomous infrastructure.
Right, the North Star for us isthat, as a developer or anybody
who is responsible for creating, like I said earlier, right,
(18:38):
the business logic of anapplication, right, All they
have to do is just do that andnot ever have to worry about
managing the infrastructure.
Now, what does it mean?
What we refer to as autonomousinfrastructure?
Right, or you can call it, Imean to use the automobile term
right, I mean fully self-drivingor FSD, right, so we are sort
(18:59):
of getting there, right, I mean,and the ultimate end goal has
always been a fully autonomousinfrastructure.
Now, what does that mean?
It means that understanding theintent of the application and
the users of the application andwhen I say the users of the
application, that is where youget into SLAs, slos and so on
(19:19):
right, I mean, what is theobjectives?
What are the commitments thathave been made from a business
perspective?
Understanding that intent, thesecond thing is
self-provisioning infrastructurefor 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.
(19:39):
So, now that we have all ofthese building blocks, we are
doubling down.
In fact, now we have adedicated team that is working
on building that AI controlplane and the agentic AI
workflows based on all thevarious different ground-level
operators or the foundationaloperators that we have built, as
I was just talking about.
Speaker 1 (20:00):
Fantastic.
Well, what a great educationinto the future of generative
infrastructure, something I wasvery unfamiliar with.
Congratulations on all thesuccess, asif, onwards and
upwards, thank you so much.
Thanks everyone for listening,watching and, as always, sharing
.
Take care.
Speaker 2 (20:20):
Thank you.