HN818: Introducing LIM: A Large Infrastructure Model for Multi-Cloud Terraform Migration (Sponsored)

0:00Welcome to Heavy Networking, the flagship podcast from the Packet Pushers Network of Fine Technical Content for Engineers. I am Ethan Banks with Drew, Conry Murray. Please follow us on LinkedIn and the Packet Pushers Community Slack Group, PacketPushers.net slash community. If you'd like to join our Slack, like thousands of others from around the world and on today's episode, Cloud Portability. We are chatting with sponsor Fluid Cloud about how their product can discover your existing cloud environment and then recreate it in another one. For example, you could move from AWS to Azure or Azure to GCP and there are other situations Fluid Cloud can help you with too, such as migrating off of VMware. Fluid Cloud is a robust product. It does a lot and it's not simply for one-off migrations. And so to get into the nuts and bolts of Fluid Cloud, is Sherrod Kumar, CEO and Harshad Omar, CTO. They are both co-founders and we're going to chat with them about not only what Fluid Cloud does, but how it does it. And along the way, we're going to cover Fluid Cloud's large infrastructure model. This is an industry first that they have launched this month

1:04in March, 2026. And guys, there's a lot of very cool stuff going on at Fluid Cloud. We had a planning call with them a week or so ago and started digging into this. And this is one of those conversations where the deeper you go, the deeper it gets. And so there's a lot here to be interested in. So Sherrod, first question goes to you. Would you give us the 10,000 foot overview of Fluid Cloud? Hey, thanks, Ethan. Thanks, too, for having us on this podcast. So 10,000 feet overviews, primarily, the reason we started Fluid Cloud was to break free people from vendor lockings. Right now, the way all this while the industry has been practicing is a hyper-scaler or a cloud provider will provide you tons of credits. You get into the cloud provider and then you start getting yourself locked in. And after that, as the bill starts getting coming, just kind of the pain starts increasing. And that's where I think we wanted this

2:09industry to be vendor lock-in free because we felt this pain ourselves. This is our second startup and third company together. And when our previous company was acquired, it took us almost eight to nine months to move from AWS one account to another account. And given that was the pain which I kind of personally felt, Harsha personally felt, at that point in time, we were like so much yearning for some automation across that. And then Hashi got changed its business source license. Most of the people started moving her open tofu. And then Big Bang, the VMware acquisition happens. Then if the whole industry decides off 80% of their industry decides to move away, okay, bye-bye, Mr. VMware, let me move somewhere else. But who's going to do that? It's like all the consulting companies are there. But the whole pain, the manual pain is so much. And that's the reason we started fluid cloud. Another thing of what we do at fluid cloud is we also

3:11have, so when is the purpose of building the company, which is the value of the companies to actually break free enterprises from vendor lock-in. And we are also proud of our foundation, which is fluid cloud foundation. We always believe in giving back to the community. We have taken a blind school as an undertaking. But we always contribute 5% of whatever we are getting as revenue to the blind school to develop the assets for the blind schools for the blind kids. Because one thing which we have realized is they have a vision disability. They don't have a learning disability. So they can go long way if right assets could be provided, right infrastructure and resources could be provided. So yes, it's like it's not just building on one side, on just one industry, it's like also getting back to the community. So we're talking public clouds and I think Ethan mentioned AWS and

4:16Azure as examples. Can you tell us the public clouds that you support where you can help with migrations? Yeah, absolutely. So we currently support almost 10 cloud providers today. So we have AWS, GCP, Azure, OCI, VMware, OpenShift, Nutanix. Now, yeah, Vulture Cloud and Hyper-V. I know VH. Yeah. I know VH, yes. I know VH as well. So and the whole premise of this was as we kind of got, first we started with kind of a new cloud where I think because we could cover 100% of the services for the new cloud from all the cloud service provider to the new cloud. And then as we started seeing the surge of sovereign cloud, OVH became one of our partners. And sovereign cloud is one of the big things which is there in Europe and also other countries given the current geopolitical scenarios as we all know. But and then I think as we started

5:21talking to hyper-scalers with the VMware exit, we started talking to Nutanix. There are a lot of things which Nutanix move does, but there are a lot of things which it doesn't. So that's where we come in and help bridge that gap. And then once we started talking to hyper-scalers, they were like, wow. Now one thing which we have to also understand all these hyper-scalers, they have hundreds and billions of dollars of backlogs. They have got the bookings, but to recognize the revenue, you need to move. You're working with consulting companies, and they work on TNM basis, time and material. They get built, the more complex the problem is the longer the project is. And the hyper-scalers wanted to move quick. So that's where I think we found this very good. And I want to add a few things. So first of all, when it comes to public cloud, as every developer, they want to try out new things. I've been stuck with AWS from past 10 years,

