Hello friends. My name is Ala Shiban and I'm the co founder of a startup called Klotho, enabling teams to write universal backend code that runs anywhere. I led teams in the visual studio at Microsoft and more recently led the cloud services.org at Ride Games. I'm going to walk you through the state of infrastructurefromcode from code in 2023, starting with what is infrastructure from code? How does it compare to infrastructurefromcode as code and the leading approaches and tools in the space? Infrastructure from code, or IFC, is a broad term around tools that analyze application code to infer the cloud resources the application needs, and then creates and maintains them without you having to manually define them. What that means is that the tools are able to take application code with some or no metadata, process it, and create a deployable cloud version of it. What does the name mean and how is it different from infrastructure as code? Infra as code or IAC refers to tools that allow developers or cloud engineers to describe infrastructure. You write templates or actual code, terraform, pulumi or similar, that describes lambdas or kubernetes clusters, IAM policies, API gateways, how they interconnect sqs or Kafka queues and is loosely aligned with using these resources using an injected configuration or environment variable. And while the name infrastructurefromcode from code sounds similar, it means something quite different. It refers to tools that automatically infer the needed infrastructure components from application code. Here's an example from one of the tools. The application code is a plain Python app that uses the Redis SDK and fast API web framework. And once the tool is run on that code, it generates an API gateway, a lambda to run the code, an elasticache instance to back the SDK usage in the code that includes vpcs and policies. The things that are needed to make this deployable and runnable. And depending on the tool, you're able to swap out technologies without changing the application code. Nowhere did it say Lambda. Looking at it from an aspirational point of view, what these tools enable is writing universal backend code that runs on different target platforms with varying runtime characteristics, different clouds, different underlying services on prem, different architectures, and they're able to adapt as requirements change. What problems does it solve, though? How rich would you be IFC? You got $1 every time somebody promised you a tool that lets you focus on the business logic and not the infrastructure. And if you've been in the industry for long enough, you've seen this never ending cycle. VMS service oriented architectures microservices, containers, mesos, serverless, and now kubernetes. Focusing on the business logic comes with a really expensive asterisk associated with it, because there's a lot that goes into building back ends, lots to learn and set up. This list wouldn't surprise you unless you look at number 14 that's not usually there, and the list goes on. Research we've conducted shows that only 63% of engineering capacity in midsized companies is dedicated to feature development. Because of this and related enabling efforts, and then requirements change and you're asked to be able to run the application on a different cloud, AWS, azure, GCP, add fault tolerance or multi region support, switch from something to kubernetes, integrate the serverless code with the existing architecture, or maybe split that growing service into two, or actually combine those three into one to save some cost. And that new service that Hema is building needs GRPC for even lower latency infrastructure from code aspires to enable universal backend code, developers only write application code, and infra platform teams set tech standards and ensure feature teams adhere to them. They work together, but independently. There are four dominant approaches to realizing this aspiration. In the SDK approach, a custom SDK is introduced that developers use in their code. The IFC tool would analyze how the service code interacts and uses that SDK, and then infers the infrastructure from that. Introducing a custom SDK makes inferring usage from code more predictable and tailored to work well for the scenarios it was designed for. But it also means the SDK is always one step behind in leveraging new underlying cloud features. The use of a new platform specific SDK requires developers to learn and make use of those libraries. However, they have the potential of unlocking unique capabilities only they can offer. This comes at a cost of sacrificing the breadth and depth of features that popular community driven libraries may offer. In the programming language approach, a new programming language is introduced that is cloud centric. They introduce language constructs that would otherwise be difficult to do in existing programming languages. Interactivity or distributed computing constructs cloud be more readily implemented or integrated into the language, making the process simpler and more intuitive for software developers. There are a few tradeoffs with that approach, though. Software developers have to commit to learning a new language, which means that they can't reuse the expertise they built over the years with existing ecosystems and tools. Starting a new programming language also means that you have to start a new ecosystem for that language or have stellar interoperability with supported and interoperable languages. That has failed in many occasions but also succeeded in others. Like with typeScript, there's an organizational cost as well where you need to hire people with that expertise in mind, and it's much easier to finding developers that know Golang, Python, C sharp, Java. The annotations approach relies on encode annotations, which either leverage the existing programming language constructs, open source libraries frameworks in the code, or expect more metadata inside of the annotations themselves. Those tools have to depend on static analysis to an even greater extent because they don't have a custom SDK or a purposefully crafted programming language that has those constructs built in. For example, in the node JS world is to annotate an event emitter with a pub sub capability, turning it into a distributed mechanism for passing messages around. But from the developer perspective, developers are still interacting with an event system. This would then be backed by SNS, SQS, Kafka. It doesn't really matter, because that becomes the implementation detail of the IFC tool. The trade off, however, is the expanding need for the tooling to understand existing and growing sets of libraries, languages, design patterns, clouds and underlying services. The dimensionality of the problem becomes potentially too large and not having an SDK to lean on or complement it. The temptation to grow the annotation system until it becomes a full fledged DSL or language is ever there, which requires developers to then understand the annotation system and processor, and often work around it manually when it breaks. The last one is more of a hybrid between a few of the approaches. You could have an SDK with some annotation systems to simplify that process, or annotations that have more metadata in them, but expand existing programming language interfaces or some variation on that spectrum. Here's a list of the dominant players in this space. We'll compare them based on these dimensions, and we'll talk about why they're important. Starting with the license there's a strong desire from the developer operator community to have more open source tools, which gives you a degree of certainty about its future, all the way down to being source available or closed source. As you can see, many of the solutions are already open source, although a few who are generally more a SaaS offering are either closed source or source available programming languages. One or two languages. The majority support one language, with a couple that focus on multilanguage support and a few that are introducing their own languages. What is the developer interface? Different tools and startups are taking the SDK approaches. Others are leaning towards the framework or language approach, with security. Most startups and tools are leveraging the fact that they have this reasoning in static time about how the applications are constructed to generate policies based on the dependency graphs, so you get least privileged permissions through IAM or similar policy engines without have to manually creating them. Infrastructure as code support is important for teams that already have platforms and either want to introduce IFC into the existing platforms or integrate it into an IFC based workflow. It provides infrastructurefromcode teams the ability to customize and tailor the output to the organizational needs that they have, reusing a lot of the terraform or infrast code templates they've already generated. This ties into configurability and not the high level one which most of those tools have configuration for. But how do you configure the lower level pieces? Do you use custom configurations or specifications, or do they allow for using infrastructure as code as the mechanism to configure the generated resources, bypassing any for a spec hosting model. Some are PaaS only, and you get the same trade offs of having a PaaS versus IAS or a self hosted solution. On the other end, it's completely self hosted where it generates IAC or the elements for you to deploy, and some do both, backing technologies like compute or storage. Some support on demand computing or serverless versus always on compute like Kubernetes. Then there's the next layer of technologies that the IFC tools target. Some are proprietary, especially ones that are more closed source or SaaS versions. You don't know what they're using behind the scenes. Others are preselected, meaning it's a specific stack that they use as part of the implementation. For instance, API gateway with postgres, DynamoDB, Kubernetes, Lambdas, GRPC, and sQs. Others are adaptable, meaning that the technologies are interchangeable. Technology can be swapped out for another being able to switch out GRPC with Linkerd or lambdas with kubernetes without affecting application code. Cloud portability support most support one cloud, others are prioritizing multi cloud support. Here's a matrix with the distillment of all the IFC tools and the characteristics of each. You can find it on Cloud dev, IFC, and many more resources there. How does this relate to existing infrastructurefromcode and platform teams? What we see happening is that the infrastructure teams will continue describing more custom and organization specific infrastructure as code or terraform in the cases that they matter, and then provide an IFC tool that translates developer code to cloud versions of it that is integrated and deployed with the tooling that the infrastructurefromcode team set, and by having this IFC tool in the middle, it allows them to ensure and enforce policies across the company based on teams or organizations or individuals or types of technologies. The infrastructure from code, movement or approach wants to help you break free from the cycle of the mundane to work on challenges that nobody else is and only you can. So check out cloud dev IFC to find all the resources and tools. Try one out and join us on discord and continue the conversation. Have a great day.