 Hi, this is Yoosaf Limpati and welcome to T3MR, topic of this month. The topic of this month is Infrastructure as Code. And today we have with us Shai Bear, COO and co-founder of Winkloud. Shai, it's great to have you on the show. Hey, great to be here. Since the topic is Infrastructure as Code, I would like to hear from you. How do you see Infrastructure as Code? How would you define it? To me, Infrastructure as Code is basically a way to organize all the infrastructure in something that's using tools that we use to develop code. So instead of doing click ops and defining everything in the portals of the cloud providers, we use files with written code. It could be code. It could be configuration definitions. But using tools that we use in order to write and to deploy and to make changes to code, basically. What does it mean for developers and dev options when we look at infrastructure as code, when everything is seen as code? What does it mean for them? How it makes their life easier or difficult? So I think, depending on the tool, of course, there is a very wide variation between the different tools. But I think that primarily allowing DevOps engineers and sometimes even developers, the ability to reproduce the infrastructure definitions, be able to take infrastructure definitions and compose them into different definitions and reuse some of the code that they've already created in order to spawn new environments or to modify existing environments without having to redo everything with clicks, basically. How much adoption are you seeing of infrastructure as code? We're biased, of course. We are primarily talking with companies that are using infrastructure as code in various forms. So I don't really know, I don't really have numbers how prevalent it is, but I think almost any company, any serious company that's on the cloud today uses some form of infrastructure as code. And as I said, you're a bit biased because you deal with companies who are deploying infrastructure as code. And can you talk a bit about, when they do embrace these practices in infrastructure as code tools, what are some of the hurdles, roadblocks that they come across? Because sometimes when we do talk about these technologies, we also talk about the people or cultural aspect of it. So talk about what challenges they face. Of course, we'll also talk about how you folks help them, and we'll also talk about the open source project as well. But I do want to understand the hurdles, the challenges they face, and how many of these challenges are about technologies, tools, and how much of it is about culture. Excellent question. So I'll start with the culture. I think one of the main hurdles is that many companies divide the, like developers who handle infrastructure, namely DevOps are different people from developers who handle the business logic of the application. And I think that especially today with modern cloud, there's a big mix, like you can't really divide the application into infra and applicative code. What you might call infra also has applicative parts to it. For example, if you have storage buckets in the cloud, applicatively it's a way to store objects, right? And that's something that the application developers are using. But if you look at the infrastructure part, you need to set it up. You need to define redundancy policies and security policies. And so you can't really say, OK, this part, this bucket is only infrastructure or only application. And when you have different developers handling these different aspects, they find themselves oftentimes having to depend on each other and having to work very closely together. And obviously that can create friction and problems. So that was a very long way of saying that people, there's no good separation between concerns of the application developers and the DevOps team. And I think technology-wise, it manifests itself in the fact that, like I said before, it's very hard to say that a specific service is just infra or just part of the application. And these tools, infrastructure as code, only handle the infrastructure part. And they don't let you also handle the applicative part. So it forces you to kind of separate your application into two different parts that you then need to stitch manually together, which is a lot of boilerplate code and glue logic that no one likes. Can you talk about some of the key consequences in other words but some of the key components by components, I don't mean the code base, but these are the key things that organizations' teams should look at when they're embracing infrastructure as code. So I think they primarily should look at their developers and see what they know. Because I think that because of this separation and friction between DevOps teams and developer teams, if you can have a team that is full stack in the sense that every developer is their own DevOps, I think in today's world with today's technologies, this is something that would be beneficial. So if you can get your team to be stacked in that way, that is something that you should look into. As well as to try and understand exactly what needs you have of the cloud. For example, if you need to have a multi-cloud setup, you have very different needs versus if you only need to be in one cloud and the same goes for if you're a multi-tenant, single-tenant. So there are a lot of different architectural aspects of individual solutions that then dictate which tools and which philosophies you should follow. What kind of trends you are seeing in this space where you look at infrastructure, you look at code and you say, hey, these are things that are happening. This is where we are heading. So I think the trend that we see is that these infrastructure as code tools are becoming more and more like actual code. Like it used to be more configuration files and now the more modern solutions are actual code in modern programming languages. And they started with just taking care of infrastructure and now you see that slowly but surely tools are starting to also handle the applicative part of the application and the connection between the application and the infrastructure. So there's this trend now of infrastructure flow code, different solutions that allow developers to write their applicative code and then have some system, platform or compiler that deduces the infrastructure that is needed in order to run that code. And I think that this is a very interesting approach. I think that it's very well suited for, let's say, very specific solutions, very specific needs, vertical needs. And on the other hand, there are other solutions that are more general purpose where they try to maybe hide the infrastructure altogether, like using Generative AI where you just define your desired application or your desired infrastructure and then these tools generate the infrastructure that is needed. And then there is tools like WingLang what we're making that we're basically creating a general purpose programming language that allows you to express your infrastructure and your code. We're not trying to hide the fact that there is infrastructure and we believe that developers do need to understand that they're writing code for a distributed system and to write their code accordingly. We just believe that they can write this code for an abstract notion of a cloud much like POSIX has done for a single machine. So basically do the same for the cloud. Since you talked about Generative AI, so when we look at LLMs, does it help infrastructure's code hurt teams? Good question. I think most developers today use LLMs to some extent while they're developing but I haven't seen a solution in production yet where we just say I want to create this and that application and it will create the perfect code for it or even just the infrastructure part that is scalable and secure. There are solutions where you don't define the business need but you define the architecture, the infrastructure. And again I think it's going to be very interesting to see how fast these solutions will evolve but currently I haven't seen a production-ready solution. Can you talk about what kind of tools are available for customers' users so they can leverage some of these technologies and practices? There are so many tools and I think that's part of the problem but there are too many tools to choose from but I think obviously some of the tools that they want more are Pulumi and Terraform obviously and you have other more specialized tools that help in more distinct use cases but yeah, that's part of the problem. So how are customers able to navigate through, I mean when you look at the whole cloud native Kubernetes space it is intimidating there are so many, which is actually good it's a healthy ecosystem but it can be intimidating for users' customers so how is WingCloud and of course if you look at open source projects Winglang is there, how are you folks helping customers? So we're helping them mainly through the connection this connection between the infrastructure part and the applicative part so we allow developers to have a single code base with a single programming model where you write both your infrastructure and your applicative code and then you can compile it to different provisioning engine different platforms basically so you can work at a higher level of abstraction and then decide later which cloud providers which provisioning engines and which security and other policies you want to enforce so developers don't really need to make these decisions or really need to know all those different tools and the operation people they are the ones who are going to work with not actually setting up these tools but they're going to configure them What advice do you have for teams when they are embracing infrastructure code what is the right approach they should have there? I would just advise them to take a very close look at their business needs not just the immediate business needs but also the projected business needs and look at their technology stack and try to choose the right tools for the job basically as you said there's a healthy ecosystem today with tools that are basically there specialized for any use case almost so just educate yourself on the available tools after you really understand the problem that you solve and pick the right tools Shai, thank you so much for taking time out today and talk about this topic and I would love to check with you again, thank you Great, thank you, it was my pleasure