6:22and AWS is the slowest in doing the innovation. If I have to spin up some GPUs, I have to wait literally nine months. Why would I have to wait in AWS for nine months to get my GPU to comments? I can deploy things in GCP, they are giving something. There are new clouds coming up. Vulture cloud is going crazy. They're giving you so cheaper GPUs. But in order to use, take advantage of that and use that. I have to deploy my Kubernetes clusters. I have to convert the firewall rules. I have to convert the permissions. It's a nightmare. One of the reasons also adding more support to the public clouds is try out new innovation, new workloads, which may be better. Why you stuck with one cloud? Okay, hang on a second, because there's a lot of difference in the platforms that you guys have described. We've mentioned VMware and Nutanix and the same breath as we've mentioned GCP and Azure and Vulture and so on. These are

7:24different platforms that have different emphasis and capabilities. So how are you? How is all of that coming under your umbrella? So yes, that's a great point, Ethan. And in fact, there's always been a norm that there's all the way you do things in a private cloud and on-prem and that the way you do things on a public cloud is totally different. What fluid cloud has done really reduced that abstraction and came up with a hypervisor on a hyper scale. We have literally reduced the boundaries between public and private clouds. So think of like this, if somebody's using VMware, all you're doing is spinning of VMs, you have some base hardware and you're spinning of VMs, you're setting up the networking, you're setting up the firewall rules, right? Which is the same things those services available as AWS native or Azure native network security groups, virtual machines. Okay. So now people do understand there are similarities. It's just matter of provisioning. How do you provision it?

8:27And when you try to provision, let's say creating a VM in VMware, you need to have a cluster, you need to have this, you need to have that so many dependencies, right? When you spin up in Azure, you need to create a resource group, you need to have a network security group, you need to have a virtual network. So that's what fluid cloud brings abstract and infrastructure running anywhere, convert that into anywhere and we give you the teleforms. Okay. So you figured out, we have that the basic needs are common across the platform. So as long as the platform can deliver that basic need, you've got and however you just said abstraction, you were abstracting away the specifics and just delivering that to use, to use a term common to networking people, intent, you're delivering a specific sort of intent into into that cloud environment. It kind of, we also go ahead and create a provision. It's like a translation, right? Like a VMware configuration translated into new damage or into AWS, you can think of like that.

9:33So you're saying, if I've got a very complicated application set up in AWS and I decide for whatever reason I want to move that application workload to an entirely different cloud, you take all of you essentially map all the services I'm using within AWS, figure out the infrastructure as code, logic, and what you would need to actually duplicate that in Azure or whoever. And you provide that to me so that then my death can just sort of like copy and paste. Oh yes. Yes. Exactly. The way you said true, that is exactly how fluid cloud works. That's a copy. Okay, but there's limitations here because not every platform has the same capability. So AWS has a zillion different platformers of service offerings that don't map one to one to other clouds. Azure's got an enter ID and so on. So how do you deal with those situations where there isn't a mapping? Okay. So first of all, that's fair point. If something is not there, which is not possible, human by like humanly is not possible, we cannot do it anything like. Let's

10:34say, for example, somebody's moving from AWS to WorldChill Cloud and he's using Cognito in AWS, there's no Cognito alternative in WorldChill Cloud, right? Somebody's using Open Search in AWS, there's no alternative for Open Search in WorldChill or in OVH or in GCP, right? So the thing is, it's a decision which developers have to take in what, how much deep or how many cloud native past services I want to use. Like there are some infrastructure as a service offerings, there are some platform as a service offerings, like authentication service, email service, managed Kafka, those might not be available in all different clouds, but as long as infrastructure as a service offerings are there, those are standard, pretty standard across all the clouds. And to, in fact, we got you covered for paths as well. Let's say if there is an alternative in the other cloud, we can convert that as well, because that's how DevOps guys do. That's what DevOps

11:34guys do. They just go ahead and provision those services, right? So you would require a GCP expert to deploy things in GCP. You would require an AWS expert to deploy things on AWS. Where's the connection between? Flute Cloud can still do that. It gives superpowers to the DevOps. So are you actually exporting this infrastructure as code in a language that developers might be familiar with? We give Terraform for you as well as the state file. So no matter how the resources were provisioned, we can just scan it and give you the Terraforms as well as the state file with that. So and once it is there for that source cloud, you convert it to a target cloud of your choice and give you the Terraforms for that as well. So what else do we do? We do these conversions in micro-milly seconds. It just happens in like a flash. So one of our code patterns is also like

12:37scanning. So it just doesn't matter how you have provisioned your cloud infrastructure. You could have used click-ops, chef, Ansible, Puppet or CLI tool or whatever. Peace can your cloud APIs and generate the Terraform for it. But we do that in the record time. One of the best CSPM tools in the market to scan 100,000 cloud resources. It will take one hour to seven hours. You will take one minute, not more than that. Okay, we got to get into this in more detail. But I got a couple other background questions first. In one of those use cases. So when we were chatting with you guys before we recorded, one of the things that came up was, was, hey, okay, the obvious use case for us is migration. You're going to pick up and move to another cloud and we're going to make that really easy. But that's not all fluid cloud is about just picking up and moving from like a one-time migration. Some people do that, but that's not, that's not even your primary use case, I guess, the way you guys describe it. What other use case is? How else are customers using fluid cloud? So the thing is, it's a deployment. It's like,

