Hello, welcome everyone. Thank you for coming. Um, I'm uh Michael Shaul. I'm part of the NetUP cloud data services office of the co. I've been working for NetUP for more than seven years now. Uh, and uh I'm based in Tel Aviv. >> Hi. And I'm Deon. I'm also around seven years inETUP. I'm a product manager in the FSX team focusing on the builder aspect. So EKS is a verymuch a very important building block in that and also around AI and we'll try in this presentation to give you a bit more context around EKS in general and how does it uh integrate well together with uh with FSX. Cool. So I'm sure most of you read the confidantnotice but we'll spend 30 seconds to have a look at that especially for Deepak is in his reminder. So don'tread it quickly. >> Don't do things that are frowned upon by the legal department. So back basically it>> awesome. So what do we want to achieve in this uh presentation? So essentially what we want to achieve is to answer the question of what is the value of fsxn for stateful applications that arerunning in EKS. Essentially most state most kubernetes workload will run in AKS. The key place where we see our value is when you look at stage stateful application, we want to showcase exactly uh where does it play and whydoes it matter right in general uh when we look at the agenda uh we want to talk a bit broader about a stateful application um in Kubernetes what's the trends that we're seeing andwhereand what workload are interestingand then Mickey will run us through um the technical of exactly how it is achieved the different features andfunctions that uh you can take advantage of and lastly we'll look at the customer story and where FSX helped him achieve aSAS application Cy so let's look at the landscape so when we look atDKS, Kubernetes in general. I'm Ithink we're like few years already into in the future, but a lot of it was looked upon as anon stateful application, things that are static that can be thrown away that the data that they produce h can be recreated. H but we see more and more workloads that are state stateless in the AKS environment. There is stateful sorry [clears throat] and they required a lot of the differenth features and function that FSX can provide in a pretty easy way. Um the two key things uh that we uh look at is how we optimize cost both from an operational perspective and uh infrastructure cost and how do we um help answer the different requirements that customer have about whether be uh protecting the data locally or also realizingdata protection across regions as well. Yeah, I think just to comment on that, I think that as Uval said that many things started as stateless with Kubernetes and it was this dogma that only state stateless applications can run but as uh companies adopted Kubernetes more and more it sort of became their platform of choice to just deploying anything and because it's easier it became more robust and it just became the easiest way for them um to do deployment manage life cycle of an application. And now you see companies that would just want everything to run on Kubernetes. If it's stateful, stateless, whatever, just throw it in there because all our operations are based on that. So this is why we see more uh of that growing I think.>> Cool. So if we look at as Mickey said everything can run on Kubernetes, right? But when we look at what we see as a returning pattern uh we see a lot of customers running uh different databases whether it'll be database that are um like posgress or h we see uh different developer tools that are run on a kubernetes environment uh like um artifactory or git that needs to uh serve the different users and maintain the data and content management andanalytics, a IML. Uh we see quite a lot of Jupiter notebook uh deployment and things of that sort. Uh that definitely have precious data that needs to be uh held in the highest standard. And in terms of um how we see thedifferent values that in data management can bring to those applications. H as I mentioned and we look at cost as a key thing. Uh now if you look at the other alternative that AWS provide if you look at EBS or EFSa lot of those are not cost oriented meaning that there's not a lot of uh costuh saving uh saving features. Uh one of the key things that you see in EKS is you give a lot of the freedom uh to the developers, right? You build a platform like Mickey said, you put you allow people to deploy whatever they want onthe Kubernetes cluster, but you want to maintain the cost. So one of the key things that we're helping with is improving that cost. Improving resilience is a very important one. being able to deploy a multi-AZ deployment rather than doing a single A and reducing that thinking uh process from the developers is very important essentially you provide them with a multi-AZ solution layer by default which is avery important thing when you look at resiliency inAWS um we're able to increase the agility with different data management uh capabilities. There is a for example flex loan youtake it as a given if you're a onep customer on prem but when you look at AWS it's a pretty unique feature and a pretty uh strong thing to give to your AKS environment in your developers ability to clone the environment without cost and immediate uh time and lastly anything to do around security right that's always top of mind for customers even the ability to do snapshot is not it should not be taken as a given that's something that we provide out of the box in a very easy way and you can do it directly from the CSI driver uh which is assa now if we look at fsx I'm assuming everybody knows what fsx is right but I'll just go around go at a glance >> just with a show of hands how many of you know the service fsx foret up on tap and How many of you have used it? Okay, good.>> Okay, >> Okay, >> Okay, >> good percentage. >> So, some haven't. So, same with you. Goopen the AWS console and start one up. Uh, but the idea is really I've been seven years in this NetUP cloud journey. I started with CVO which was our product that was delivered by the marketplace. Really the idea in FSX is to take all the goodness of ONAP and wrap it around the very scalable service that AWS provide and being able to essentially get all that goodness surrounded by the AWS scale andpower. So if you look at that there's two ways to look at that uh equation. One is you can take FX on top and get a lot of the benefits without being an expert, right? You get the high availability out of the box when you deploy multi-AZ system and you get a fully managed performance and we put a lot of emphasis around what throughput you select and what kind of infrastructure we uh deploy to provide it. uh we give you a lot of flexibility around how to access the data. So um a unified both for block and for files uh system allowing you like with the example of Kubernetes of customers wanting to deploy everything on Kubernetes. We want customers to deploy whatever they want using FSX and being able to provide them uh with all of those capability. And lastly obviously you get all the cost efficiencies and costsaving out of the box. So you put the volume you have fin provisioning did a compression as you put the data. You don't need to configure anything or do anything. It's all by default. And once you got all these bases in a very easy way you're also able to take advantage of the different features. Right? The innovation is just around the corner. So whether you'll take uh clones to accelerate CI/CD or accelerate your tasting uh cross region replication for DR purposes realizing a DR is pretty hard to do. So that's something that we're able to allow customers to add to their service or creating a new way to uh isolate your tenant anduh create abetter SAS service. So, a lot of those are just at your fingertip once you start that journey.And with that, I'll let Mickey show us how it's done actually. >> So, let's see it in action. So, we're starting by looking into uh thething that allows us to do this all very easily, which is the integration layer, uh the Trident CSI driver. So that's the way thatthe customer that wants to work with FSX andEKS or any other Kubernetes for that matter on AWS uh start with you deploy theTrident driver and then you get all the CSI primitives andmuch more of the benefits that we're going to see uh from FSX and ONAP. Actually what's nice is that like FSX today has uh lots of automation and uh and many APIs available from AWS but Trident also masks a lot of ONAP APIs that don't have an AWS API today. So if someone wants to automate that outside of EKS and Kubernetes they will have to write some sort of onap script or things like that where with Trident you get that easily and you don't need to understand ONTAP you just need to understand how to consume storage within EKS and Kubernetes you just need to allocate a persistent volume claim and it can be either an NFS it can be an SMB if you're working with Windows containers which is also supported And it can be an ice kazilan like this is an example where today we don't still don't have an AWS API to create a block device. It's fully supported but there youhave to do onap APIs but if you work with EKS you don't need to know onap APIs. You just allocate a PVC a persistent volume claim and you get a block device which is great. Um so as everything is done via the uh kubernetes uh primitives like cubectdl you can offload these to your platform team to your devops team to your developers you don't they don't need to understand AWS on tab or anything for that >> like one thing that is really cool it actually goes broader than that right you can even deploy your fsx environment directly from there yeah you can do yeah you can evenly use so that's not trident but yeah wecan even so things like customers use today to manage their AWS infrastructure through EKS so there are projects like crossplane which is a CNCF incubation project to manage cloud infrastructure from kubernetes so fsx is supported from crossplane so you can also allocate file systems using eks and then use trident to manage them through ek KS. So we can do the entire life cycle of the infrastructure manager end through EKS. So yeah, that'sa good point. So uh the first feature that something that uh Yuva mentioned that we're going to mention here is tenant isolation and tenant management. So FSX comes with an ability to do tenant management. Either you can uh use uh separate file systems which is fine or you can do different SVMs. And this totally integrates bottom up or top down uh from uh the Kubernetes layer through the CSI Trident CSI driver which connects to the FSX file system. So we can connect and have one EKS clusteruh consume many different file systems or it can consume one file system with many SVMs. And for the uhyou know the devteam or the uh platform team all they know is different storage classes tojust consume different storage classes. But what they're getting is an isolated instance of the storage from a security perspective and also from like a noisy neighbor perspective. So they can get different quality of service and these can be controlled through the trident driver and also consumption like capacity consumption limitations and things like that. uh this can easily be linked to the Kubernetes way of separating tenants like namespaces like we have in this example or it can be like different EKS cluster dependent on how the customer runs the organization. So in this example you can see different EKS cluster connecting to the same FSX file system but also different namespaces in one uh FSX uh in one EKS cluster. So uh it doesn't have to be an either or. It can do both. Um one unique feature that uh Trident has with FSX and ONAP in general is something that I saw some customers that were very much interested in that uh is the ability to do cross namespace data sharing. So a PVC a persistent volume claim is what's called a namespaced resource within Kubernetes. So once you attach a volume like let's say even if it's an EFS if it's an NFS share to a specific persistent volume claim and attach that to an application you won't be able to attach the same NFS share for example to a different namespace because the resource the PVC exists within one namespace so uh Trident sort of created a way around that uh creating this resource called Trident volume reference It's acustom resource within Kubernetes that you can use to be able to share volumes PVCs between different namespaces. So like for example for logging systems that we see is very useful because you want to write from all the namespace theapplication logs into one large uh file share and this is not possible if you're doing uh PVCs with any other NFS because you can'tdo this reference from other namespace other name spaces for so this is very useful feature uh to know uh multi-AZ this is something that you've all mentioned thisis an amazing feature because you get this out of the box don't need to do anything. Uh you get this cross replication. Uh if you compare this to like we spoke with customers that used to run third party uh products and third party you know you inquire uh um networking cost for their applications. So you have to pay this extra. Actually we discussed we had a customer running a Seth cluster and the replication cost the networking cost was uh 10 to one compared to theterabyte cost. So for each gigabyte they saved they paid or each dollar of storage it was $10 for networking just for the chatter between the ais. So it's huge amounts. So this is compared to third party. So here you get that just out of the box free of charge. you can mount the file system from any um a within this region. So even the data path doesn't get charges. And with Kubernetes, this is amazing because usually your app is spread across a you want it to be available and theneat thing here is that it's also available for block. So you can say okay EFS does that withNFS that's fine but uh with EBS you get just this single a instance and you don't move so here you get a block device which is available across a and you can mount them from any place so youcan move your block devices you can run your uh containers in any a for availability scale whatever reason and your lock device will be uh available and your pods won't get stuck pending for the storage waiting for the storage to become available at the specific a that they were scheduled on. So this is agreat feature great feature and just Iforgot to comment if you have any questions feel free to ask them during the presentation don't have to wait till theend how are you keeping those cost savings I mean the bits have to go We don't charge for>> AWS doesn't charge for uh networking cost. The replication happens as part of the service. So if you choose a multi-AZ deployment so replication just happens. Youdon't know it's there. It's just it is just there. So you get the uh like a mount point andit'sdone in the back end of the service. And for the mount you get you don't get charged for cross a uh data mounts uh just AWS decision that you know uhit wouldn't have madesense if it didn't because this is the way that we wanted this to work. So we sort of figured this out with them how to make this work like that because we want this to be available in any other uh a so yeah>> question no so uh the next step would be cross region replication so while you know multi-AZ is a difficult task then cross region replication would be an even more difficult task and here you get this very efficient block level incremental forever replication you can do between as uh of course if you have onamp on-prem you can of course do it from onrem toAWS uh but even within the cloud it can be challenging so you have this it's secured it's encrypted if Iguess most of you or some of you know snapmir it works uh it um makes sense and once again even here for block. We spoke with customers that used to have block devices and for large customers they can get into hundreds and thousands of volumes with EBS and sometimes just this con consolidation and being able to replicate everything within one container of data. this makes their life so much easier to work with because uh with Kubernetes it's the like a it's the wild west of what happens there because you delegate so much and you automate and you build platforms upon platforms and then you delegate to developers and there they just allocate when they need stuff and then you need to control it somehow and here you just get total control without the need to or the cost it takes to uh teach your developers or let them do something differently. They just do whatever they want andyou get this platform to support that and we'll see that uh with cost savings inthe next slides as well. Umnow that would be a disallow right crossing the region replication having two>> yeah you you'd have to have two FSX instances yeah oneregion and one in the other and uh I we don't have a slide on that but that's also true for caching. So if you need uh we Idiscussed this with a customer like two weeks or three weeks ago. Uh they want an EKS environment where theyhave satellite environments and these environment they need only to cache theblocks that need to get access. So you can do caching not full replication of the data and you get only theyou know recently read blocks present in that region. So it works with caching as well not just cross region replication also cross region caching use products for that caching >> it's part of the fsx it's part of onap so it's flex cache it works I mean it works yeah so it works not global file cache it'sflex cache it's part of the onap OS so it's part of fsx as well and um and you can do it for NFS and SMB so no ice scuzzy but Yeah. Um so snapshots that that's something we see like lots of customers using and we we're getting great feedbacks from AWS specifically around EKS workloads but any other workloads for that matter because as um an AWS guy told me you have to teach them within AWS what how does your snapshot differs from ABS snapshot because they're totally different. So the concept of what we know or what if you know on tap for many years as snapshot islike so completely different and uh the ability to do that so easily so fast. So you can even delegate that into your you know developers and uh make them run that the snapshot whenever they need toprotect the data before migration to check their code make sure that everything is running. So they can do that. You can offload these and they can use once again the Kubernetes primitives ofa volume snapshot. You can see the code right here. Theydon't need to understand FSX. They don't need to understand onap. They get this Kubernetes code, the EKS code. They run this.creates our snapshot in the back end. And if they used EBS before, they ran the same script just using a different storage cost and they got an EBS snapshot without the benefits of oursnapshot. So they don't need to change what they know. They just get the benefit underneath. It's faster. The cost is reallycheap because wejust create, you know, a pointer table when we create a snapshot. We don't copy any blocks. So you can just takethem whenever you need. Uh so this is amazing. >> And I think for EFS it you don't have it.>> Yeah. For the EFS you don't even have snapshots. It just relies Thank you. It's a good comment relies on backup to S3 and recovery. So for these type of like development process automation, databasesthat that'snot the solution. Usually if you need something fast or even like ransomware protection, you want the ability to take snapshots quickly and whenever you need it, whenever you detect an anomaly or something that bad is going to happen, not a backup which takes forever to run, especially if it's an NFS file system, which can be huge. >> Yeah. And I think another important comment both on snap mirror and snapshot is like there for data protection, right? you think about uh region protection but people use snap mirror and snapshot for different building blocks right you use like your comment about developer checking his code with snapshot and then running it it's important to understand it really accelerate a lot of different processes that you have it it's not just for the data protection which is very important >> you question support all the ransomware privile>> yeah so we added the snap lock and you have asnapshot that is temper proof so that I you have the temperroof snapshots. I think I had a slide maybe I remove it. Yeah, I might have removed that but yeah.you have the temperroof snapshots and you have the um the warm protection if you need that. I think that the full uh snap lock is as additional charges but >> and basically cost like alicense on prem. That's like they have a cap on it. It's not endless. So, it's pretty >> good. And actually, snapshot temper proof is free of charge. So, it's not exactly pre Well, it's there's a hack there, but I wouldn't say that now. I read the disclaimer, but you can ask me later. Uh, so this amazing snapshot technology uh so we build upon it this our data cloning technology. So it's sort of like the snapshots these very efficient very fast no cost at all no space at all. So we can now open them to read write uh to use with your application. So once again you can your developers your platform teams can run what they know within Kubernetes the persistent volume claim to create anew volume from an existing snapshot. So this is how it works. You can see the data source is a volume snapshot. So this is how you create a Kubernetes clone. So that's the way they know this. That's the way they did that with EBS for example or with other storage uhsolutions. So they don't need to know on tap how to create clones or whatever. They just get the benefit and they can use that. We see a lot of that in their application develop development life cycle because when things are so fast and so efficient and you can run them whenever youneed to. This sort of open uh anew space of innovation because uh like we had companies that used to do these type of clones before upgrade before testing for QA for whatever and they ran for hours or even days and now they run for minutes. So if you have these processes run for minutes then you can think about how you can do more with that how you can test more how you can create more um your service can become more stable more innovative. So you can uh you have your let's say your production EKS cluster here. Youhave your data. It's a 40 terabytes uh four volume umdevices your containers and you want to replicate that or create a clone to be able to test your new version in your testing environment. So you just use look for this clone and you create a clone and it's fully accessible really fast to your testing environment and you can start testing your new version your RF your bug fix whatever h it's zero terabytes almost zero terabytes unless you change something you can run your cycle move on another environment to a pre-productiontest that and then gointo production and deploy and going on with this very efficient cycle. We also see that starting to take into effect with large uh um like with workloads that use large amount of like huge data sets where when thinking about that with other with any other tools you won't be able to create this ability of what we called explore and destroy. So with Kubernetes you have this and containers you have this amazing platform for your stateless app to be able to run your code and explore and destroy. you run and you have an image of your application logic and you can execute that with scale on thousands of computer instances on thousands of GPU instances test something decide it's not good or decide it's good destroy that shut it down not pay for it anymore but with data that's an effort because if you want to change something that the way that the data processing work the way your data set is built you have to just cloning a pab AB of data that sits on EFS would be an a huge effort. So here you just have it.just works. So you can start an instance of your app, explore it with the data set, with a new data set, have teams work on different data set, but it doesn't take any cost and then destroy it. So things like uh generative AI, genomics, uh video rendering, gaming development, all that. So they have huge data sets and they can benefit we see them benefiting from these type of explore and destroy scenarios using our uh cloning technology and we get all these amazing benefits right andthen we're uh starting to think well if I get all these features I'm probably going to pay much more on a much you know more robust featurerich products than Ipay for other stoages and uh no thatin most cases it won't be theanswer because we have such a rich cost optimization engine running in the back end of the FSX service whichif you know on tap you know probably know parts of it and the first would be and I see that very beneficial for Kubernetes based environment is spin provisioning this is something unique for uh for us with any other um cloud offering storage doesn't exist in the cloud. So you allocate something, you pay for it, right? You allocate a block device within Amazon, you pay for whatever you allocate it. You allocate something, you ask for your uh file system to be this big, you pay for whatever you ask for the size of it. With FSX, you allocate a file system, but then your developers can start allocating volumes and as long as they don't consume data within this volumes or that the data that they consume doesn'tumexceed the size of the file system. You don't need to pay for it. You just pay for whatever the size of the file system is. So you can have a 10 terbte file system accommodating for 10terabytes volume like 100 terabyte of uh volume provisioning because they just don't use it so why pay for it. So this is as I said as Kubernetes tends to be the wild west and you delegate a lot of things and you it's not the old ways when you used to pet the servers and allocate volumes and think about everything in advance you want to do everything faster quicker so other people do it and when other people do it that things tend to do get out of control so I'm saying let them go out of control and we have the features to cover for that so uh we got a lot of good feed back from uh customers that we work with around thin provisioning with within an EKS or Kubernetes environment uh in general and on top of that once you get data to save within the file system we run dduplication compression and uh and then the blocks that remain get can get the infrequent access tearing mechanism. So this runs in the back end. When you create a file system, this is automatically onall volumes. You can turn it off if you have specific volumes that you don't want to get tier because you want the extreme high performance all the time for all the data. So you can turn this off. You can change that within the life cycle. So you can automate it this like for exampleum so let me just explain whatit does. So um FSX has two tiers of storage. So the SSD tier when you create the file system you allocate the size you say how much would be the size of the file system you can increase it as you go but you uh this is the more priciest uh storage it's the more performant one and then you have a capacity tier which is the less performant one and also cheaper one so we make sure that unused blocks gets tiered in the back end to the cheaper type of storage and you don't have to do anything for it. So it just happens once a block doesn't get touched for a few like a month, two months, you can set that up. We just tear it off and ifit does get access eventually, so you just have to pull it once and it get warmed again. Uhandyou >> I think the other thing which is cool is it's completely elastic, right? You don't need to calculate how much capacity tier I need. It will just be there as the data cools off. If you warm the data, it will be reclaimed to the SSD and yeah, exactly. So,a good example, so you can definitely run that in production. It would save you a ton of money, but let's say wetalked about cross region replication. You have a DR at another site. Usually, you don't use it. You just drill test uh you do drills once or twice a year. So why not cool off all the data in that site, pay much less for it. And when you drill, change the policy, warm the data, access, do your drill, go back, put everything in capacity, pay less for it. So you it's elastic. So you can change that all time for vision standard on tap on time systems. There's some monitoring that needs to happen to make sure that you all run out. I think the same. Yeah, you can definitely do that. Automate that with cloudatch do like automation for any other auto growth for volume. >> Yeah, the same there's auto growth. Yeah, you can do auto >> exactly the same thing >> or like get alert. >> Yeah, you can get alerts. You can automate on these alerts and of course Yeah. Can do whatever. Uh it's very easy because you don't have to you know it's like not like in on-prim you had some alarming rates because you'd say well if I go through uh this threshold then I need to stop because I need to order new disc shelves but here you don't need to order anything you just need to addmore add more so that's it's just a matter of seconds so yeah and automating the process or doing that uh whichever way andJust to go to the bottom of the bottom line here which we talked about all these efficiencies and so if you go into these are not like secret numbers I'm not getting these out of any secret spreadsheets just went into the AWS calculator you can do it yourself and you can compare workloads you can check whatever it costs to do native block withuh AWS and FSX block you can do native uh EFS compared to FSX with NFS both multi-AZ and uh single A and you can see the difference. This is just whatever the calculator shows up with some ratios taking taken into consideration, right? So because these we see these numbers with customers and these are conservative numbers and these numbers also like for example for block storage these just take into consideration the raw storage that you allocate right it's just the EBS on two as you don't get the replication for doing replication between a with EBS you'd have to buy a replication engine for of some sort like a third party tool And then you incur networking cost which we mentioned. So this doesn't include all of that. So these are very conservative and also these don't include any benefit you've get from things like snapshots and clones. So because they vary dependent on the customers because we have like many customers using tons of cones and snapshots and so they would benefit a huge amount out of these and their savings would be muchlarger and some just don't use it so use it uh more less often. Um so yeah lots of cost benefit andwe see lots of focus on that in this current economy trying to uh save wherever possible. Ithink I had two months ago I had a conversation with a customer that AWS uh referred us to and a customer had an analytic workload running on EKS. It's a European customer. It's like a half betabyte of this specific workload, this specific application. And their main point was our current storage solution is too expensive. We need a different one. and AWS told them Iguess your best bet would be try it with FSX with NFS and they cut uh four fifths so like uh 80% of the cost we're just moving the data from the other AWS solution there is no licensing cost is the cost of the service yeah of course that just the cost of the service itself yeah so you pay FSX has like uh you pay for I said you have the SSD D tier. So you pay for as much as you allocate within the SSD tier, the capacity tier. So if you tier things into the capacity here, then that's added to the price le cost less, but you still it still gets added and you pay for the uh the skew of uh performance that you choose. So ifit's a more performance file system, you'd pay more for the file system. All these are added and this is the price of the service. >> Yeah. And the skew is scalable, right? >> Yeah, the skew is you can change it like for Yeah, for theDR example that we gave. So if most of the time you don't need the performance because it's just there dormant, you can do 512 megabytes of throughput and once you go production, you can automate the change into like 6 GB Q and get 6 GB of performance from this file system and uh and back. So depending on whatyour requirements are. So it's very agile, very fast. Like I said, you don't need to buy an extra shelf or change the control, do control replacement. It's just achange in parameter and AWS doesthe rest in the back end. They manage the service, they change whatever needs to be changed. Um so this is um an example we had with a very large customer that chose to use uh FSX with Kubernetes for many reasons. But uh we sort of learned from them as well how they did that and used that to uh to handle their production deployment life cycle for removing major releases and also EKS migrations. So this customer was an on-prem customer and their first stage was to move into AWS and move the monolith as it as is. So they first moved into EC2 instances. They moved they had their application layer. They have their load balancer as you can see here and they have had their uh sort of transa transactional database queue that they leave for the application. This is their state stateful layer. So thatran onEC2 before and then on the second phase theystarted to refactor their application trying to rebuild that uh refactor the monolith and make it scale containerize that uh move into a multi-tenant environment make it more robust uh more secure for their customers and so they had a requirement to support uh a storage that supports uhhigh um scalable um transactions with their uh data layer. So 10 million messages per second was their requirement with their conversion engine. They needed multi-AZ support because they wanted things to be easy for them. They didn't want to handle these movements of data. They didn't want to incur the penalties ofreplication. They didn't want to manage it. They needed easy CSI integration because they wanted everything to be handled through the EKS environment, nothing to be done outside of it. And they, as I said, theywanted to refactor everything to a SAS multi-tenant environment. So they needed potential future support for multi-tenant storage environment. So they chose FSX. It was a great fit for them. And then they had this question of we want to make our environment more available now that we are running Kubernetes, we're running in the cloud and we want to have like major upgrades or major infrastructure upgrades in this example. So we have their production environment running on the right with EKS 123 and their app environment running version 2.5 for example and then they have EKS version 124 with their newer version of the environment and they need to run like a thorough uh testing of their major release because lots of things change EKS change they can sometimes API break, sometimes some of the processes break. So it takes a while, but then they need todo this switch over to their customers. So for a stateless app, this is just changing glo load balancer um like uh definitions and pointing the connections to the new version. But then you also have the state you need to route the reroute the application to work with the data. So uh one thing they did is they just they can access the uh the volume so that they have the this NFS volumes and they have thousands of it and they also do icecazi block they can access that uh from the um other cluster start testing read only they can do that right so that's possible andthey did thatbut in some cases they want to run case testers that tests that are also you know change the data. So and also for block devices you can mount them even read only on other clusters. So what they did some of it uh in a manner that it's same cluster it's uh this is a minor release you can see this is the same cluster so theyuse different name spaces and in this case it's a major release and this gets a whole different cluster because it changed the EKS version and then another major release of their app. So in both types of upgrades they can do a clone here. They can do a readwrite on the clone test. Same with this one. So it's both for block and file. And then when they uh shift the new version into production, they just need to change load balancer changes to read and that's it.takes like afew seconds and the downtime is minimal to the customer. They had so many tests run on that before they moved into production because as we mentioned during the presentation that using this cloning technology or even if you don't need to test with updates you can do read only and you just access the same mount point and once you move into production you just do read write. So you can do both. uh so if you need updates you can use clones you can uh do read only without clones so they use both methods so this was an amazing feature fe feature that was enabling them so they didn't choose fsx because of that they chose fsx before because all these reason but then where they started to think about how to you know become better with their environment how to keep upd when upgrading their service this gave them a great benefit of working uhwithFSX and the feature that Trident provides it makes their life made their life much easier. >> Yeah. And I think it showcased that you can innovate, right? You can start with Snap Mirror and then decide to move to the next level and implement clones as well as part of your >> Yeah, exactly. >> pipeline. >> pipeline. >> pipeline. >> So, um any question? >> Cool. So uh we have a this isthis on?>> Okay. So we have a quick survey for you. Uh what would be the most important feature provided by FSXN with your EKS deployment?Let me just uh scan that myself. Simply work. Hopefully it works. It's an open question. Nomultiple choice. So beimaginative. So let's see. Oh, we have flex cache. You didn't even speak about that. Okay. Cross a efficiency 7221354.What?that feature? Uh so some phone number maybe I'll try that later. Cloning snapshots cost. Okay. I see flex across a replication. So already in a ded.So do you see lots of challenges that require flex cache to handle? Oh, I see that and multi-AZ is the who had flax cache as ohokay thegang. Okay. So anymore questions on that? Would you try FSX with EKS after this session?Give it a shot. Actually, it's really great. It works perfectly. So,just key takeaways. Uh, so you get great s service persistent storage for containers. I think we covered that. Cross aaz access to prevents pods from getting stuck. Yeah, we get that both NFS and block. I think this is themost unique one. But even for you know get everything so it'seasier to work you have all your storage in one pool can manage that um cross region replication huge hugely important uh any other way would be very complicated to maintain lots of hundreds and thousands of volumes you need to take care of them here just replicate everything uh penalty flip-free snapshots amazing feature completely different for any other snapshot thatthecloud is familiar with and know um uh clones also same highly uh and like a greatest options for innovation within the application life cycle and uh ransomware protection data locking cost reduction like the easiest path just as I said this customer type reduce cost just moving the data even not thinking about any other feature just 80% costsaving just for just keeping the data and then as well oh I have this amazing feature of clone that oh that'sgreat I already have the data there why not so uh and uh multi-tenency if you have an environment if you'rerunning SAS and you need that so definitely support that out the box um please attend other sessions from the demo track yeah hopefully I was making sure if they were already on or no, but you cango and you can read about some more resources at um and that there's there are also some blogs from AWS that you can take a look if you want to start your path with uh EKS and uh um and FSX. So yeah, thank you for coming. Uh if you have any more questions with a deer and