 Hello and welcome to our on-demand CNCF webinar on adopting infrastructure from code. So we are here to talk to you about challenges with infrastructure as code and why infrastructure from code is needed. So first up to introduce who we have here today My name is Danielle Cook. I am a CNCF ambassador and also a VP at AppCD. And I'd like to have my co-presenters introduce themselves. Asif, over to you first. Sure. I'm Asif Owan. I'm one of the co-founders and chief product officers at officer at AppCD. And Lauren. Yeah, I'm Lauren Rother and I'm the VP of product here at AppCD. Awesome. Well, let's jump right into this. So we are going to present to all of you first seven challenges that exist with infrastructure as code. And we want to go back and forth on this and give you some context because we all know that infrastructure as code is widely used throughout the cloud native space. We are sure that you're going to relate to some of these challenges if not all of them. So let's jump right in with the first one around a learning curve. So this one I'm going to throw over to you, Lauren. So talk to us a little bit about the learning curve. Yeah, for sure. So infrastructure as code often requires mastering new tools, right? And especially when you think about infrastructure as code, we often think of in the cloud, but actually also applies to on-prem things. And so you are mastering tools for all of what you're using and that and whatever frameworks they come with. So you're looking at things like Terraform, Helm, Ansible, Chef, Puppet, etc. There's even more than that. We're not going to list them all. That would be boring. So the learning curve can obviously be kind of steep and especially for teams that are accustomed to doing things manually or via a series of scripts or doing things in a console for a cloud provider. And I think hardest of all, most infrastructure as code tools, especially now use declarative languages to define and support infrastructure and resource management. And specifically that means defining what is needed and not how it gets built. And that shift can be really difficult for teams who are used to programming languages, which tend to be imperative. And I know this has been a struggle since even my time at Puppet. So 10 years ago, it makes a lot of sense on that one. So keeping moving on, let's talk about number two, which is tool proliferation, which is obviously something that is not unique to infrastructure as code, but it's something that is everywhere and widespread. But let's talk specifically about infrastructure as code. So Asif, you want to answer this one? Absolutely. So just like Lauren mentioned, there are so many tools that over a period of time, mostly in the past 10 years have been built for specific purposes. And the configuration that any of these tools provide, they resonate with a particular audience. So what I mean by audiences, developers like Lauren said, as an example, Chef uses imperative language. So it's much easier for developers who are used to using imperative languages, which most of the developers do, they can relate to it and they can ramp up very quickly. So it's not that big of a deal. Whereas in case of Puppet, as well as with Terraform, they use declarative languages. So it's not that intuitive for the people or the developers with their kind of background to be able to start using those tools. So the problem with over a period of time, what happens is that in larger enterprises, all these expertise silos that start getting created, and then your workflows or pipelines start reflecting those silos. So there are a lot of tools that need, and which causes fragmentation and knowledge and fragmentation and approaches. So that is something that has turned out to be in the past 10 years or so. As I said, based on at least my experience of working at larger enterprises, as well as interacting with people who work at large enterprises, that seems to be a big challenge. How do they pick the right tools? That makes a lot of sense. And I know something, I've written alongside a working group, I'm part of the cloud native maturity model. And we talk a lot about you are going to have lots of different tools that come into the organization. And as you become more mature, you're going to have to choose what's right for you. So I think this talks a lot about that. IAC isn't necessarily the first thing you use, but it's definitely something that becomes all over the place. And then you need to be smart about it. Okay. So moving on, next up, the third challenge is around cloud complexity. Lauren, go over to you. Yeah. Yay. So lots of tools, lots of choices. But no matter what you pick, no infrastructure as code tool removes the need for you to know, at least on some level, how to create and manage infrastructure components and what those components are, how to provision and configure the services and resources around those components, how they connect to each other, the order of operation that you have to call them in, who among us has not built a config and then realize they put things in out of order and then it can't be built and they have to tear it all down and write the config again, because I've definitely done that. And then on top of all that, you're keeping up with changes in the configuration that you're making and the resources that the tools you're using offer to you. That's a lot to ask of someone. So like, let's think about AWS, right? Like AWS has what, 200 some-odd services and like 800 different resource types. I am pretending like I knew that number off the top of my head. I did not. Daniel helped me with that. So if you're thinking about it, like you have these public cloud service providers, let's say you only use one cool, that's still a lot of things to know. But what if you're trying to get into multi-cloud, now you have to know AWS and Azure and GCP, et cetera. And all of these service providers introduce new services, right? And new resources that offer faster and sometimes cheaper ways for you to perform the same business task. And now you're shifting and having to grow your knowledge. And none of this is your, if you're a developer, this isn't your daytime job, right? Like knowing the cloud is not your job. Your job is building applications and other things. So then add all of that onto all of the third party and open source services that your app is relying on in the cloud that also has to be considered when you're building this infrastructure. And that is a lot to ask anybody to know and hold in their head at all times, let alone to build a config out of it. Well, and we know as an industry, we're talking a lot about cognitive load. It's just like a perfect example of I need to remember all of these things. I just have to remember it. And it's a lot for people. So, all right. Moving on to number four, which is around version controlling. So ask that over to you. Yeah, absolutely. So coming from services being monoliths, right? And over a period of time, containerization has helped us develop applications into microservices using microservices based architecture. All of that is nice and handy. But the problem is that each of these services could be owned and developed by a different development team, right? And obviously, each of these services could have its own configuration. So you're talking about various different life cycles of the services that need to be managed and across various different versions and their corresponding configurations and act to that the complexity of each of these services being tested and deployed and various combinations of these services being deployed as an application in different environments, which is why having a streamlined, well understood process and automated pipelines to handle these various different versions so that at any given time, let's just say that you have an application which comprises various different versions of microservices. And if there is an issue, you should be able to right away be able to duplicate that issue or spin up that particular combination with the exact configuration in a new environment. So it's a fairly complex thing. I try to explain it with some simple examples. And that is one of the challenges, like I said earlier, that large enterprises, especially with that have teams that are responsible for different microservices or the development and release of different microservices are constantly based. Yeah, that makes total sense. I mean, version control is obviously something that if you're not keeping up to date, opens you up to security issues. It opens you up to reliability issues, like all of these things that can really hurt an organization and hinder their ability to meet their business goals. So moving on to the next one, it is around drift management. Lauren, back to you. Oh, yeah. So I think maybe with the exception of declarative, a lot of these are issues that kind of happen around infrastructure as code, right? I think they might have happened regardless of whether infrastructure as code is there. This is one that's hard, because it's like, I love infrastructure as code. And this is a problem that infrastructure as code gave us. It's a fun little gift. We all have these things, right? So you have this configuration, and this determines what your infrastructure is. But then how do you detect and track and then remediate drift from that configuration? Because configuration drift happens all the time, right? When engineers of any stripe, whether they're application, platform security, make changes to your platform resources directly, either in the cloud environments via consoles, and they don't use your infrastructure as code, there's like, how do you figure that out? How do you then fix your configuration to match that? And there's usually like a very good reason someone's doing this. I think it's very... I won't ever really get a comment about this. I'm sure that sometimes it's just that someone doesn't want to, but a lot of times you think about it like someone asks you for a really quick change, and they are very high up. You're in the middle of an incident management, and you just have to fix something because you cannot leave your service down. Doing that through IAC is really hard. And unless you have a really robust incident management team that is used to kind of following through full best practices, it's easy to forget to make that change in IAC. And so how then do you find it? And then you have to probably get a tool, because unfortunately, I think a lot of the IAC tools like try to do it, but none are doing it particularly well. It's a really hard problem to solve. And then you're relying on one to try to find it. And that means whether you're building that tool in-house or buying something, you're reverse engineering the creation of your IAC files from the environment state management files. So you've got your environment that is deployed in real life. You're trying to reverse engineer what the IAC would be and then compare it to the one that it was supposed to be, but is not. And now you have to remediate that. And maybe some of you are crunching because there are certain IAC tools where remediation means tearing something down and putting it back. And that is a life none of us want. That can be very hard. So now you're also in a how do I begin to do this in a way that doesn't actually like destroy anything? Really, really hard changes. And that's assuming that everyone who's in charge of the IAC code agrees with all the changes that got made and want it to be there. And you don't have to have several meetings to make sure everyone is good with it. Well, and as you said, if there's an incident, if you put it in, you don't have time to do all that. So yeah. All right. So two more to go. So we're moving on to the sixth one, which is around security, which is always an issue with every technology out. It just is. So Asif, let's talk about security. Yes, absolutely. There are, I mean, there are a lot of security related concerns when you're introducing a new tool, a new approach. Which like Lauren mentioned, IAC offers an automated way for provisioning resources, for provisioning infrastructure components. But when you're defining how the resources need to be provisioned, one of the key things is that you have to also define how you are going to access those resources in first place or get to those resources, which means that in most of the IAC, if you're not careful, you would end up including those credentials, those account credentials, and secrets. So the first point is that the awareness of being able to handle or how to handle those credentials and those secrets in the infrastructure as code files or those configuration files, that becomes very important. So it's between that somebody has to review it and ensure that those credentials are not included in these files because infrastructure as code, code being the keyword there, is eventually going to get checked in to a version control system, which obviously if you have included the secrets, then anybody can see those secrets, even the ones who should not be having access to those accounts. The second big challenge is that of provisioning the privileges, I mean provisioning the resources that are, I mean provisioning enough resources that are required by the application. So not over provisioning of resources. So the obvious thought that comes or goes with the over provisioning is that of cost. But when you're over provisioning resources, the issue is also of access. And especially when you have, as I mentioned earlier, this kind of a microservices based application or microservices architecture based application, you have to be a lot more careful from the perspective of what kind of resources are being provisioned and accessible to each of these microservices. Because in the context of microservice, in the context of application A, needs to have certain kind of access to a resource. In the context of another application, it needs to have different kind of access to a particular platform resource. The third, so it's basically enforcing zero trust. The third key point is that of along the similar lines, ensuring that after you have given access to an application or a microservice that is part of an application to a platform resource, the privileges are not over provision. I like to give this example that if a particular microservice or an application needs to have just a read only access to an AWS S3 bucket, right? Then if you're not careful and if you end up over provisioning and give it read write access, basically the application, if it gets compromised or misconfigured or due to some bugs can end up making the changes in the S3 bucket that you would not want it to make. So those are some of the things to definitely keep in mind. Well, and there's a human error or element in this, right? So humans, unfortunately, we're all not perfect. So everything you talked about requires a level of human involvement, which can, again, open you up to some security risk, which is not ideal. All right. Moving on to our seventh challenge. It's all around enterprise governance. So as if I'm going back to you on this one. Absolutely. So when you introduce new tools, obviously, there needs to be new set of policies that are that needs to be defined in the context of each of these tools. And what is it that they are allowed to do? So what that means is specifically going back to what I was talking about just a moment ago regarding the security related compliance and the policies that need to be applied. What that means is now specific to the tool, there needs to be a call it a roadblock, call it a gateway, call it a check that needs to be introduced so that when these IACs are created to ensure that there aren't any secrets that have been included in the IAC. So many times what happens is that even though the pipelines that have been created for including the checks before the provision actually happens in any of the environments, those are automated, but the review process is still manual. So what that means is as a developer as an example, if I have gone ahead and created my own infrastructure as code from scratch, and I thought that I have complied with the policies while writing the infrastructure as code and then as part of the automated pipeline, if there was a scanning IAC scanning tool as an example, TerraScan, this is a very popular OpenScore project. So if that is used and it flags certain alerts, what that means is that that IAC file that I handcrafted is going to come back to me. And I need to fix it. And which means that I need to have an offline communication and understanding as to why what I thought was right has been bounced back to me. So that could lead to a lot of iterations and hence the delay in eventually deploying the application because as a developer all I want is to write the business logic, deploy the application as quickly as possible. So that is something that needs to be, so what I'm trying to say just to tie everything together is that new tools leads to new pipeline, but from a security compliance and governance at scale, if you want to have the consistency across enterprises, across various different teams, then you need to be careful about the kind of process that you're putting in place with the realization that some of these processes could lead to multiple turnarounds, going back and forth with the developers and the DevSecOps team and eventually leading to a delay in the deployment of those applications. Well, and we know with everything, time is of the essence. People need to get everything to applications to market, new features, new functionality, so speed is important. So we have given you seven challenges, but we're not going to leave you with that. We're going to actually talk about how you solve these challenges because, you know, want to bring problems, we want to bring solutions. So there are three main challenges that were, sorry, three main ways to solve these challenges that we mentioned. The first is golden templates followed by options of new programming languages and then infrastructure from code. So we're going to talk through a few of these and we're going to talk through the pros and cons of each, starting with golden templates. So Lauren, you have created lots of templates. So let's talk about some of these and we're going to start with cons first and then go for pros. So, you know, we're going to flip it a little bit. So first let's talk about the cons. Yeah, of course, we love to end on a positive note, right? So just keeping everything, keeping everything on the up. Yeah, so I, having worked at Terraform did actually work a lot on templatizing and how does that work? And golden templates are great, right? They, they save us a lot of time, but they save us time by being really tied to a specific point in time at which they were created. And then they tend to go out of date, depending on what environment therefore that can, or application therefore, that can be very quickly, that can happen very quickly and updating them. Well, if anyone who is here or watching has built software, you know how getting anyone to update anything is very hard. So they also encourage copying and pasting, which is kind of a pro and a con weirdly like, yay, copying and pasting saves you some time, but copying and pasting is prone to a lot of errors because it's a template that person doesn't necessarily have, if it copied wrong or something happened, they're not going to know, right? Like until it doesn't build, they're not going to have the wherewithal to be able to read through that. And that's difficult. Also, when you're copying and pasting answers, that can get strange, right? You don't necessarily know what goes in there. So that's a challenge, too. And it takes a lot of time to make changes to golden templates, right? How do you know what version is employed in place for what application with what team at one time, you have to have a single source of truth from that. A lot of templates are like built in storage or maybe VCS, but like cool, you know where the template version is, but you don't know where it got deployed, that's going to require some fun scraping of your VCS. We all know how great that is. Sure, we've all done that too. So yeah, keeping them up to date, knowing who's deployed them and when and then getting them updated is just a big challenge. That's it. They do save you a lot of time, right? Someone doesn't have to write something from scratch. That is always a win. It's much easier to get started with a fill in the blank than it is a literal blank entirely. It also helps give your developers a step in the right direction, right? They know what order things are in. So that whole problem of like, I have to understand what order components need to be called in already there for you. And you don't have to worry as much about you can inject some nice environment variable stuff, and then no one has to mess with it. They don't have to learn. So that's nice too. Templates. Awesome. Yeah, templates. And I know there's a lot of talk about golden templates and the golden pathway. We like to talk about golden standards, but we will get to that. So Asif, let's talk about new programming languages. And first, let's talk about the cons of this. Okay. So as with any new programming language, when you're introducing a new language or a new way of doing things, there's always going to be a new way of doing things with any new language, even though it falls under, as we talked about earlier, under the category of being imperative or being a declarative language, right? But whoever needs to start using that language, A, they have to learn, B, still, it doesn't take them, take them away from the fact that they still need to understand the underlying infrastructure, the platform resources, how they need to be configured and so on. The third con, if you can call it that, is that it typically or very easily works for new applications, greenfield applications. But how about your existing applications, right? I mean, you go back and you could have existing deployment files, do you throw them away? Do you pick some of those aspects, some of those pieces from there? How do you migrate onto this from the old land to the new land, so to speak, right? So those are some of the cons that need to, and I like to give this example in the context of some new programming languages is that before Java became popular, there were like, at least tens of languages that came about that were not successful, right? I mean, not as successful as Java. So those are some of the challenges or the negatives of adopting a new language. The positive, of course, is that the developers in these days, as an example, AWS CDK, right? They allow the infrastructure to be codified or provisioned using existing languages that the developers are already aware of. But like I said, the challenge is that it's not just about learning a new language, but the thing that goes with it is that it does not take away the fact that the expertise or the knowledge of understanding the infrastructure and the platform resource attributes or each of the resource attributes and how they need to be configured, that doesn't go away. So that still remains. Awesome. So now we're going to go on to the last one, which is infrastructure from code. So first, we're going to define this for you. So Asif, do you want to talk to me about what infrastructure from code is? Yeah. So as the term suggests, right, infrastructure from code is actually inferring infrastructure directly from the application code itself. So basically, take the application code as the foundation and use that foundation or that infer deployment needs of the application to auto-generate the infrastructure-related configuration. And when you're auto-generating anything, as in this particular case, you can have the security-related, compliance-related, best practices-related, design-related policies already be taken into account. And hence, the infrastructure that is generated from this, from treating the application code as the foundation, that could be used without having to worry about the challenges that we were talking about earlier from a security perspective, from a compliance and governance perspective, and so on. Now, do you make sure we're balanced here? Let's talk about a few cons about infrastructure from code. Yeah. So one of the challenges to be very fair and honest about infrastructure from code is that since the infrastructure, the deployment-related needs are inferred from the application code without making any changes to the application code, what that means is now that solution, that IFC solution, has to have the ability to be able to understand the application that is written in various different programming languages. Okay. That is dimension number one. The second dimension in terms of scope is being able to generate the infrastructure as code specification for the target cloud. So it is not a challenge with respect to the approach, but it is a challenge in terms of what needs to be covered as part of the scope, because there are quite a few popular languages on one end, and then at least on the other end, there are pre-main target cloud service providers to deal with. Well, and you know, for somebody who writes a lot of IAC, you might be thinking like, what could it do everything? Like, would it really see everything? And I think, you know, that's where you're going to try it to see. But let's talk about some of the pros of infrastructure from code. So Lauren, we have a few animated options here. So Lauren, let's talk about how infrastructure from code helps you get streamlined. Yeah. So infrastructure from code, because it's pulling from your application, streamlines the application cloud deployment, right? Because it keeps it aligned and it allows developers to kind of stay in the flow and the tools that they use, which is a better overall and more productive experience. And they don't have to know things about infrastructure because the infrastructure is assumed from what they already knew, which was the application code. And this, you know, anytime you accelerate time to market, you accelerate your ability to meet customer demands and needs. And then with improved developer experience, things get done quicker. That's time is money, generally more profitable, right? Also, who doesn't love automation? Like, the whole reason you're probably watching this webinar is because you're at least somewhat invested in automation. It's been a big talking point for a lot of years. This infrastructure from code allows DevOps to kind of do what it originally wanted to do, right? Which is provide developers with an automated solution for deploying applications correctly. And then you don't have to create knowledge silos because you get to utilize the knowledge that you have without having to try to build strange bridges across them. It's already there for you. Well, and then that kind of leads a segue into standardization by default. Yeah. So when you're generating infrastructure as code, rather than having someone write it, you get consistency and security and policy all built in to the application deployment by default. You don't have to remember to do them. You don't have to know how to do them. It just happens. So that means, you know, it's more secure because standards are built into the application deployment process, not scanned after the fact. Side note also less annoying, right? Just hate doing things twice. So this means also that if you're deploying to the cloud, forever, your cloud is more secure by default and you don't have to worry your security team and have them doubt you and check on all your work because they know that this is just getting put in by default. It also allows for governance where standards are implemented as it's generated, meaning things are least privileged and you don't have to be thinking about how all of the different parts of your app are in all the components of your infrastructure are going to interact. We know that for you as infrastructure from code and it just happens. Well, and there was somebody we were chatting to today who was saying policy is worst policy. So, you know, to have something that builds governance in is cool. And so the final pro is there being context aware and I feel like this is one, Lauren, that you are really all over. I do. I love communication. What that sense about me. Also, if you're really into policy, that's amazing. Like we need people who are really into policy. No shade to you there. Yeah, but in this, I think context awareness hits on that too, right? So from development through deployment, each team involved has the context that they need for the part of the application deployment lifecycle that they are knowledgeable and responsible for, right? And they don't have to try to convince any of the other sides why they're right or how they're right. You just have what you need to make the decisions you have to make. This keeps things productive, right? Applications are deployed with dependencies, resiliency, reliability and security all automatically built in. And that just saves the company and you time, money, resources and removes the human error of like, I didn't get a lot of sleep. And so the way I worded this was bad and now no one knows what I'm talking about. And we're going to have a 20 minute meeting because I wrote the wrong word in this one sentence slack DM. Who hasn't been there? I think everything that we've summarized here talks to the business value, right? So yeah, or at a business, the organization, they don't want to do things unless it maps to a business goal and, you know, anything that can help the company be more profitable, reduce risk to be more secure and to be more productive as a team is really good. So we're going to move on to us at CD. We're going to talk a little bit about what we do and how we address this. So we provide generative infrastructure from code. So what does that look like? I'm going to give a quick little summary and then Lauren's going to talk through it. So we look at your application code, we analyze it, we create a visualization of it and we generate your infrastructure as code from the application code. And we do this without you requiring to do any new like learning new languages. You don't have to do code changes. Like it's just done for you. So your developers get to keep doing what they're doing. They don't have to learn anything new. And you DevOps platform engineering team, you also, you get to know that this is being created with the standards you need in place, your golden standards, if you will. So Lauren, why don't you talk us through these steps? I would love to. So first, obviously we're analyzing your application code. Right now, that is Python and Java version two. I learned that today. So excited to share my knowledge with y'all. What that allows us to do is understand the required infrastructure and cloud dependencies that are coming from your application itself. This is inferred via API calls. The core infrastructure we see you trying to call out to service configuration, ingress, egress, environment variables, anything your application is trying to use in order to get its work done. We're looking at statically and analyzing. And then we're visualizing it. So instead of having to read a really fun blob of configuration language that you may or may not understand, you get to visualize what your infrastructure is called. Deployment architecture is going to look like so that you can see all the components. You understand how they're connected. If you know that you need something, say an extra database that you wanted, you can add it in, be it easy drag and drop. You don't have to remember what the exact formatting is for the configuration or like worry about where to put it. We will deal with that for you. It also allows you to connect resources in a way that's safe and guard railed because we will validate that all of the information that needs to be there in order for it to build and deploy properly is there. If it's not, we'll call it out and show you where you need to fill things in. If it's violating policies, we'll call that out and we'll not let you build a nonconforming infrastructure. And it validates the connections between the resources. So you can't put things in the wrong order. We won't let you build any impossible stuff. That sounds like a nice safeguard. And finally, let's talk about generative. Yeah, when you've got all your pieces together, we then generate either Terraform or Helm charts and that is an inclusive or it can be one, the other or both. And we do this with all of those golden standards, all of those policies applied at creation. This means we've said it a lot, but you really care about it, right? Least privilege, least privilege access, only talking to what it needs to talk to. Also includes things like best practices from AWS and Azure, including well-architected framework type stuff and compliance, right? HIPAA, NIST, GDPR, we offer you a range of things out of the box to make sure that your app is compliant with various well-known industry standards. All right. So now we've talked a lot about what we do, but let's actually show you what you do in a demo. We're going to work our magic and see if we can stop sharing and Lauren can demo this for us. Yeah, amazing. Can you see my screen? It is coming. It's thinking about it. Of course, yeah. Still thinking about it? Here we are. Yay. And that was at the end of that, which we'll just ignore. So what we're going to do is we're going to walk through a demo where I am going to play an application developer, but I am going to have some insights about where DevOps comes in because I think there's a lot that our platform has to offer for DevOps. And please also, if you want to interject stuff, I've been talking a lot and people might be quite bored of me. So please have things as I go. So also worth noting before we get started, everything that you're about to see in the UI with the exception of the visualization is available in the CLI right now. So it's just harder to demo because Ben, who hasn't spent hours trying to make their text big enough, we're going to do it visually. It's cuter, but we do have it in the CLI. So when you come to app CD, you're going to log in with GitHub, GitLab, or actually Google, and you're going to authenticate. And then you're going to be presented with a list of repos that you've already onboarded, or you'll be asked to onboard some repos. And depending I've been here before, so I have repos all set up. You're going to want to verify that the repos you need in order to build your project are here. Mine are. That's great. So I'm going to go ahead and get started looking at my app stacks and building a new app stack. What I will be doing as an application developer, right? I'm working on this payment microservice update. It's going to tie to the wish list to let you see what things are in your cart, how they impact your total fun stuff. The cart itself I'm not working on. So I'm going to go ahead and select the language it's in, but I'm going to leave it on the main branch because I'm going to use my co-workers work as I do this. But when I get to the payment repo, I'm actually going to use the branch I've been working in, which is version one. And then when I get to wish list, I'm going to use my fail-safe branch. I can also do this with a Git tag or a commit shot, if that's how you like to roll and you don't like name and branches, totally understandable. So then I'm going to, these are all that I need to build. Also, if you have a monolith, no problems. Select that, select your language, select your branch. We got you. No worries. Not everybody's in microservices. It's some work to get there. It's cool. So all I have to do now as an application developer is I'm going to hopefully name my app stack something good and not something weird. It depends on how I feel that day and hopefully give it a description that will help my future self remember what I was doing. But we're going to pause because there's a lot going on on this screen that I don't have to pay attention to as an application developer, but y'all might care about. So in addition to the repos that I've selected, there is a cloud service. If my platform team had wanted to give me access to a cloud choice, that could have happened here, right? I could have put AWS ECS instead of EKS. We will very likely have Azure coming in the future, near future, but future. So that could be a choice or it can be auto selected for me and I don't have to worry about it. It also automatically figures out what infrastructure is code I need. I don't have to think about whether I need or want Terraform or Helm. I don't have to know that or care. It's just there for me. And most excitingly, in tiny font at the bottom, it says 256 policies applied. Noticeably, I can't get out of that. If I don't like one of those policies or I find it annoying, too bad for me. It's getting applied because this is what needs to be applied to make sure that my app is safe. And I don't have to mess with it. I don't have to remember to pick it. It's just, they're all just there. So, but I'm probably not thinking about this. I'm probably trying to get on with my day. So, I'm going to go ahead and create my app stack. And here is where we're going to see that app CD is statically scanning my application code to get a sense of what infrastructure my application needs in order to work. And because this is a demo, I get to pick when this analysis ends and I choose now. Exciting things about versioning, which I'm going to talk about for a brief moment, is that once I've done this, if I make updates, if I want to see what a different implementation would look like and how it might impact my infrastructure, I can push another version and then I can look at it and compare. So, your versions of app stacks can be versioned along with your code pushes, which is nice. But we're just going to look at this first version right now. This is a visual representation of the infrastructure that my app needs in order to run. Now, we are in the real world as much as sometimes I wish everything could be ideal. This is pretty magical, but it's not going to have all the information that I need to just go ahead and deploy. Immediately, I'm going to have to supply some information. So, I'm going to go ahead and click on a component. In this case, route 53. It's marked by this little error icon. And I have to fill in my host name and the time to live. This is stuff I know off the top of my head. That's good for me and us in this demo. If it wasn't something I knew how to do, though, we are giving you the plain name of the component and the specific piece of information you need for that component. As someone who wrote Terraform config for a while, that can be pretty rough if you are in a Terraform config file and you do not know the name or thing that you're looking for. You're like, I need to fix this block of code. How do I do that? And then you look kind of silly. You're not actually asking questions is good, but I felt very silly trying to ask my coworkers instead of having a plain name for things. This gives you that. But I do know it, which I should because it's a demo. So, go ahead and input that information, click save, and now I'm going to let it, it's going to validate, which of course it's doing because it is from scratch. So, from my app code. So, it's fine. If I had dragged any of these resources off to the side over, this is where validation is super helpful because validation is going to be what allows me to make sure that all of my connections will run and that all of my information is right. Go ahead and validating, clicking buttons. And now I'm going to go ahead and generate my infrastructure as code. Ta-da! I feel like I didn't maybe need a ta-da, but it got one. We've talked about that something that could have taken days, maybe not days, maybe days to create versus, you know, if you were in the office or at your home office creating it, this whole process would take an hour, maybe two at a push, but a lot less time than days of back and forth. Yeah, definitely. And the next part is if I do want to read this and I know stuff about this, great. I can read it. If I need to get signed off, fantastic. It's right here. You can call someone in. They can sign off. If I want to ignore this because it's a staging environment and I don't actually want to learn Terraform, cool. I don't have to learn it. I can just go ahead and export. I'm going to export the generated IFC files. I am going to put them in a PR and I'm going to PR them into my CICD pipeline or deployment pipeline or whatever I've got going that's going to give me the infrastructure I need. And then everything I need is going to get those. Beautiful. Love it. So as we round this out, thank you all for listening to us as we go through this. We do have some resources available to you. So you can try appcd. So appcd.com, you can visit our playground. So if you don't have something or some repos that you can scan and work with and write not use right now, you can look at our playground, see how it works. We also have a free developer edition. So you can totally use it. A CLI as well. And then of course, with every organization, we do have an enterprise product as well. So if you have any questions about this or if you want to get in contact with us, I am on the CNCF Slack channel under Danielle Cook. But we also have created this lovely email address for you CNCF at appcd.com where you can talk to any of us. So I want to thank all of you and thank you, Asif. Thank you, Lauren. It's been great going through this. And thanks. It's been fun.