13:45it's a cloud cloning. You want to create a copy of your infrastructure to somewhere else. Now, we can help in the migration. We are not a migration tool from one cloud to another. Yes, you can do that. In case of tenant sharding, right, you have a multi-tenancy architecture. One big customer comes up and says, hey, I don't want my data to be shared with my other with your other customers. Please set up a separate environment for me. Now, you have to replicate that same a separate deployment for that customer in the same account. So or in the same provider from one account to another account or maybe you might have your dev and stage in different accounts and production in different accounts. So you might be moving within the same provider or in terms of compliance and data residency scenarios where you have to replicate the resources from one region to another region in the same account. So you can even go crazy, like select one region and to a different region and change provider or don't change provider. It doesn't matter. In fact,

14:49we can also help you with some kind of a rollback scenario. Imagine a DevOps has a complex deployment where five different terraform files runs and then after that Kubernetes deployment happens, the API deployments, we have multiple state files. One bad deployment. How will you roll back? You need five rollbacks because there are five deployments happened. Fluid cloud can combine all those into one state file. We can give you all that combined into one terraform file. So you can really copy, select two different applications, bring that into one state file if you have to roll back. Super easy. It's basically version control for your entire cloud infrastructure. It's something about that I was thinking, this would take a lot of data and this and that and not really. It's just state files. I guess there's a question of, do you guys also deal with the data that is living in my cloud or just the infrastructure hole that all of that lives in,

15:54if you will? No data. It's only the infrastructure. You don't need to understand what my workload is doing. You just need to understand the configurations around it. These are not looking at data. Okay. Exactly. And then it isn't. So you wouldn't, you're not a backup and restore kind of product either. There are not so far terraform for your infrastructure. In fact, I'll give you a crazy situation, Ethan. In case of an outage or in case something happens, something bad happens. It BCDR strategy. People are not able to come to an RTO or RPO in minutes. They might have the data backup, but in order to spin up the critical services again, as a backup in a different environment, right? That takes hours. So RPO can be reduced, but because your critical services are not spinned up, your RTO itself is in hours. With the fluid cloud, you can literally have RTO reduce down to minutes. Because I've essentially got a backup of my infrastructure, sort of waiting to go. And if, say,

17:04cloud provider one goes down, I can launch this into cloud provider two and spin up that application to get it back online. Exactly. That's correct. And if you recently cover the Dota compliance, which is digital operational resilience act, which started in Europe for primarily financial institutions, one of the most critical component of that is if the whole provider goes down, what's your backup and restore strategy to go into nothing. So you have to throw a lot of bodies into it to maintain that kind of posture, which is now could be automated through using fluid cloud. But again, to understand, sort of the problems yourself, I can get that infrastructure, all those infrastructure configurations into cloud B. But I assume you're not handling the DNS reconfiguration and redirecting all that traffic to cloud Bs that someone else. That would be a separate startup. Someone to look. This is really no solution for it. Yeah. So to the listeners,

18:04we have a sort of idea, right? Okay. Or you guys licensed. We licensed. So we charge you based on number of resources we discover. So in your cloud infrastructure, you might be using various services like EC2 security group, I am your 100 EC2 instances, 50 security firewall rules, 100 VPCs. Everything becomes an asset. It's a cloud asset resources. We discover a resource that becomes you get resilience, right? That resource is converted into every other cloud provider we support for you to always be ready to deploy and convert into Terraform and do the provisioning. So we charge you get per resource level and it's a t-shirts like pricing here. Go ahead, and you can do unlimited migrations, unlimited movements of infrastructure. So we don't restrict anybody on number of cloning. You want to do and we don't call it migration because migration

19:07is you're taking here and putting it there. The reason we call it cloning is you're just cloning it and it exists in both the world now. It's almost like a visit to end. So you can do unlimited cloning. You can do unlimited within the region for your accounts or from cloud provider to cloud providers. And I think as soon as people have started plugging us in, as few of the customers we've already started seeing the result, as soon as they put us in within like one or two months, they're immediately able to see 5 to 10% reduction in the cost even if they're not changing their cloud provider. If they change their cloud provider, it's almost goes to 30, 40 or maybe 50%, depending on a cloud provider they choose. But just within the cloud provider also, they're able to see 5 to 10%. For example, if something is in the US, the best one, they want to go to US East one. That's itself is like a 10% reduction in your cost. And then you can do that in minutes.

