Ketan Umare: A project like this has to be truly open for it to get a chance to become a standard. We really, truly wanted to build something that other people can build off and all of us can improve together because to compete with the big four, you need open source. Eric Anderson: This is Contributor, a podcast telling the stories behind the best open source projects and the communities that make them. I'm Eric Anderson. Today, we'll be discussing the Flyte project and I'm joined today by Ketan Umare, who's one of the creators of Flyte. Ketan, thanks for coming on the show. Ketan Umare: Hey, Eric. Thank you for having me. It's my pleasure. Eric Anderson: Flyte's caused a bit of a stir. It's an interesting project and I'm excited to hear more about it. Perhaps you could start us out by telling us what Flyte is. Ketan Umare: Yeah. Defining something in a very succinct way to is hard, so I'll try my best. It's a Kubernetes native workflow automation platform for large scale machine learning and data use cases. What it does really is that different way of thinking about problems for data and machine learning. It tries to essentially make it very easy for machine learning developers to take their ideas from their conception to production automation. It's heavily geared towards productionization and that's has been our focus because we started at Lyft and we were thinking how to productionize everything, especially the complex use cases. The word platform is because it tries to separate the concerns of DevOps and managing machines and so on from actually building machine learning applications, which means it actually includes compute with it and it is Kubernetes tool to achieve computation. Kubernetes native workflow automation platform for error and machine learning use-cases. People have used it for other things, but our focus is machine learning. Eric Anderson: Got it. So, I'm a machine learning engineer I want to build and deploy a model and that involves a bunch of other ancillary tasks, like getting data, moving it around, putting in the right place and I can orchestrate all those tasks with Flyte gathering, moving, munging, but also training the model, deploying the model Flyte's the orchestra for that. Ketan Umare: I think recently that has been more literature on this. I think some people call it CD4ML. Some people call it data pipelines and so on, but essentially what happens is when you, when a machine learning engineer has an idea, they don't really think about hundreds of different things. They think about their idea, which is what you should you think about. I have this cool problem I want to solve using a machine learning model and I think I have on some of the data sets that I need to actually solve the problem. The way they solve it is they actually go, oftentimes either use a Jupyter notebook or Python scripts or whatever, and write the model out. But usually when they're doing this, they don't have access to a lot of GPUs locally or have many times even don't have access to the dataset locally. Ketan Umare: If you're in a company where data is, could be PII data or secure data. The way they go about lending from here is they actually write that one piece of software. Now they have to push it out to a larger scale and probably use GPUs or data that's not available locally. Soon they realize that, oh, I need to mung the data a little bit, transform it into a way that I want to consume it, and so now that becomes another step. Typical way people will write all this in one single application, but if you think about it, just the data processing itself might take a large amount of time, might use [inaudible 00:03:50] technologies Spark and, or maybe better served if written in some other technologies. Ketan Umare: Then it's possible that the model training itself could go for like hours or days, depending on the data set size and the type of model. If all of this run in one process, you have like various failure cases, the data process could fail. Yeah, then you restart. But what if the data processing succeeds, but the training process failed and not only the training process failed, let's say training process succeeds. But now I want tweak the training parameters likely called hyper parameters or whatever, but the data set is kind of the same, but I want to train potentially a new model, so would I do the data processing again? So, these problems that are rising and that's where Flyte really starts fitting in and it starts shining. It's like, okay, let's split these two out. Ketan Umare: In the case, when I redo things, you should just reproduce from an existing older dataset that I created the case of hyper parameter tuning. In case of failure, you should just recover from my last model training checkpoint. All of this is like the encoded principles of Flyte that help users develop more robust pipeline, which inherently also automatically translate into production because you want that robustness and that reliability in production. Hopefully that helps understanding why you need this stuff. Eric Anderson: It makes a lot more sense. Given the additional context you gave it. We said it's called Flyte, but I should note that's Flyte. It took me a bit, but I think I realized that was a nod to its origins at lift. Is that right Ketan? Ketan Umare: Yeah. I will not name the previous names of the project because I still get shivers from those names- Eric Anderson: But those are the kind of nuggets that people come to this show for Ketan. Ketan Umare: Okay. All right. Eric Anderson: Yeah. There we go. Ketan Umare: I was not working on Flyte. We were trying to solve our problem. I used to work on a team called ETA. I lead the team for the model development part of it. ETA at Lyte is essentially the number that you see when you open up the app and, or the fair that gets charged to you when you sit in the car or you're about to sit in the car. Both of them are very, very critical numbers because they play with the user's psyche at a level, you will not trust something if something says five minutes and it never arrives in that time, or you will not like something, if something child you way more than what it should. Ketan Umare: Both of those are very critical from a completely user point of view and also from a business point of view because they affect conversion and the affect revenue. I was responsible for that. We had to build models and we had to rely on them in production because we couldn't do experiments and say like, all right, maybe this will work. That's not how you can employ a production model, and this is Circa 2016. So, there was a dude in my team, awesome engineer, he would run these models by hand. We started calling him model builder, literally, and then came across the project that started to these models. We called that repo model builder, and it was the most insane piece of code that anybody had written because things were done manually and lots of some Spark stuff and it also had these orchestration bits in there. Ketan Umare: It was crazy. Then we added Airflow to the mix and it just kept on becoming gnarly and gnarly, and so that was the name. In about 2018 after Flyte had caught on and it became something, we still used the name Model Builder, still a point. Then we're like, no, no, it's time to come up with a new brand name for this project, and people came up with really, really crazy ideas. Somebody called it Mamba. I was like, why is that even relevant? Somebody was enthused by the idea that it should be a type of music, opera, conductor of sorts, and so Luciano Pavarotti, is that the right name? Somebody said let's use one of those names like Lucian. It was just not rolling off the tongue. I believe that names are something that should just be sharp, memorable, and do not need to define what the project is always because that's why you have tagline, the descriptions and docs and so on, but names should be memorable and easy to remember. Ketan Umare: Then I was like, I just looked at Lyft and I was like, what if we do an anagram on it and kind of say, and our first tagline was take your data for a Flyte and it just fit in. It's like, okay, and that's how we sold it within the company. It was literally in five minutes, we [inaudible 00:08:35] Flyte and that's what we wrote. Suddenly, we got very good response from most people, they're like they loved the name. We rarely got people who hated the name. So, that actually was a good sign and so we're okay. Let's stick with this. Eric Anderson: No, that's great. Good name. Maybe tell us more of the origin story you. I think you said, did I hear 2016 during [crosstalk 00:08:56] Lyft? Ketan Umare: Yeah. A little bit about my background, maybe two minutes, I've worked across multiple different industries. I'm a software engineer for 17 years now. I have worked on banking, high frequency trading, logistics, mapping, cloud software, and then at Lyft, I was doing again, mapping related machine learning because it was ETA and locations and so on, which is all users geography data. When I was working on ETA's and I saw this problem, I was like this, you cannot be doing this. You cannot have people running on their lab laptops and triggering these jobs on a remote machine and monitoring them, and what if their laptop closes, and we go to sleep. Ketan Umare: This doesn't work, this is not scalable. We were a tiny company then, Lyft was a smaller company then, but I knew there were solutions on outside at Amazon, and I was the first few people who started Oracle Cloud and I had written workflow engines at Oracle Cloud, their base engine I was one of the core inventors of that. I was like there must be something out there that are cloud services also. We looked around and we found one open source Airflow, and we're like, okay. There were a couple other Luigi and so on, they didn't seem to fit because they had no real... Ketan Umare: The structure was not modern enough. I think even Airflow, according to me is not modern enough, but still it was little better than everything else and we are like, okay... And I could hack Airflow pretty easily. It's just all Python, and I was like, all right, we can do this. Over a weekend we wrote the first version of whatever we were using at ETA, the model builder. Ketan Umare: That became over a weekend and we were able to deliver things. Actually suddenly people were like, oh my God, my life is so simpler. Of course with the simplicity came a lot of complexity because we started and understanding what do we want to do with this? Oh, we want to ad hoc on things. I actually had a tool internally that called Better Airflow, which took Airflow and hack even more and made it better Airflow. We actually had one of the largest air... We had the largest Airflow cluster at Lyft, the actual data platform Airflow cluster was one, which machine while our cluster was about 50 or 60 machines, because we actually hacked [inaudible 00:11:23], did all kinds of things, made it work. Oh my God, it was blood, sweat and tears really. But at that point we were not really trying to [inaudible 00:11:32] a platform. I didn't want to do infrastructure. I'd been doing infrastructure for a while, so I was like, I don't want to do infrastructure, let me solve my problem. Ketan Umare: But getting that out we realized that other teams have been struggling with delivering their models, and these were massive big teams like pricing, supply chain, understanding the market economics dynamics. Those teams, which are very, very critical for Lyft was struggling to deliver models for multiple quarters. Eric Anderson: This is a common pain point, it seems. You're not a big startup until you build your own workflow engine. Spotify built Luigi, Airbnb built Airflow and you're running into a slightly different problem, which is not only Airflow at scale 50 machines, but also this ML twist, and as you describe to me- Ketan Umare: We didn't know at that point, I didn't know about ML twist, to be honest, I was not really... I was like, okay, it just looks like a work ranger. We looked at the cloud ones, they were just terrible at that point, to be honest. I love step, not step functions, the one before that simple workflow and I had used it in the past, but I was like, it just doesn't apply to this problem. It just doesn't work. The reason why Airflow is successful because it actually, we can say all the things about it, but it has done a wonderful service to the community. The reason why it's been successful is because it found that problem and it solved it. Maybe not correctly, because it didn't know it was solving the problem, but it found the problem. Ketan Umare: It's a serverless orchestration engine of some sort. Weirdly, even if you're not thinking about it runs the compute for you in a set of machines and if 50 people are writing 50 different things within the same repoint and so on, all of the weird parts of Airflow, but it's actually automatically being used for running some compute. Now granted it was always designed to pull things and run things outside of the cluster, but when you have a place to run something, people are going to run compute on that stuff, and not everything needs Spark, many things don't need Spark, to be honest, and not everything similarly needs large, big data process things. So, people start running them and then that's when they start failing over and Airflow just doesn't really handle that very well. So, we discovered that stuff and we made it work for compute at some level because for machine learning, compute is very, very critical. Ketan Umare: It's almost a requirement, and so hence it is not... Flyte is not a workflow engine in the typical sense. It is more of a... I don't think it's a better airflow tool, but what it's trying to do, it's trying to combine, compute with the workflow engine aspects of the stack in a way that it's very cohesive to the user where the user only writes business logic and runs somewhere. You forget about how it's handled, how it's versioned, how all the Spark clusters, how you maintain the queues, how the machines are drained, how Spark machines are handled hundreds of different issues that you get with infrastructure. Our aim is to completely abstract that. At some level it wouldn't have been possible five years ago because we didn't have the understanding of Kubernetes or Kubernetes had not mature to the level that it is today. Ketan Umare: We didn't have... Eight of this [inaudible 00:14:53] did a great service of bringing serverless compute and making people understand the beauty of just not thinking about machines and so on, and then now it's becoming more and more rampant, and I think this is a great use case for it. That's how we found it. Other two teams started using, came to us and wanted to use the Airflow infrastructure that we had used. We're like, oh, oops, sorry. This is not an infrastructure. I built it for my team, and we are barely able to survive with our own team. If I had another team, which is a gigantic team too, we would probably just collapse and crash and burn. Ketan Umare: We decided to take the learnings, and in a month we took one engineer from my team and me, two people, maybe three, just wrote something quickly using step functions, which is a hosted service at database as the pillar for the engine and then everything built around it, which we got Flyte. That became extremely popular in the company and we had about 50 in our team in six months using and delivering models at are rapid pace. Some people actually said that it made it very easy to do stupid things at scale. Ketan Umare: It had a very idiosyncratic API because of using hodgepodge of cloud technology with like cooked some [inaudible 00:16:13] AWS batch. We were the first users of AWS batch. All that just caused a lot of inversions of patterns and made it work, but could not actually deliver the type of user experience that the user should desire. We saw that people are just using it. We started talking to other companies, including Google and so on with the Q4 project, the Q4 project was just a shell at that point, 2017 December or something in 2018. Ketan Umare: We decided that we cannot build this our own. We have to open source it, but we have so much of learnings. If there is something out there we use it, nothing exists it at that point. We're like, okay, we seem to have stumbled on some niche area, which other people are not really trying to work on at the moment. We decided to open source what we have been doing, and how we have been doing it because we couldn't... I don't think Lyft could have built infrastructure on its own and we didn't want to. As a company, that's not our goal at Lyft. Our goal was to be the best transportation network, not be the best infrastructure company in the world. And ROIs, to be honest, it's very hard to justify the ROI in infrastructure investments in companies where infrastructures not the top priority. Ketan Umare: So, we decided to opensource at that point, took us a while because we completely rewrote the version, not for open sourcing initially, but we wanted to rewrite and then we realized we should just open source it. That's when we actually built it for open sourcing in about 2020 January is when we had it open sourced. So, a long journey. Eric Anderson: Yeah, I imagine that it continues to develop along that journey project. Ketan Umare: Oh yeah. The old one was kept on and the new one just slid right in, and the old one we learned so much while doing this, is that like, okay, for example, we had a problem where all of our users were using one provider and we wanted to move away from that provider for running some big data jobs, when we wanted to just migrate that. In a typical world, in many of the software, even today that I see some of the software packages out there, you have to install all the dependency on that provider in your clients SDK. Ketan Umare: Now, if I have 200 teams using me, how do I coordinate across 200 teams to migrate, you just cannot, and this is what Spotify [inaudible 00:18:46]... They wrote a blog last month. In their blog too they are saying that to migrate 300 teams to a new provider, a simple case, it's [inaudible 00:19:00] impossible and do that reliably at scale it's almost impossible. We had that issue and we made it through the learnings, get designed it in a way that we came up with this concept of backend plugins, which is like provider plugins and you want to switch providers, it's a back and flip, switch, flip the switch and the users, they didn't even know. We actually did a rollout 5%, 10%, 20%, 50%, a hundred percent, and if something went wrong, we would just immediately go back and they didn't even know that they actually moved to a new provider, and that itself became... And that Spotify like that part a lot and that they became a major partners with us. Ketan Umare: That was one of the learnings. Another learning was how types are very important in a thing like Flyte, even though it's not obvious, but what you're doing is you're writing functions, let's call them tasks in Flyte and you're connecting them. Ketan Umare: If you take a programming language, you do the same. You write functions [inaudible 00:20:03] connect them in a business logic. Once you connect them, you can do it in a Python like world, which is good, which is really rapid and fast, and it's exhilarating but the way you verify things are good is you run them. Now, if I tell you that every run takes eight hours, then I tell you, okay, go write your code. Then I tell you, there's this another world, you can write the code in C++, Go, Java, where every, at still takes eight hours, but it catches most of the errors at the time when its Java C or GCC compile. As a software developer [inaudible 00:20:44], I want to use this cohort because it'll catch 90% of my errors, which are stupid errors, like, oh, I pass a [inaudible 00:20:50] when I should be passing a string. And because as complexity increase, it just becomes extremely hard to manage and that's why these large programming languages, all in a history have moved from a type to type. Ketan Umare: I was telling some people that it'll punch cards to assembly to [inaudible 00:21:06] all typing. And it's like, okay, that's interesting way of looking at it. Similarly, in Python nowadays typing is interesting and that it is more and more pervasive. We decided that we want type safety. The reason is in machine learning, the processes are extremely long. We want to catch these errors even before you run them. We didn't know how to do that, initially, we learned it across the years. Eric Anderson: This came up on our episode with great expectations, Abe and Kyle came on the show and they were talking about interesting things coming up in the industry. They were like, we've been talking a lot to the Flyte team because they have this perspective on typing. That's really interesting. They're like, basically they're leading the charge on how we bring typing to machine learning workloads. Ketan Umare: Yeah. I think Abe and I have also, with thinking of also writing this more, it's very hard to actually explain it to data people sometimes because we've been used to not thinking about types, but the moment you write software in any other piece, you'll be like, oh yeah types are given. Think about services, untyped services, we had that some time ago. What that meant was send a random JSON to somebody and they will return you a random JSON. You'll be like, what is the use of this service? They were like, yeah, Google the [inaudible 00:22:26] long API or maybe what you call the geocoding API. You send something to it and it tells you something, it's not useful. You send [inaudible 00:22:35] long and it probably gives you the address you give the address. Ketan Umare: It gives you the [inaudible 00:22:39]. It's a nice, beautiful way of describing the problem. It's an inherent way of describing the problem. You have to tell you what the contract is. If you don't do that, then you are, I don't know what you're describing, to be honest, it's opaque and hard to use. We believe that actually that type of description has to happen constantly even in data world and even in the ML world for sure, because the penalty of not doing that is too high. That means it's too expensive for people to learn new systems because when I read the code, I don't understand what's getting passed where who's using what it's too hard to actually find these errors and too expensive to find these errors at a little later in time and it's too complicated to build systems and manage them at scale. Ketan Umare: We think typing just improves this stuff. We actually spent a lot of time designing a type system and Flyte is nothing but just a type system and a way to connect typed functions. Then the current thing that you see about Flyte is an instantiation of that idea. In one form, you can have multiple forms with it and I will leave with that thought. Eric Anderson: I think I understood you to say you're a protocol for a system that can describe typed functions and then string them together, and then you're also an implementation of that protocol, but you could imagine other ways of implementing the Flyte protocol. Ketan Umare: It's an open protocol. We would love to completely open up. It's part of Linux foundation. We should treat it as a separate entity almost and open it up as a standard if people are interested because we have enough research in this area where we found, what are the types that matter to machine learning and data folks. We failed at certain things. We improved them and layered them. We would be open if there is any project out there who would love to reuse the type system, the entire protocol. We would love to reuse them. In effect, we are building something like GRPC. That's what it is. Eric Anderson: Yup. Tell us about the Linux foundation. I forget where in the history that came up, but at some point you engaged with the Q flow team, they were excited about it. Other teams were excited about it. You decided to open source this. Ketan Umare: Yeah. The Q flow team decided to actually build something similar to Flyte in called Q flow pipelines. [inaudible 00:25:06] own because our open source timelines in match up almost and probably some other reasons which I'm not privy to. At Lyft we had donated [inaudible 00:25:16] we had had good success with it and we also actually got a lot out of it to be honest. We could hire good engineers. We could, even though we drove the initial part of the online development, the later parts of online development was actually done in the community and that helped the company a lot, and Lyft positively believe in opensource. We decided to open source Flyte with the same structure goals and so on. It's just that when we open sourced in 2020, the pandemic happened and it was a little tough time for Lyft in the initial parts. Ketan Umare: We lost people and I was leading a larger team and working on multiple different parts and I was getting completely randomized. I'd also spent about five years at Lyft. I was thinking about moving and trying something else. At that point I had two options, whether I wanted to continue working on Flyte and contribute to the open source project and maybe even think about commercializing it, or I could just go to another company and get work on something. I was like this has barely scratched the surface at [inaudible 00:26:30] I owe it to myself to actually give it a little more time, and if not, it's fine, I at least tried. And I had not done much open source much earlier. I'm not a person who's like a big evangelist of [inaudible 00:26:42]. I don't have huge Twitter following. Ketan Umare: I don't do Twitter. So, things like that was very odd for me, but I like the idea of actually building something that had a different take. So, I spoke to Lyft. I was like, okay, I probably am going to leave. What should we do? I would love to contribute to it and you can continue using it. They were okay, let's give it to the Linux foundation. Spotify, I was already contributing to it, and [inaudible 00:27:06] was, and a couple other companies were. They're like, no, maybe it's better to put it... It was very hard to contribute within the Lyft organization, under the Lyft umbrella, so we decided to move it to the Linux foundation. We truly believe that a project like this has to be truly open for it to one, get a chance to become a standard, to really make people believe that we are not in it to actually make... There are some open source projects that actually seem open source, but not really open source. Ketan Umare: That was not the goal here, we really, truly wanted to build something that other people can build off and all of us can improve together because compete with the big four, you need open source, and that's how we decided to give it to Linux foundation, AI and data chapter. My client was part of the decision with the [inaudible 00:27:54] and we were like, yeah, CNFC is not the right place for this because it's too much of infrastructure stuff [inaudible 00:28:03] we want to focus on AI and data portions of it? So, I went to the Linux foundations, AI data chapter. That happened in, took a couple months, but happened in like February 2021. Then earlier this year, January, it was one of the fastest graduating projects. It graduated and it's a top level graduated project. Eric Anderson: And maybe it's worth pointing out as a bit of a sidebar comment that had you opensourced five, 10 years ago. We might be talking about the Apache foundation, Airflows Apache, and you mentioned Spark Apache. That was the place to put data projects, and now I feel like there's a lot of tailwind on the Linux foundation in part, because of the success of the CNCF, and then you're right Envoy went to CNCF, and so that was a natural place for Flyte to go. Ketan Umare: Yeah. Even a [inaudible 00:28:56], which came from Lyft, went to Linux foundation, and we were like... Actually that had happened, [inaudible 00:29:02] and had gone to [inaudible 00:29:03]. We were like, okay, we cannot be putting in random places, so let's just put it in one place. That's how the decision was made. We like the Apache community, we just, when we had a conversation with both, we found a better fit with Linux foundation at that time because of our history and past relationships. Eric Anderson: Great. Tell us where the product headed today. I feel like we got the intro on the history. What's the current state of the project? What are you looking forward to in the future? Ketan Umare: Last year I also started a company to back this project. I think really open source project need companies to help them in the beginning, and even at decent midterm, they need help by commercial entities. We started a company called [inaudible 00:29:52]. Of course, it's a commercial entity. Eventually it does want to make money off of whatever we do. But our goal has been to evangelize and build a product that becomes a standard for machine learning orchestration. Orchestration's like a vague term. It's big term. What we want to basically say is that, how do you run your expert event? How do you reproduce them, get results from them, manage your infrastructure for machine learning and data. That's the goal of this project. I would say that true open source has been the last year and I've learned a lot about open source at the moment. Ketan Umare: Given a chance I would, if it was purely for open source, I would do Flyte very differently. The reason why that it's a big project, it's completely production proven. If you can take it today and manage to deploy it, we can guarantee you that you'll not have a failure. We know that it will work. But the problem is if you realize what I said is manage to deploy it and that's because some of the choices you make, like Kubernetes, love Kubernetes it's required, but I'm talking to some companies and really big names, they don't have Kubernetes used pervasively within the company. It's like for those companies to even adopt Kubernetes is hard. So, sometimes... Other companies it's even harder. Ketan Umare: That would be one of the things, you learn this when you do this, but that being said, I think it's still a big power. I think it is going to be the default of standard. Just a matter of time, when not how. And we think we have a huge advantage of having just five years in the past, working on Kubernetes data ecosystem. We probably, we had a talk at [inaudible 00:31:37] which talked about using Kubernetes for [inaudible 00:31:40]. So, 2500 people attended, because it was one of the first talks that anybody had ever done and we are like, we are one of the first people to have done it. So, that's great but when you're one of the first people to have done it, you go through all the failure possible modes to reach a solution and those are the things we learned. Ketan Umare: But last year, I think what we have seen is our choices and our decisions have helped a lot and a lot of different thought leader companies are realizing that, and they're joining us [inaudible 00:32:11] with Flyte and which is fantastic, even as a small company for [inaudible 00:32:16], that is great because it's just means that we are pushing with the thought leaders, essentially getting all the brains within the community to work with us, which is great, which is what we always wanted. The project has, at least I can... The numbers, what I can tell you is 20 plus production deployments now, arbitrary large scale, like the other day I saw a company and we have all these presentations on YouTube and so on, and definitely check them out. One company is building a biocomputing platform on top of another company is building a full geomachine learning mapping platform. Ketan Umare: It's a digital twin of the world using satellite images and machine learning and this is what is used in Microsoft simulator and other places and it's like a fantastic problem to see all that happening on top of Flyte is just amazing. I was telling you about Spotify, 300 teams in Spotify, and we talked about Luigi a little bit. They're giving up on Luigi and flow and all of those pieces for Flyte. So, Flyte is becoming the [inaudible 00:33:26] orchestration at Spotify. It's been amazing for us and we are grateful. The community is built with some values. We truly value inclusivity and here I mean beyond gender, race, et cetera, it's what I mean is knowledge inclusivity. What we've realized is that in the machine learning and data space, not everybody knows Kubernetes or [inaudible 00:33:54] and so on. Ketan Umare: What we are really trying to say is that don't be afraid to join the Flyte community and ask questions. You will find somebody, there is always somebody who's ready to listen to you and help you with something, and that's how you build a strong, inclusive community. So, we are good. We are closing in a thousand people within the lack channel. GitHub starts are interesting. None of ours, another analysis that was doing is 500 people at Spotify [inaudible 00:34:24], with 600 people at Lyft and are total [inaudible 00:34:25] stars are 2000 out of which only 1% is Spotify and Lyft people, for example. I don't know what the GitHub star measures, but one thing it measures for sure is that how much awareness there is, and that's on us to actually improve the awareness and this year, we really want to improve awareness and bring Flyte to anybody who don't be afraid of the platform just come in. I think we are working very, very hard to make it extremely accessible to every player out there. Eric Anderson: That's awesome. Thank you so much for all the community work, the typing system. I'm just thinking back act to our conversation with great expectations. It's very apparent that you're focused on community and technology and solving the problem first, and then trusting that with success on solving the problem the business will succeed on some level and future. Ketan Umare: Yeah, I think the reason for Union AI's existence is to actually to make it even more easy to achieve the same level of things that larger companies with more resources can do. Think about us as your infrastructure partner, really that's what it is. There's a clear weirdly as in investors speak Flyte is very up market. It's really built... It's adopted by up market teams, lots of deep technological expertise and so on, but we want to be union that the SMB and the down marketplace to help essentially everybody else create the level playing field. Eric Anderson: Ketan, thanks so much for coming on the show today for all your contributions and best of luck. This is quite an awesome thing you're building. Ketan Umare: Oh, thank you so much, Eric pleasure talking with you. Eric Anderson: You can find today's show notes and past episodes@contributor.fyi until next time I'm Eric Anderson and this has been Contributor.