Bridging Developers and DevOps: Unifying Teams with IfC (Infrastructure from Code) | DevOps Experience 2024

Hi everyone, and welcome to today's webinar on Bridging Developers and DevOps, unifying teams with Infrastructure from code. My name is Lauren and I'm the VP of product here at Stack Chat. Thank you so much for joining us.

Um, over the next 30 minutes, my coworker Caesar and I are going to explore how infrastructure from code or IFC, we might refer to it that way, can help bridge the gap between development operations, ultimately improving collaboration and deployment velocity. Hey, Lauren. Um, I need some help.

I have a, an app that I need to deploy. My boss really wants this today for a marketing push. Um, we're doing a marketing promotion for, for kittens, and he wants it like right away.

I have a deadline, so please help me deploy this because, um, it needs to go in right away. Oh, uh, wow. Yeah.

Okay. Uh, cool. I totally hear that.

Um, it's like 5:00 PM though. Uh, and we're working through some production maintenance. I, we think we could set an email about it last week.

Uh, it's gonna be ongoing for a couple of hours. I don't know that we're gonna get to this tonight. I am sorry, man.

This is, this is always a problem with you guys. Obstacles. I, I'm tired of this to be honest.

I'm gonna have to escalate because it's always the same thing. It's always the same thing with you. Yeah, no, yeah, I, yeah, I really understand.

But I, we're, we're literally right in the middle of this update. It's, it's definitely gonna take at least an hour, and that's assuming that nothing goes wrong or, and unexpected stuff doesn't pop up. So the absolute earliest I can get your app out is gonna be after 8:00 PM You know what?

Just, just let me have the access. I, I'll do it myself. How hard could it be?

Okay. Yeah. Uh, do you know how to write Terraform?

I can GPT yet? That's gonna be easy. Did that sound familiar to you?

It probably, it's something that we've both heard a lot and also experience, as I said before, hello, I am Lauren, VP of product at Stack Gen and not a DevOps professional. I'm Cesar, uh, VP of engineering at Stack Gen And not an ENC calcitrant developer, right? All right.

So in the scenario that Cesar and I just played out, you see the divine that can occur between devs and DevOps teams. Um, often our companies incentivize these teams totally differently, right? I was incentivized to keep our systems up to date secure and to communicate out my timelines, but stick to them once they're in motion.

Whereas Caesar was in set of eyes to push out updates and new features as quickly as possible to demonstrate user value, right? But intermixed with our different motivations was also our interdependencies. Caesar needs my knowledge to help deploy his app and I maintain the infrastructure so his app can be out in the world.

And the thing is that developers wanna go as fast as possible once a feature is released. If it's all good from a QA security and governance perspective, uh, they want it available for the customers to use and they want the process to release to be as frictionless as possible. Uh, we don't wanna seek our doubles, see our doubles folks, um, unless it's an emergency and we really, really need their help, then we call them.

Uh, years ago in a previous role as a security architect in my organization, we tried to implement Golden Path for modules. So the developers that fit into a cookie cutter infrastructure architecture could release as fast as possible, and that worked well. But for the development teams that didn't fit into those architectural patterns, patterns, it was a huge pain.

We had necessarily added additional overhead and hindered their innovation and ability to quickly adopt new technologies, which is not good. No, and we need each other, right? But we have to find a path forward that meets both of our needs and the incentives that our company sets for us.

So ideally there would be an approach that leverages both of our strengths and makes up for the places where we don't have as much context. So one of the ways we're trying to solve this divide is with something called infrastructure from code. Uh, so Lauren, what's infrastructure from code?

I am so glad that you asked. Caesar infrastructure from code uses Caesar's application as the starting point figuring out what infrastructure is required to successfully run Caesar's app and generating the IAC to fit the needs of that app. And because it's coming from that app code first, infrastructure from code will always create least privileged and minimum viable infrastructure from the start without requiring Caesar to know what permissions to set or what resources to provision in what order.

And that's a game changer for bridging development and operations. So IFC helps you break down your silos. So as a developer with IFC, I'm focused on my business requirements using the best technology to solve the problems I have at hand, while being empowered to own the revisioning of my infrastructure dependencies without having the cognitive load of learning how to properly configure and operate those infrastructure resources.