20:09It's literally in minutes. So are you saying that in addition to understanding all of this infrastructure, you're mapping it to how it's being priced by that cloud provider and other cloud providers and show me that? So yes, interestingly, why would somebody use infrastructure? There's a whole ecosystem around infrastructure. You have resources, then you have a lot of phint ops tools which give you cost estimation analysis of there are a lot of security tools which give you security analysis and fixing stuff. Now, when you have that infrastructure, we can do that cost analysis and security analysis as well. Now, using our mapping, we scan your AWS account, convert that into Azure and we do the cost analysis of Azure. So convert that into GCP, do a cost analysis of GCP, convert that into OCA. So you have an active infrastructure running on one cloud which is AWS and we give you exact comparison how it looked like in Azure, GCP, OCA. It's really like a multi-cloud

21:12cost comparison. And you can really go deep, see each instance is how much that is going to cost. Each volume how much that GB of transfer will go is going to cost me and all those cost factors into the product all by itself is just as scanning your environment in that 60 seconds, give you telephone, give you cost analysis, everything. So it sounds like you have a pretty straightforward ROI story, then people invest in this product. There is an economic analysis that happens that means the product can more or less pay for itself. One of the also reasons is people are frustrated with consulting companies. They take times. Are they? Oh, I have so many friends. I can speak yet, it's recorded, but there are so many people, they're frustrated with consult because they just do a dump, just take all those things. I generally give that example. Have

22:15you ever seen in my home when I was in bachelor in my college? Clothes in the cupboard was always never folded and you just take all that grab all you can and put it in another cupboard. That's what consulting companies do. People want control. People want their shirts folded and put away. They don't just want a big laundry plow. They want an automobile folding their shirts. So it sounds like you are getting deep into my cloud environments. How are you getting this information? Where does it go? How are you storing and analyzing it? This is very flexible. Users can choose where they want to save their data. We can put it into your history buckets or you can use R. We deploy in RSAs. You can use RSAs or we can just give you your private deployments and stuff. So it's fairly flexible. But as in now in configuration data, if we have a database, it's RSAs, which is replicated in

23:20five different clouds. So we have an R.D. or R.P. in like Italy, 15 minutes. The whole area is down. We can come up in 15 minutes, less than 15 minutes in Azure. Oh, that is if the whole point here is to make sure I'm not victimized by a cloud outage, I don't want my fluid cloud platform to be victimized by that state and cloud outage. So you spread the spread things around. Yeah. So one of our POC was just from the largest cyber security company in the world. And while we were doing that, they said, what if you go down? They're like, yeah, that makes sense. So now we are like kind of parallel, active, active, and five cloud providers at the cost of backup and restore. So this was a requirement from one of the customers. But again, how are you getting that data? Are you just making API calls into my infrastructure? What level of permissions do I need to give you to get that data? So are that information? Yeah. If these are standard API calls, each of these cloud providers

24:21have standard documentation and it's you can just get all the things done with just the read-only permission. So we cannot, fluid cloud cannot make any changes. If you want, fluid cloud can make a lot of changes on your infrastructure, make it more resilient, make it more optimized. But if just read-only, we can always generate terraforms and people can get the ICD pipeline separately. Do I have to do anything more than point you at my cloud with the appropriate credentials and you do the full discovery? Do I have to do more prompting, give you more clues as to what's going on and what to look for? No, everything is automated. Zero friction, zero, like just give me read-only credentials and that's it. So everything ends with yeah, when we started with this whole journey of multi-cloud, the way I wanted this to happen was the way you book an Uber. That's like not more than three clicks. So exactly the way we wanted this as well, like scan, convert and deploy. So like can do scan, convert and then you can analyze

25:25your terraform script and then you can deploy. So scan, convert, analyze and deploy. So we just have the analyze button which is more like is the price is right from a Uber, can I choose comfort versus black? So that's what I have to choose. Let's get into the nuts and bolts of how you guys are doing your translation. Now we've said okay, it's going to end up as a we're going to discovery, it's going to end up as a terraform state file and then we have conversion magic that we do that can can make that existing state file into a different state file for a different environment. How what's going on under the hood and I think along the way we got to talk about your large infrastructure model this new thing that you guys have announced because I believe that's a pretty important part of the story. Yes. So first of all, the conversions all the as a as a as a city and as a developer, I am very skeptical about you know what AI is generating my code and when it comes to infrastructure, there's even more skepticism and we wasted around four

26:28months to try doing this with AI. So like okay, we don't approach exactly. We have tried almost every LLM model you can think of but no success. So what you will probably had some success but there was just enough errors and problems that it wasn't worth pursuing further. Zero success. I'll tell you the low of conversion was in terms of accuracy, it was less than 10%. Oh wow, okay. And these we are talking about the biggest of the models, biggest of the models which are the best in coding. Less than 10% success rate. So did you tell like manually do one-to-one mappings by hand essentially or how did you exactly so what we did so just like I explained right there are various services as a DevOps we would know how would you configure an EC to instance in AWS.

