Latest / Giant Robots Smashing Into Other Giant Robots / 480: klo.dev with Aaron Torres and Ala Shiban
Transcript
- VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with me today is Aaron Torres and Ala Shiban from Klotho, which powers Infrastructure Copilot, the most advanced infrastructure design tool that understands how to define, connect, and scale your infrastructure-as-code. Aaron and Ala, thank you for joining me. ALA: Thank you for having us. AARON: Yeah, thank you very much. VICTORIA: Well, great. I wanted to just start with a little bit of a icebreaker; maybe tell me a little bit more about what the weather is like where you're currently at. AARON: So I'm in St. Louis, Missouri. Right now, it is definitely...it feels like summer finally. So we're getting some nice, warm days and clear skies. ALA: And I'm in LA. And it's gloomier than I would like compared to what it's been in the last few years. But I'll take it if this means we're getting closer to summer. VICTORIA: Right. And I'm not too far from you, Ala, in San Diego, and it's a little chillier than I would prefer as well. But that's what we get for living close to the beach. So there's always trade-offs. Well, wonderful. I'm so excited to talk to you about your product here today. Let me start with a question about, let's say, I'm a non-technical founder, and I've just heard about your product. What's your pitch to someone in that position on the value of your tool? ALA: For somebody who isn't technical, I would say you can enable your team, your developer team, to quickly iterate on their applications or features and let InfraCopilot and Klotho take care of taking that application or features and deploy them and getting them running on the cloud. VICTORIA: Okay. So maybe I've been thinking about having to hire an AWS engineer or someone who's an infrastructure engineer. I could consider getting a tool like Klotho and Infrastructure Copilot to allow my developers to take on more of that responsibility themselves. ALA: Absolutely. VICTORIA: Gotcha. Okay, well, great. So let me ask about how did it all get started? What was the impetus that set you on this journey ALA: Both Aaron and I used to work at Riot Games, and I used to lead the cloud services org at Riot. I had about 50 people, 40 engineers, as part of a larger 120-person org, infrastructure platform org, which was tasked with building the platform that runs League of Legends, VALORANT, for 200 million people all around the world, in China. Full DevOps mode for Riot developers and full ops mode for running in China. It took us three years, a lot of effort. And by the time we were done, it was already legacy, and that seemed broken to me. We were already getting started to do another round of upgrades and iterations. At that point, I decided to leave. But I couldn't let go of this feeling that we shouldn't have had to spend so many years solving a problem only for it not to be solved. And based on research and conversations, it was clear that this was an industry-wide phenomena. And so I went about trying to figure out why that happens and then how we can solve it, and that's how Klotho came about. VICTORIA: That's so interesting. And I've certainly been a part of similar situations where you spend so much time solving a big problem and infrastructure only to get to the end of it and realize now you have a whole nother set of problems. [laughs] And you get upgrade. And they've also invented new ways of doing things in the cloud that you want to be able to take advantage of. So you had that time with Riot Games and League of Legends and building this globally responsive infrastructure. What lessons learned did you take from that into building Klotho and building your product, Infrastructure Copilot? AARON: We learned a bunch of things. One of the more difficult problems to solve isn't technical at all; it's organizational and understanding how the organization flows and how the different teams interact with each other. So we really endeavor to solve that problem. I mean, our product is a technical product, but it is meant to help bridge that gulf and make that problem a little bit easier as well. Otherwise, yeah, exactly to your point, part of the problem with these migrations is that new technology comes along. And there's definitely a feeling of when you hire new developers, they are excited about the new thing, and there's other reasons as well. But you get this kind of natural, eternal migration going to the newer technology. VICTORIA: That makes sense. And you bring up a great point on some of the issues, not being technical but organizational. And when I look at a lot of infrastructure-as-code tools, when we get to security, I wonder how it fits in with the organizational requirements for security, right? Like, you have to have defined groups who have defined access to different levels and have the tools in place to be able to manage identities in your organization. So I'm curious how that fits into what you built with Klotho and the Infrastructure Copilot. ALA: The way we think about infrastructure is as a set of intents or things that developers, and operators, cloud engineers, infrastructure engineers are trying to satisfy or to do. So you have tasks. You're trying to build a solution. You're trying to build an architecture or add something to it. And organizations have constraints, whether it's their own Terraform, or their own ruleset, or security expectations, or compliance expectations. And the way we look at this dynamic is those rules are encoded in a way that Klotho, which is a cloud compiler, it has the ability to reason about both the application and the infrastructure-as-code and enforce or at least warn about mismatches between the constraints that the organization sets, and what the developer or operator are trying to do, or the intent that is being described high level or low level within the tools. And then that is reflected both visually and in code and in the infrastructure-as-code, one or more. And so it's very much rooted in how the entire set of technologies and product and tools are designed. VICTORIA: Got it. So do you see the tool will be more fit for the market of larger development shops who maybe have existing infrastructure but want to experiment with a different way of managing it for their developers? ALA: It depends. So because we went about solving the problem rather than just building a specific vertical or a specific stack piece, we try to only play in this space of intelligent editing and intelligent understanding of the alignment between infrastructure and code. And so you could, as a developer, effectively with Klotho, write a plain application and have it be running in the cloud without knowing anything in the underlying cloud systems. It will set up storage, and persistence, and security, and secrets. All those elements are easily accessible within the code itself. It can also work in the context of a company where the infrastructure or platform team have set those rules and guidance within the tools. And then, developers can continue working the way they expect to work, either in code or in the infrastructure-as-code layer. And it would still allow them to do the same intents that they want only within that sandbox. Or if they can't be satisfied because they're trying to do something that isn't allowed, they have a mechanism of, one, knowing that but also asking, in our case, InfraCopilot to help it reshape what it's doing, what they're doing into the sandbox and the trade-offs that that brings in. VICTORIA: Got it. So you can both start from scratch and start a brand new application using it, or you can integrate it with your existing rules and systems and everything that already exists. ALA: Exactly. VICTORIA: Gotcha. Yeah, I think one interesting thing we've found with very new founders who are building their application for the first time is that there are some essential things, like, they don't even have an identity store like a Google [laughs] or Microsoft Azure Directory. So starting to work in the cloud, there are some basic elements you have to set up first that's a little bit of a barrier. So it sounds like what you're saying with Klotho is that you wouldn't necessarily have those same issues. Or how would you get that initial, like, cloud accounts set up? AARON: Yeah. So, for the situation where you're bootstrapping everything from scratch, you've done nothing; we haven't invested much in setting up the initial accounts. But assuming you get to the point where you have AWS credentials, and you're able to hit the AWS API using the CLI, that's sort of where we can take over. So, yeah, like, I would say right now, as a business, it's definitely where the value is coming is going to be these mid-sized companies. But for that scenario specifically, bootstrapping and starting something from scratch, if you have that initial setup in place, it's one of the fastest ways to go from a concept to something running in the cloud. ALA: And if you think about the two tools that we're building, there's Klotho, which InfraCopilot...or the Klotho engine, which Klotho the CLI tool uses and InfraCopilot uses. The Klotho engine is responsible for the intelligence. It knows how to translate things like I want a web API that talks to DynamoDB. And it will literally create everything or modify everything that is needed to give you that and plug in your code. You can also say things in a much higher level degree, which things like I want a lambda which handles 10,000 users. And I want it to be lowest latency talking to an RDS Instance or to a Postgres database. And what that would do is, in our side, in the Klotho engine, we understand that there needs to be a VPC and subnets, and spin up RDS, and connect an RDS proxy. Because for connection pooling with lambda specifically, you need one to scale to that degree of scale. And so that is the intelligence that is built into the Klotho engine if you want to start from the infrastructure. If you want to start from code, all you have to do is bring in the Redis instance, the Redis SDK, and, let's say, your favorite web framework, and just add the annotations or the metadata that says, I want this web framework to be exposed to the internet, and I want this Redis to be persisted in the cloud. And you run Klotho. And what comes out the other end is the cloud version that does that for you. And it's one command away from getting it to run. VICTORIA: So that's interesting how the two tools work together and how a developer might be able to get things spun up quickly on the cloud without having to know the details of each particular AWS service. And reading through your docs, it sounds like once you have something working in the cloud, then you'll also get automated recommendations on how to improve it for cost and reliability. Is that right? ALA: That's where we're headed. VICTORIA: Gotcha. I'm curious; for Aaron, it sounds like there is more in that organizational challenges that you alluded to earlier. So you want to be able to deliver this capability to developers. But what barriers have you found organizationally to getting this done? AARON: So I'm going to speak specifically on infrastructure here because I think this is one of the biggest ones we've seen. But typically, when you get to a larger-sized company, we'll call it a mid-sized company with, you know, a couple hundred engineers or more, you get to the point where it doesn't make sense for every team to own their entire vertical. And so you want to really put the cloud knowledge into a central team. And so you tend to build either a platform team, or an infrastructure team, or a cloud team who sort of owns how cloud resources are provisioned, which ones they support, et cetera. And so, really, some of the friction I'm talking about is the friction between that team and developer teams who really just want to write their application and get going quickly. But you don't have to fall within the boundaries set by that central team. To give, like, a real concrete example of that, if you wanted to prototype a new technology, like, let's say that some new database technology came out and you wanted to use it, it's a very coordinated effort between both teams in terms of the roadmap. Like, the infrastructure team needs to get on that roadmap, that they need to make a sandbox and how that's going to work. The code team needs to make an application to test it. And the whole thing requires a lot more communication than just tech. VICTORIA: Yeah, no, I've been part of kind of one of those classic DevOps problems. It's where now you've built the ops team and the dev team, [laughs] and now you're back to those coordination issues that you had before. So, if I were a dev using Klotho or the infrastructure-as-code copilot, I would theoretically have access to any AWS sandbox account. And I could just spin up whatever I wanted [laughs] within the limits that could be defined by your security team or by your, you know, I'm sure there's someone who's setting a limit on the size of databases you could spin up for fun. Does that sound right? AARON: Yeah, that's totally right. And in addition to just limits, it's also policies. So a good example is maybe in production for databases, you have a data retention policy. And you have something like we need to keep three months of backups for this amount of time. We want to make sure that if someone spins up a production database from any of those app teams, that they will follow their company policy there and not accidentally, like, lose data where it has to be maintained for some reason. ALA: That's an important distinction where we have our own set of, you know, best practice or rules that are followed roughly in the industry. But also, the key here is that the infrastructure central teams in every company can describe the different rulesets and guidelines, guardrails within the company on what developers can do, not only in low-level descriptions like instance sizes or how much something is, whether it's Spot Instances always or not in production versus dev. But also be able to teach the system when a developer says, "I want a database," spin up a Postgres database with this configuration that is wired to the larger application that they have. Or, if I want to run a service, then it spins up the correct elements and configures them to work, let's say, Kubernetes pods, or lambdas, or a combination based on what the company has described as the right way for that company to do things. And so it gives flexibility to not know the specific details but still get the company's specific way of doing them. And the key here is that we're trying to codify the communication patterns that do happen, and they need to happen if there's no tools to facilitate it between the infrastructure platform team and the feature teams. Only in this case, we try and capture that in a way that the central teams can define it. And the developers on feature teams can consume it without having as much friction. VICTORIA: So that will be different than, like, an infrastructure team that's putting out everything in Terraform and doing pull requests based off GitHub repository to that. It makes it a little more easier to read, and understand, and share the updates and changes. AARON: Right. And also, I mean, so, like, the thing you're describing of, like, the central team, having Terraform tends to be, like, these golden templates. Like they say, "If you want to make a database, here's your database template." And then you get a lot of interesting issues like drift, where maybe some teams are using the old versions of the templates, and they're not picking up the new changes. And how do you kind of reconcile all that? So it is meant to help with all of those things. VICTORIA: That makes a lot of sense. And I'm curious, what questions came up in the customer discovery process for this product that surprised you? ALA: I think there's one...I don't know that it was a question, but I think there was...So, when we started with Klotho, Klotho has the ability to enable a code-first approach, which means that you give the tool to developers as the infrastructure or platform team, or if you're a smaller shop, then you can just use Klotho directly. You set the rules on what's allowed or what's not allowed, and then developers can work very freely. They can describe very succinctly how to turn a plain object, SDK, et cetera, how to build larger architectures very quickly with a few annotations that we describe and that give cloud powers. We had always thought that some teams will feel that this encroaches on their jobs. We've heard from people on infra, you know, platform teams, "This is amazing. But this is my job." And so, one of our hypotheses was that we are encroaching into what they see as their responsibility. And we built more and more mechanisms that would clean up that interface and give them the ability to control more so they can free themselves up, just like most automations that happen in the world, to do more things. What happened later surprised us. And by having a few or several more discoveries, we found out that the feeling isn't a fear of the tool replacing their job. The fear or worry is that the tool will make their jobs boring, what is left of the job be boring, and nobody wants to go to work and not have cool and fun things to do. And because I think we all, on a certain degree, believe that, you know, if we take away some of the work that we're doing, we'll find something higher level and harder to solve, but until that exists in people's minds, there's nothing there. And therefore, they're left with whatever they don't want to do or didn't want to do. And so that's where we tried to take a step back from all the intelligence the Klotho engine provides through that code-first Klotho. And we built out focusing on one of the pillars in the tech to create InfraCopilot, which helps with keeping or making the things that we already do much simpler but also in a way that maintains and does it in a fun way. VICTORIA: That makes sense because my understanding of where to use AI and where to use machine learning for best purposes is to automate those, like, repetitive, boring tasks and allow people to focus on the creative and more interesting work, right? ALA: Yes and no. The interesting bit about our approach to ML is that we don't actually use machine learning or ChatGPT for any of the intelligence layers, meaning we don't ask ChatGPT to generate Terraform or any kind of GPT model to analyze a certain aspect of the infrastructure. That is all deterministic and happens in the Klotho engine. That is the uniqueness of why this always works rather than if GPT happened to get it right. What we use ML for is the ability to parse the intent. So we actually use it as a language model to parse the intent from what the user is trying to convey, meaning I want a lambda with an API gateway. What we get back from our use of ML is the user has asked for a lambda, an AWS lambda, and API gateway and that they be connected. That is the only thing we get back. And that is fed into the Klotho engine. And then, we do the intelligence to translate that to an actual architecture. VICTORIA: That's a really cool way to use natural language processing to build cloud infrastructure. MID-ROLL AD: Are you an entrepreneur or start-up founder looking to gain confidence in the way forward for your idea? At thoughtbot, we know you’re tight on time and investment, which is why we’ve created targeted 1-hour remote workshops to help you develop a concrete plan for your product’s next steps. Over four interactive sessions, we work with you on research, product design sprint, critical path, and presentation prep so that you and your team are better equipped with the skills and knowledge for success. Find out how we can help you move the needle at: tbot.io/entrepreneurs. VICTORIA: I'm curious; you said you're already working on some issues about being able to suggest improvements for cost reduction and efficiencies. What else is on your roadmap for what's coming up next? AARON: So there's a bunch of things in the long-term roadmap. And I'll say that, like, in the short term, it's much more about just expanding the breadth of what we support. If you think about just generating all the different permutations and types of infrastructure, it's, like, a huge matrix problem. Like, there's many, many dimensions that you could go in. And if you add an extra cloud or you add an extra capability, it expands everything. So you can imagine, like, testing it to make sure things work, and everything becomes very complicated. So, really, a lot of what we're doing is still foundational and trying to just increase the breadth, make the intent processing more intelligent, make the other bits work. And then one of the areas right now is for our initial release of the product; we chose to use Discord as our interface for the chatbot. And the reason for that is because it gives us a lot of benefits of having sort of the community built in and the engagement built in where we can actually talk with users and try and understand what they're doing. However, we really have a lot of UI changes and expansions that we'd like to do. And even from some of our early demo material, we have things like being able to right-click and being able to configure your lambda directly from the UI. So there's a lot of areas there that we can expand into an intent, too, once we get sort of the foundational stuff done, as an example. The intelligence bit is a much bigger process, like, there's a lot of things to unpack there. So I won't talk about it too much. But if we were to just talk about the most simple things, it'd be setting up alerts somehow and then feeding into our system that, like, we're hitting those alerts, and we have to make modifications. A good example of that would be, like, configuring auto scaling on an instance for [inaudible 22:17]. So we can get some of those benefits now. The bigger vision of what we want to do with optimization requires a lot more exploration and also the ability to look at what's happening to your application while it's running in the cloud. ALA: Let me maybe shed a bit more light on the problems we're trying to solve and where we're headed. When it comes to optimization, to truly optimize a cloud application, you have to reason about it on the application level rather than on the one service level. To do that, we have to be able to look at the application as an application. And today, there's a multi-repo approach to building cloud applications. So one of the future work that we're going to do is be able to reason about existing infrastructure-as-code from different portions of the teams or organization or even multiple services that the same team works and link them together. So, when we look at reasoning about an architecture, it is within the entire context of the application rather than just the smaller bits and pieces. That's one layer. Another layer is being able to ingest the real runtime application metrics and infrastructure metrics, let's say, from AWS or Azure into the optimizer system to be able to not only say, oh well, I want low latency. Then this is hard-coded to use a Fargate instance instead of a lambda. But more realistically, being able to see what that means in lambda world and maybe increase the concurrency count. Because we know that within the confines of cost limitations or constraints that the company wants to have, it is more feasible and cost-effective to raise the minimum concurrency rate of that lambda instead of using Fargate. You can only do that by having real-time data, or aggregated data come from the performance characteristics of the applications. And so that's another layer that we're going to be focusing on. The third one is, just like Aaron said, being able to approach that editing experience and operational experience, not just through one system like InfraCopilot but also through a web UI, or an app, or even as an extension to other systems that want to integrate with Klotho's engine. The last thing that I think is key is that we're still holding on to the vision that infrastructure should be invisible to most developers. Infrastructure definition is similar to how we approach assembly code. It's the bits and pieces. It's the underlying components, the CPUs, the storage. And as long as we're building microservices in that level of fidelity, of like, thinking about the wiring and how things interconnect, then we're not going to get the gains of 10x productivity building cloud applications. We have to enable developers and operators to work on a higher abstraction. And so our end game, where we're headed, is still what we want to build with Klotho, which is the ability to write code and have it be translated into what's allowed in the infrastructure within the constraints of the underlying platforms that infrastructure or platform teams set for the rest of the organization. It can be one set or multiple sets, but it's still that type of developers develop, and the infrastructure teams set them up to be able to develop, and there's separation. VICTORIA: Those are all really interesting problems to be solving. I also saw on your roadmap that you have published on Klotho that you're thinking of open-sourcing Klotho on GitHub. AARON: So, at this point, we already have the core engine of Klotho open-sourced, so the same engine that's powering InfraCopilot and Klotho, the tool itself is open source today. So, if anyone wants to take a look, it is on github.com/klothoplatform/klotho. VICTORIA: Super interesting. And it sounds like you mentioned you have a Discord. So that's where you're also getting feedback from developers on how to do this. And I think that challenge you mentioned about creating abstractions so that developers don't have to worry as much about the infrastructure and platform teams can just enable them to get their work done; I'm curious what you think is the biggest challenge with that. It seems like a problem that a lot of companies are trying to solve. So, what's the biggest challenge? And I think what do you think is unique about Klotho and solving that challenge? AARON: I guess what I would say the biggest challenge today is that every company is different enough that they all saw this in a slightly different way. So it's like, right now, the tools that are available are the building blocks to make the solution but not the solution itself. So, like, every cloud team approaches it on, let's build our own platform. We're building our own platform that every one of our developers is going to use. In some cases, we're building, like, frameworks and SDKs that everyone's going to use. But then the problem is that you're effectively saying my company is entering the platform management business. And there's no way the economies of scale will make sense forever in that world. So I think that's the biggest issue. And I think the reason it hasn't been solved is it's just a very hard problem. There's many approaches, but there's not a clear solution that kind of brings it all together. And I think our product is positioned better than most to solve some of the higher-level abstractions. It still doesn't solve the whole problem. There's still some things that are going to be tricky. But the idea is, if you can get to the point where you're using some of our abstractions, then you've guaranteed yourself portability into the future, like, your architecture will be able to evolve, even in technologies that don't exist yet once they become available. ALA: To tack on to what Aaron said, a key difference, and to our knowledge, this doesn't exist in any other tool or technology, is a fundamentally new architecture we call adaptive architecture. It is not microservices. It is not monoliths. It's a superset that combines all the benefits from monoliths, microservices, and serverless if you consider it a different platform or paradigm. What that means is that you get the benefits without the drawbacks. And the reason we can do it is because of the compiler approach that we're taking, where everything in the architecture that we produce is interchangeable. The team has decided to use Kubernetes, a specific version of Kubernetes with Istio. That works great. And, a year later, it turns out that that choice no longer scales well for the use. And we need to use Linkerd. The problem in today's world and what companies have to do is retrofit everything and not only the technology itself, but it's the ripple effects of changing it into everything else that all the other choices that were made that depended on it. In the Klotho world, because of the compilation step or the compilation approach and its extensibility, you could say, I want to take out Istio and replace it with Linkerd. And it would percolate all the changes that need to happen everywhere for that to maintain its semantic behavior. To our knowledge, that doesn't exist anywhere today. VICTORIA: So it would do, maybe not, like, would do migrations for you as well? ALA: I think migrations are a special case. When it comes to stateless things, yes. When it comes to data, we are much more conservative. Again, bringing what we've learned in different companies in, a lot of solutions try to solve all the things versus we're trying to play in a very specific niche, which is the adaptive architecture of it all. But if you want to move data, there's fantastic tools for it, and we will guide you through getting the access to the actual underlying services and, say, great, write a migration system, or we can generate for you. But you will run it to move the data from, let's say, Postgres to MySQL or from being able to drain a unit on Kubernetes to a lambda. Some of those things are much more automatic. And the transition happened through the underlying technologies like Terraform or Pulumi. Others will require you to take a step, not because we can't do it for you but we want to be conservative with the choices. AARON: I would also add that another aspect of this is that we don't position ourselves as being the center of the universe for these teams. Like a lot of products, you kind of have to adopt the platform, and everything has to plug into it, and if you don't adhere, it doesn't work. We're trying very, very hard with our design to make it so that existing apps will continue to function like they've always functioned. If app developers want to continue using direct SDKs and managing config themselves, they can absolutely do that. And then they'll interact well with Klotho apps that are also in that same company. So we're trying to make it so that you can adopt incrementally without having to go all in. VICTORIA: So that makes a lot of sense. So it's really helpful if you're trying to swap out those stateless parts of your infrastructure and you want to make some changes there. And then, if you were going to do a data migration, it would help you and guide you to where additional tools might be needed to do that. And at your market segment, you're really focusing on having it be an additional tool, as opposed to, like, an all-encompassing platform. Did I get it all right? [crosstalk 31:07] ALA: Exactly. VICTORIA: [laughs] Cool. All right. Well, that's exciting. That's a lot of cool things that you all are working on. I'm curious how overall the workload is for you two. How big of a team do you have so far? How are you balancing out this work of creating something new and exciting that has such a broad potential scope? AARON: Yeah. So, right now, the team is currently six people. So it's Ala and I, plus four additional engineers is the current team. And in terms of, like, where we're focusing, the real answer is that it's somewhat reactive, and it's very fast. So, like, it could be, like...in fact, Copilot went from ideation to us acting on it extremely quickly. And it wasn't even in the pipeline before that. So I'd actually say the biggest challenge has been where do we sort of focus our energy to get the best results? And a lot of where we spend our time is sort of meta-process of, like, making sure we're investing in the right things. ALA: And I think that comes from both Aaron and I have been in the industry for over 15 years. We don't, you know, drop everything and now switch to something new. We're very both tactical and strategic with the pace and when we pivot. But the idea is when we decide to change and focus on something that we think will be higher value, and it's almost always rooted in the signals and hypotheses that we set out to kind of learn from, from every iteration that we go after. We are not the type that would say, "Oh, we saw this. Let's drop everything, and let's go do it." I think we've seen enough in the industry that there's a measure of knowing when to switch, and when to refocus, and what to do when these higher tidbits come, and then being able to execute aggressively when that choice or decision happens. VICTORIA: Are there any trends that you're watching right now that the outcome would influence a change in direction for you? ALA: Not technically. I think what we're seeing in the industry is there's no real approaches to solving the problem. I would say most of the solutions and trends that we're seeing are...I call them streamlined complexity. We choose a set of technologies, and we make that easy. We make the SaaS version, and it can do these workloads, and it makes that easy. But the minute you step out of the comfort zone of those tools, you're back into the nightmare that building distributed systems brings with it, and then you're back to, you know, square one. What we're trying to do is fundamentally solve the problem. And we haven't seen many at least make a lot of headway there. We are seeing a few of the startups that are starting to think in the same vein, which is the zeitgeist. And that's fantastic. We actually work with them closely to try and broaden the category. VICTORIA: Right. Do you feel that other companies who are working in a similar problem space that there is...is it competitive between each other? Or do you think it's actually more collaborative? ALA: It depends on the companies and what they're trying to achieve. Every set of companies have different incentives. So Google, Amazon, and Microsoft have, you know, are incentivized to keep you on their clouds. They may care less about what they have in there as long as you are happy to stay. So you'll see more open source being adopted. You will see Amazon trying to copy or operationalize a lot of open-source tools. Microsoft will give their...because they are working with larger companies to have more vertical solutions. Google is trying to catch up. If you look at startups, you will see some focus more on developers. You'll see others focus on infra team. So it really depends on the intersection of the companies, and then they either collaborate or they compete, depending on how it affects their strategy. In our case, we recognize that our competition is the incumbents and the current way of doing things. And so we are happy to collaborate with all the startups that are doing something in the vicinity of what we're doing, startups like Ampt, and Encore, and Winglang. And there's several others. We have our own Slack channel where we talk about, like, where we're headed or at least what we can do to support one another. VICTORIA: Great. And I wonder if that's part of your business decision to open source your product as well or if there are other factors involved. ALA: I think the biggest factor that we've seen, realistically, is the expectation in the developer community to have a core that is open source, not even the source available model but to have an open-source core that they can rely on always existing and referencing when, you know if the company disappears or Oracle buys them. And so I would say that that was the biggest determining factor in the end to open-sourcing the Klotho engine. It's a very pragmatic view. VICTORIA: That makes sense. Well, I wanted to make sure we had time to ask one of my favorite questions that I ask on the podcast, and you can both answer. But if you could go back in time to when you first started this project, what advice would you give yourself? ALA: I guess the advice that I would give is keep selling and start selling as early as you can, even before the vision is realized. Or let's say you're making kind of headway towards what you'll wind up sharing and giving companies, the lead time to creating the opportunities and the belief and the faith that you can solve problems for companies, and the entire machinery of doing that is a lot more complex than most founders, I think, or at least first-time founders or, honestly, myself have found it to be. AARON: Yeah. If I try and answer that same question, it's very challenging. I guess my perspective now is there's nothing I could tell myself that would make me go any faster because a lot of it really is the journey. Like, the amount of stuff that we've learned in the last year of working on this and exploring and talking with people and everything else has been so vast that there's nothing I can communicate to past me that would prepare me any better. So [laughs] I think I would try just my best to be encouraging to just stick with it. VICTORIA: Well, that's good. And who knows what you're going to learn in the next year that [laughs] probably might not help you in the past either? That's wonderful. Do you have any final takeaways for our listeners today or anything you'd like to promote? ALA: So, from my lens, I've always wanted to do a startup but felt that the life setting wasn't quite ready. And a lot of the startup culture is talking about younger, earlier founders. I think having had the industry experience and understanding both the organizational and technical challenges, knowing more people, and engineers, and founders, potential founders, has been vastly more helpful than what I would have been able to pull off ten years ago. So, if you are thinking maybe it's too late, it is not. It's probably easier in some regards now. And yeah, check out InfraCopilot. It's on infracopilot.io. We would love to have you try it out and go on this journey with us. AARON: Yeah, I would definitely echo that. I mean, sort of the same thing on the journey. Like, it's never too late to start. And yeah, like, I would say being in the industry and actually seeing these problems first-hand makes it so much more fulfilling to actually try and solve them. VICTORIA: That's [inaudible 38:15]. I'm excited to see what you all accomplish. And I appreciate you coming on the show. You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, you can email us at hosts@giantrobots.fm. And you could find me on Twitter @victori_ousg or on Mastodon @vguido@thoughtbot.social. This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening. See you next time. ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.