From an ops teams and platform team perspective, uh, they can focus on implementing the standards and organizational requirements without having to chase down individual blueprints or templates for each new technology or to be a bottleneck for the development teams. While trusting that any security and operational guardrails are gonna be included by default on the generated infrastructure as code and it's context aware with IFC, your generated infrastructure S code is always least privilege. It's aware of the context and only includes the resources that your application is actually using.

And this is huge. As I mentioned, um, my background in security architecture, one of the things that I was in charge as part of my role was managing A-W-S-I-M roles for the enterprise and the processes around it. How it worked was that a development team came to the cloud operations team with their architecture diagram at the beginning of their project, and the CloudOps team used that information to create least privilege I roles for that point in time.

What ended up happening was that development teams didn't come back as their application evolve to pair down their privileges from what they originally envisioned as they of wanted to avoid the friction of dealing with another team and being in another meeting. So this caused a lot of applications to be unnecessarily overprivileged, which is a huge pain to fix once applications are in production. Very true.

So let's talk a little bit about what the infrastructure from code approaches are, right? Infrastructure from code is a whole movement and there are a lot of different approaches that you can take. Um, some infrastructure from code tools have SDKs, which Cesar would plug into his apps code base and then when he wanted to deploy would generate the infrastructure from that code base.

Um, this requires some work on Cesar's part to ensure he's using the SDK correctly and that his code fits within the SDK's framework. There's also an IFC programming language. Um, there's a couple of those out there.

So Cesar could write his app from the start in a language built to generate infrastructure once the app is complete. Um, this is a bit of a heavier lift for Cesar who would need to learn a new language and then use it to write his app. And that may or may not be possible depending on the rules at our company, right?

And how far along in the development process Caesar is, what he learns about best option. Um, and then there's static code analysis and that takes existing code and analyzes it to determine what infrastructure is needed for that code to be deployed. Let's talk a little bit about how that fits in the pipeline.

So it's Dian, we believe that infrastructure from codes should fit at the intersection of DevOps within your code artifacts and your CI ICD pipelines and workflow. So on the left we start with the application source code and configuration files. This will be now the source of truth of your infrastructure architecture.

Your operations and platform teams will configure your IFC tooling with the standards and best practices that they will like to enforce. And once a developer is ready with their code, they can trigger the IFC tool to scan, do static code analysis on the source code and generate the corresponding infrastructure from code as helm charts and Terraform, which can then flow back into your repo or your artifact store and flow into your existing CICD workflow. So with Stack Gen, your developer can ship code, it will generate the IC and move it to your existing CIC pipeline with a streamline process that's aligned and context aware.

Very nice. And what happens with the deployment? So here, here's, here are the impacts that implementing IFC will have for you on your team.

So first is streamline. Removing infrastructure provisioning requirements from developers helps speed up the new features and application deployments and it keeps your business and customers happy, which is what we all want. Developers are more efficient, they're able to easily manage infrastructure and focus on your development.

Your operations team is gonna be more productive and focus on eliminating any toil instead of being a bottleneck for your dev teams. And you have standards built into the application deployment process. It's not scan after the fact.

Your cloud is secured by default without a security team involvement and slowing down the deployment. Yeah, absolutely. So that's why we created generative infrastructure from code, right?

Using Stack Gen and Simple Command Infrastructure as code is autogenerated based on the application code with no code changes required and it's right sized with least privilege access controls. But how does that happen, right? We've kind of talked about it, we've talked about where it fits in the workflow, but like how exactly does act make that happen?

I'm gonna take you through a quick tour of what we do before Cesar shows you how we do it. First, we analyze your code. We currently support Python and Java with more languages coming soon based on our analysis.

We understand your required infrastructure cloud dependencies, and then infer things like API service configuration and more. And then we visualize, we create a visualization of your deployment architecture if needed. You can drag and drop resources to enhance that architecture.

And by design we offer built-in guardrails and notify you if a connection that you're drag dropping can't actually be made because that's not possible. Or if you added a resource that's against a policy or best practice, no one secured S3 buckets here and no trying to create something in AWS that is physically impossible as I have tried to do in Terraform several times. And then once you have your architecture all set, we go ahead and generate your Terraform or health charts or both, and those files already have all of your golden standards baked in these privilege access controls, AWS or Azure policies, any compliance policies like SOC two, hipaa, PCI, et cetera, it's all there for you.