27:28You will given VPC ID so before that you have to configure VPC in order to create VPC then you have to create an account, create a user, create then create a subnet, create a security group, give a file like inbound rules with IP address and port. The same way and then if a DevOps has to replicate that in Azure you do the same thing you create a resource group, create a virtual network, give a private IP then you know create a network security group with source address. Now in order to do the translation we went resource by resource service level mapping like this service EC to instance is an equivalent of Linux virtual machine in Azure is equivalent to compute engine in GCP is equivalent to OCI instance in OCI. So there is a service level mapping then next level is the attribute level mapping like for example in order to define an instance type the attribute called is instance type here here it is called VM size here it is

28:33called something else. So there is attribute level mapping and then finally this value level mapping which is because these cloud providers is not going to make your life easy give if you want to spin up a VM with the two CPU and five or four GB RAM you know you cannot do that straight forward you have to define T2 medium or Vivec flash like I don't know I can never remember which class of and I have to all the doors guys they remember all this class but when it comes to Azure right it's even weird like standard BS one standard BS two I don't know what does that mean when it comes to OCI it's even E4 standard E4 it's very weird right and everything translates to certain CPU and config so the idea is service attribute and value it's a three level nested mapping you need between all the cloud providers and that's what our patent is

29:34where we have developed ground up we built it around and it took almost more than a year one year yeah we started in August 24, 2024 August and by the time I think April 2025 we were able to add support for 30 services across AWS Azure and GCP and today we expanded that coverage to around 130 services across AWS Azure, GCP, OCI, WorldCero, VH, Nutanix, VMware and like that so now the large infrastructure model concept sounds like large language model so is there an AI tie into this concept does it behave like AI or is it trained like a model like many of us have become familiar with when we think about LL labs I mean in terms of experience you'll get the same experience like and you're talking to an LLM but behind the scene it's not an LLM it's a ground up built purpose built machine learning algorithm which we have trained it based on our data

30:44which we using our mapping and stuff so obviously there'll be an LLM which is in the initial interaction to understand the user intent what you want to buy the front end I can say in plain English I want to I want to convert this environment from yes you know this cloud to this cloud or whatever some plain spoke can request that that gets parsed and then handed off to the the LLM but that isn't the LLM but you've built as you said it's a machine learning trained must yes so we have trained it over I think a 9 billion tokens of data and that's that's a beta launch at the moment and we are seeing a lot of you know advantages with that because with that what is going to happen is we are able to show you a compatibility score like imagine you are using AWS Aurora DB and the whole day it looks like okay this is just an RDS right I'm using database

31:46service for AWS but if you want to go that database service in Azure good luck with that because there's no Aurora DB you have to convert that into pro's grace yeah so internally it what we have done is we're using that mapping we are able to give you a compatibility score so we scan your environment and we give you a compatibility score against various services to each resource level to each map attribute level and then all the way grouped by the whole account compared to other clouds so maybe it will help somebody like okay as a company you know executive I'm thinking to go to Azure but take a look at that compatibility score you have a low compatibility score with Azure try gcb that's a better choice you have more success of migration so that's a very good you know use case which we are able to come up with the help of all I am actually yeah so I can tell you one thing the way even like the way AWS if you want to go to like from any cloud

32:49provider to AWS the way AWS looks at it or even on prem it's SS mobilize and migrate the one which is SS that itself is this whole compatibility thing which they give it to a consulting company and they will cost from the source to destination that takes four to five weeks or maybe more than that so that you always is readily available that how multi cloud ready you are so just from that perspective I mean there is no extra dollar any like even hyperscalers have to spend at this time as this tool is getting used what is the appetite for actual migration because it's you know not just the hassle of figuring out how to map a workload from cloud a to cloud b there's also cost associated with doing that data migration that's where in a lot of cases the cloud providers get you oh you want to believe okay here's the exit fee

33:49so it's great that you can make it easy but if I'm going to get hit with that spend and most organizations are now sort of multi cloud already what's the impetus to drive what's the value of doing a migration I mean that's a great point Drew and most of the times this this is something in awareness you know we we are trying to spread across because the data egress and ingress charges are not you know in every cloud only AWS Azure and GCP in fact if you go to OCR so when people those who are multi cloud they should choose one particular provider where they're going to recite the data so that to avoid those data movement there was a huge backlash from like when from the government when data egress charges were super high so they lowered down and then AWS and GCP partnership happening I don't know where where does that go but there are solutions

34:56and work around you can actually always create a private tunnel to avoid data egress charges between the clouds so the only reason why I would somebody stop using is basically the engineering effort of I owe I have to understand OCI first of all OCI has the worst terraform syntax somebody can think of okay I mean it's very hard to learn one particular cloud provider and to become an expertise and that when you are given with a terraform syntax which is very rarely you have a attribute which is like 50 character long like you can't even see in that screen you have to you know need a bigger monitor yeah so to understand the terraform to write those terraforms not any model is able not every model is able to generate that terraform and that's a huge gap for DevOps because if you see the DevOps they always want to make any modification with the infrastructure

36:01either to you know make changes on three factors whether it is reducing cost adjusting your cost or if you are fixing some security or you're increasing the performance so think of it like this RGB different weightage to different you know color gives you a new color these three patterns cost security in performance give different weightage to these factors gives you a new infrastructure design pattern okay so that is the basis of the LIM and which we are able to give to the DevOps they can take advantage of yeah as a part of the tool be already support almost 1300 policies right out of the box for all the cloud providers you mentioned all the 10 so this is also one of our core patterns it's omega-1 policies can primarily we have the the cloud security posture management built into the tool so we can give the compliance code for gdpr gdpr pci dss swap to hepan nest or the any benchmarks which the customer wants

37:09not only that we also give a remediation like if there is there is a there is a misconfiguration on a particular side of the infrastructure as code we actually give you the right recommendation and if you allow us we can actually we can auto remediate it as well and give you the right deployment script huh so you're saying in addition to showing me cost comparisons and so on you can also help me um security side on the security side yeah oh yeah that's correct yeah so it's like an RGB when we call it it's security cost performance we truly mean like security securities like uh beyond this there is nothing much which is there on the cloud security side our previous company was acquired by tenable uh and where we have learned a lot of we have like we learned a lot of things on the cspm site uh like we did really great things there there were things which you could have done better which is done at best today

38:13now we said earlier on that blue cloud does not handle the data migration portion of moving from one cloud to another um so how do your customers typically deal with that do you integrate with tools they might have that would help them with that or what's that process look like once they've used blue cloud to get that infrastructure whole ready to accept data oh yes yes there so each of these cloud providers have some kind of a data migration tools uh which is great um and this becomes very complimentary uh fluid cloud becomes very complimentary to these kind of solutions so using fluid cloud you can create a landings on you can create a bare shell infrastructure and then move the data create your data pipelines using those tools so think of it like this we have you have some hundred s3 buckets in AWS if you are going to Azure you can create 100 storage containers in Azure then use the Azure AZ copy tool to just move or there are hundreds of open source

39:14tools in fact these are these cloud providers have an s3 native uh you know s3 compatible APIs just give us the source s3 bucket and then we copy all the data automatically so the provisioning the understanding of that infrastructure that's where we're in order to create an s3 bucket in order to create and storage container you need to understand Azure by no permissions and other stuff which is not at all related to that and that's where the majority of the time goes so i'm getting the sense you know you can uh sort of map or match you know sort of the compute in the RAM and all of that from provider a to provider be what about the networking environment because that's where things can get really complicated with vpc's and routing and load balancing and ip seconds so on how good are you at doing that kind of mapping and clothing so we we take care of all those infrastructure cloud native services and map it everything including networking storage iam permissions compute everything i gave an example of an easy to instance with

40:21a recipe and map that is one of the configuration one of the property of that service but really if you go deeper there are tags there are you know encryption settings there are snapshot settings there is so many permissions there are people creating custom permissions and stuff there are networking like no credential chaining where it automatically assumes the role if the Kubernetes cluster is and the s3 bucket in the same account you don't have to give an permissions now how would you configure the same thing in Azure so taking care of the networking we go ahead when we scan we actually not just can give you the infrastructure footprint we also take care of the dependencies what service depends on what what is mandatory what is optional and we bring in all those how would you convert that manually we take care of that taking care of the design patterns and give you that so to give an example if you have to create a you know public subnet you know if you have to make an

41:24easy to instance public so what you typically there's in you know you create an easy to instance attach it to a vpc and then have a private subnet and a public subnet now how do you do that and Azure you create a Linux virtual machine attach it to a virtual network then which virtual network has private IP then you create another public IP and then do a vpcp hearing alternative in Azure so we do that conversion so because that is the way you deploy things in Azure so taking care of the networking in another example in Azure you can define deny rules like in security group I can give an IP address a particular port and I can say deny any request comes to this port from this type source IP deny the rule but you cannot do a deny rule in AWS how would that get converted into AWS so we do from source so any other IP addresses

42:24except that port is allowed that's how we convert it which looks very crazy in terms of the rules in inbound rules if you see there will like 10 different rules that coming up but yeah that is the only way to do it one of the thing I would like to mention is most of the listeners also was stuck with VM there one of the biggest issues they would face is moving from NSXT if they're choosing from an NSXT to flow on Nutanix or NSXT to the the native for the networking in the cloud service provider we also take care of that in fact at this point in time as we actively talking we are partnering with Nutanix and integrating our tool from a networking conversion perspective into their tool called so as we talk about it many of the listeners who are more stuck