Okay, Caesar, how about instead of chat GPT, uh, which which might not grasp the nuances of Terraform and kind of needs you to know what everything you'd need in order to deploy, uh, and can maybe hallucinate a little bit, which might not be great. Uh, why don't you trace gen? Okay, let's give it a shot.

So here's my repository. It's called Hello Kitty. This is a Python, simple Python Lambo serverless based application.

Let me try and create my app stack and onboard my repo in this stack gen. I wanna do this from the source code directly using IFC. So let me search for my organization, which is under my name and the repo is Hello qd.

So this is a single service repository, only one component is the Hello KD app and it's on the main path and Python for my compute environment. I'm gonna select Alys Lamba. And I already see that sneaky Lawrence sneak in all of her policies into my configuration here.

She's implementing CIS benchmarks, HIPAA ISO, NIST duct two PCI will Architective framework and everything is included by the vault. Thanks Lauren. Now I don't have to think about that stuff.

I'll proceed. I'll name this hello kit and I'll create my app stack. So under the hood, once I create my app stack stack in will call the repository.

It performs static code analysis to infer what are the infrastructure dependencies for your application, and then shows you an architectural diagram of the things that found and allows you to make any updates on things that are not directly your solar code. So for example, in the case of this Lambda function, I have a images bucket environment variable that my application expects. And I also have a bucket name that I have to pre-populate for my infrastructure itself.

So I'll name this deck gen below 80 user demo, and I'll put that on my environment variable as well. And I'll save my changes. The next step here is I need to do a few configuration changes here for my Lambda function to make sure that it takes into account my how I do build for my Lambda.

So first thing here for the code configuration, I have an S3 bucket called Stack demo builds where my code is pushed for on my CICD pipeline and it's being pushed specifically to this, um, path within the, within the bucket. The next thing is that I want to have a function URL so that I can access my lamb function. The cool thing is if I have to add any additional resources, I can always drag and drop if stack.

If I, I'm not specifically, um, invoking any resources within the code base and stack in didn't detect it, I can always drag and drop that. Um, I can connect that to my limit of function to give it access. And there we go.

The other benefit of static code analysis, like uh, Lauren mentioned is that I get least privileged by default. For example, if I click this block within the, uh, between my Lambda function and the Esther bucket, my generated I am policy grants, me access to boot object list object, get object and get object version. And the reason I'm getting, uh, those permissions is because the tool detected directly that those are the permissions.

Those are the API calls that my application is making. So it's least privileged by default. And if a developer like me is trying to be sneaky and bypass some of your requirements, let's try to save block public access on this actually bucket walls.

If I save that, it'll trigger a policy violation and will, while there are any policy violations in place, I'm not able to export my IAC or push it to my GitHub repository. I'll have to follow the remediation instructions here on fixing the violation before I move forward. So I'll fix that policy violation and I'll delete that with the basis I'm not actually using that.

So everything that you see on the canvas is backed by terra form files that are automatically generated based on your infrastructure architecture from your application if you wanna see these files. So you can roster them through the ui. But the next step for me as a developer is to push these files into my GitHub repository.

So I pre-configured my located repository here. It was my infra path. So I'm gonna go and push to GitHub where the system is gonna create a pull request.

So I'm gonna go ahead and view my PR well. All right, so now I can see that stack created this pull request. It has all of the necessary changes for my terraform, for my infrastructure codified as Terraform.

And, uh, my, our repository already has a pipeline that uses GitHub actions, uh, to do a Terraform plan and apply to provision the infrastructure resources. So let's give it a minute while the GitHub action loads. So now my GitHub, uh, action executed.

It performed a Terraform plan and it commented with the Terraform app plan output into the port request. So we can see what resources are getting added here. So, um, setting 12 resources for my, for my, um, infrastructure.

So I'm gonna go ahead and merge the request of delete this branch, which is no longer needed. And if I go back to my actions, I'll see this infra apply, which is, um, running with my, um, merge code to do a terraform applied on the infrastructure scope changes. Once this is applied, we'll see an output with the URL for my land of function.

Let's give it a minute while Terraform executes, terraform apply. And finally, if we click here, my application is out and running. Hello kitty.

My random kitten image generator. Perfect. Amazing.

And then we have, you know, our kitten marketing push all out the door without any maintenance interrupted. Well, thanks so much for joining us. Everyone.

com or go check out our white paper. com. We love hearing from you.

Thanks so much. Thank you.