43:28on the networking side on the VMware we can help them out where we can do these conversions it actually takes a couple of months to do that with the God level expertise also takes a couple of weeks we will be able to do that in minutes using this tool so is this in an on-prem environment it doesn't have to be public cloud if I've got on-prem VMware and I want to migrate off I can do that or it could be either it could be either it could be you know managed VMware on a cloud and would be on-prem VMware so it just doesn't matter for us we'll treat it as equal okay a couple of other things to explore here one of those when we were planning this show you talked about a scenario where some customers of yours maintain an active active data center across clouds and they use fluid cloud as a way to mitigate that risk of a cloud outage how does that work what's going on so it's it's pretty simple it's a three you have an infrastructure running on one cloud scan using

44:32fluid cloud convert it into another cloud do the telephone deploy and now so you have two different Kubernetes clusters two different databases everything running twice right now what about the data you can always have a Kubernetes job to synchronize the data every 15 minutes or you can use people use you know distributed SQL like you abide or you know spanner you know those things automatically do that where there is a primary database and secondary database all get synced the services it's the services how you access that data using fluid cloud you can convert that infrastructure and have a turning so now what happens is you have an standalone application one cloud exact another application running in another cloud both are getting synced in like whatever you want every 15 minutes every 30 minutes and stuff now your DNS will resolve to one load balancer at a moment if something happens you have to choose the DNS so that's what I

45:35said that's a different start of do so I wanted to talk so it's okay I would because I would describe that as like an active standby your data center but it's replicated in near real time assuming I've got my data synchronization going keep my DBs in sync and but then I mean man as far as a disaster recovery business resiliency sort of a solution that's awesome I can just I can literally cut DNS over and I'm ready to go I might be behind one sync rev yes you on the database side depending on how I've chosen to done my database or I might be you know exactly replicated in real time and and ready to go to okay so I can maintain that environment that also means oh okay so I changed something in my primary active data center you're going to pick that up as fluid cloud and replicate that to my my other data center environment too so I'm always in sync between the two environments absolutely that's a good problem that's another feature

46:37we call cloud sync in fact this also comes up with let's say not somebody would do multi-cloud active active right as a start of we developed an Azure or we developed an AWS solution my customer wants a solution in OCI or in solution in Azure how do I do that so customer deployments yeah more I mean most of the startups they face this we always hear that hey we would like to have a you know air gap deployment and be use Azure and currently you guys are an AWS why don't you move yourself into Azure that's a two three months of effort keep the whole refactor move into another cloud and then go for it it's like guys you don't have to do all of this just sign me up and then we should we should we should be fine like we can actually do that in like real time out like in a day start less than that but that's how that's how that's fast that's how as fast as it could get one gotcha here which is let's say if my application is using a cloud

47:45native services right I'm calling S3 packet APS I deployed that in Azure but I'm still calling S3 packet API right because application logic is not changed so that is something somebody has to do manually to change that to now start using Azure native but we got you covered we have a portable SDKs so you have to just use fluid cloud S3 bucket and your infrastructure is pointing out to AWS we'll call the API S2 AWS S3 bucket if you change deploy to Azure just change the environment variable to Azure and then we'll start calling the Azure APIs for you so your application is literally zero code change it's almost like a building a super cloud so you know every time AWS has its conference it rolls out like 500 new services so high-least how do you guys keep up what's sort of the differential between current capability and

48:46whatever a cloud has just released yes I can I can start with that answer so let me start with OpenAI OpenAI came up with a ton of features like every single day it's like hey I have this integration I have that configuration but again you have to just narrow it down the user is using it for can you rewrite this hey tell me about that tell me about this maximum people are using codex and others for doing the coding but then sometimes they move to other tools from the user perspective if you have one of the most sophisticated DevOps as well they don't go beyond 30 services and a very sophisticated organization they have 1000 but I have not seen personally people using 100 200 services of AWS at once even though they're coming up with 500 so we don't have to keep up with another 500 which is coming in the next

49:49print for AWS all we have to make sure that we are covering the users and the maximum coverage we can give them so for an enterprise of the magnitude of like the largest insurance provider you're working with they might use like 35 40 services or maybe 50 services how do we how much do we cover almost like 45 of that what we cover the rest of the five we can build it on the go so our focus is more user focus than what the services they are using versus like oh they have come up with another 500 we have to build automation for another 500 so it's a it's a very user centric approach okay so to put it in other way it sounds like you're letting your customer sort of drive you toward the services you want to include in your mapping service yes that's correct and in fact as we are partnering with the cloud service providers they are telling us that hey we have these 20 customers why don't you do you have these services like you know we we kind of integrate very closely with OCI so OCI has given us a list like can we have this let me put it in the next

50:53print just crank up the engine and you know we get the mapping for those and boom like we have it also are most of the mapping is kind of getting vetted by the cloud service providers it's not there just we are just doing it randomly so they are also looking at it and they're like oh yeah this looks good we can kind of roll it out now so we are working hand in hand with all these cloud service providers that's the that's where we find ourselves to be in a very privileged position very lucky like lucky to be in this position where you're solving a problem and like the whole industry is coming towards of helping okay yeah you should be doing this or that so it sounds very easy that hey fluid cloud currency girl but it's a whole lot of whole turn of effort to maintain that accuracy in fact we have pointed out many times AWS has changed the availability zones for those accounts every month and suddenly Terra from up level start failing you would not know

51:53why because that availability zone is not available longer available for your account we have seen vulture cloud has changed the OS IDs like the OS ID is you did determine your OS for your in vulture instance so if Ubuntu was OS ID 2514 suddenly at this point in time the OS ID says invalid OS ID oh what is that new OS ID for that Ubuntu machine the version I'm using so we have pointed out those because every day we are doing hundreds of migrations you can think of every combination AWS 12 regions to Azure 8 regions to OCI 40 regions to Vulture 32 regions and every it is a nightmare for us to keep up with the services and you know yeah cloud bill is quite high it's like what you said earlier it sounds easy and I'm going no one does it it sounds terrifying so yes it's almost like an Apple it's an Apple iPhone like it seems to be you know the

53:00user interface yeah you'll say easy is can convert deploy behind the scene the kind of the heavy lifting which is getting done I think the great technology should be better like that the the front should be very easy to use very intuitive but the behind the background and I think I mean and I can be very honest every single time and tropics coming up with a new model there are 100 companies which are dying out there in the market we saw a lot of like IBM stocks tanking down and all those kind of things happening very recently however I think that's where I like when you have to pick a start of year to pick up problem which was not solved for a couple of like decades like all this what you're solving at 20-year-old problem you were very sure we tried using AI four months into it we knew that this won't be solved through an AI kind of based problem and then you kind of get into that and that's how it is definitely not easy and that's the reason I mean we'll be able to survive much more longer than then another average starter

54:03yeah you're tackling a very difficult problem and if you can take away that pain for the customer that's the whole point yeah okay this has been a wonderful conversation in that the complexities of cloud and how you deal with it and deal with multiple environments and so on has been a problem the industry has been tackling in a lot of avenues and a lot of different narrow least scoped products and and so on for a while and what you guys are doing I think stands out to me as like you really went for it and you're really going after some hard challenges and it also sounds like it might be a little bit to be true so I it's there should I be I don't know I don't want to sound skeptical but I mean how do you address people whose natural response is like come on I can't do all of those things right I mean yes yes we do get that kind of reaction very often Ethan it's too good to be good because our our claims are super high like a nine-month task can be done in like one hour are you crazy like yes it is that crazy my request for all

55:09the developers and DevOps guys like just try it out we are not doing something like totally out of the box like which is not understandable it's simple straightforward terraform conversions generating terraforms and we have taken that super hard problems in a different way which we are able to provide value so my request to the DevOps guys would be just try it out get the feeling of the product then you will understand power and then make use of just like open claw right nobody believed in open claw can do the things but when you try you'll be amazed so for infrastructure we want to be solving the super hard problems for DevOps and we want to solve those infrastructure problems so when you think of infrastructure cloud infrastructure think of flute cloud well people have questions for your harsh should Omar how do how do they reach out to you oh you can come to our website flutecloud.com find me on LinkedIn my name is Hushed Omar my email

56:11is hushed at flutecloud.com it's my first name and flutecloud.com and yes there are various ways to reach out to me and we are a sure on comear yeah and then sure on comear same question how do people reach out to you yeah I mean so I'm on LinkedIn uh people can uh on LinkedIn sharad comear and my email is sharadact flutecloud.com yeah mean just uh go to our website book a demo and to the the question which you also said was like when people actually click on the demo when they see the demo and the reaction and this morning I think we just had this reaction one of the customers with like wow you guys were not doing hand gestures it's real it's like so I'm like yeah guys I mean it's a full fledged thing like I'm like oh no we would like to get into it so yeah I mean unless it's a it's like touch it to believe it so I think yes book a demo with us uh reach reach out to me reach out to Hushed and uh yeah you will see the magic happening in

57:13the infrastructure award well thanks guys for joining us on having networking this was fantastic and uh fluidcloud.com if you're interested in what these guys are doing they're also going to be at several different events in video gtc human x Nutanix.next AWS summit both in la and in dc so if you're at any of those events and you see fluid cloud swing by and take a look and see what they're doing and have a chat and thank you for listening to heavy networking today and if you do ring up fluidcloud to find out more tell them that you heard about them on packet pushers that lets our sponsors know that we help you keep up with the industry and therefore they should keep working with us like share and subscribe leave a comment wherever you're listening apples modify youtube wherever wherever and all that helps other people discover our podcasted videos and we really appreciate that we have fun while we're doing this but we don't do this just for fun if you know what I'm saying this is how we've made our families here at packet pushers and for what you do to pay your bills and feed your families thank you every network janitor packet mechanic and scruffy looking switchherter matters you matter your work is important we see you we appreciate you

58:17here keep doing what you do to keep the world online and tell our next episode to just remember too much networking would never be enough