 Hello everyone welcome to cloud native live where we dive in code behind cloud native I'm Paul Simons and I'm CNCF ambassador every week we bring in a new setup presenters to showcase how to work with cloud native technology they will bring things they will break things and they will answer your questions join us every Wednesday at 10 CDT and this week we have a pleasure to receive like Kikwarp from CEO from the store West and he will talk about automating the orchestrate database and our stateful workloads with Kubernetes also join us for cubicon and cloud native virtual Europe in May doing four in seven to where to the last from the cloud native community this is an official live stream of the CNCF and as a second is a subject of CNCF code of conduct please do not add anything to the chat and our questions that would be in relation of the code of conduct basically please be respectful of all of your fellow participants and presenters we for all that's hand over to Alex to show us about this amazing idea that is how automating the orchestrate database and the stateful workloads and companies thank you Alex for joining us in our live today thank you thank you very much Paolo and thanks for that amazing introductions hopefully I'll live up to to making this an amazing discussion I'm going to share my screen and put up a few slides to help with the process so a little bit a little bit about myself my name is Alex Kikwarp I'm one of the founders and CEO of storage OS where we've been building a software defined platform for cloud native storage I do have two hats I'm also the co-chair of the CNCF storage sake so feel free to to to ask any type of questions around cloud native storage during this talk and I'll happily try to answer to the best of my capability my background before before starting up storage OS was was actually working on infrastructure and infrastructure engineering of sort of large platforms with large financial services I mentioned the CNCF storage sake I want to make a little plug here we're always looking for to expand the community and have people join the the the sake and the and the the the SIG meetings we cover a lot of things including project presentations that that are for projects that are working with the CNCF as well as projects that are just considering joining the CNCF and we also do a lot of work on different documents and information that we think would be really useful for for the end user communities and for organizations and developers and teams that are that are deploying cloud native technologies so I wanted to cover off right we often have this discussion around you know what is a stateful application why is cloud native storage so important so I'll start off with something maybe a little contentious my my premise here is there's no such thing as a stateless architecture all applications everywhere want to store states somewhere whether that's you know simply in a file or in a database or a key value store or or perhaps an object store or a message key or or any any one of those things so so when we think about why storage the answer is really you know all applications are going to use storage somewhere and of course if you're making the investment in platforms using containers and orchestrated using Kubernetes why wouldn't you want your stateful applications to be orchestrated and managed in exactly the same way so if we're talking about if we're talking about stateful applications what special considerations do we need to think about from form a cloud native storage point of view because of course not all storage is is is equal so it's worth it's worth understanding what we're looking for when we're talking about cloud native storage you know there is this common thing about pets versus cattle in in the cloud native world and you know cattle being this this sort of homogeneous recreatible easy to manage and easy to orchestrate environments versus pets which are you know very bespoke implementations and the same applies to the storage to as much as possible we want cloud native storage to be composable and declarative you know in much the same way that you can specify which containers your applications uses and the amount of CPU and RAM and perhaps the the network topology or the the service mesh etc that that that your applications need developers should also be able to provide the ability to compose their storage environment and of course you know for that to be possible the storage environment needs to be API driven and needs to integrate with you know the control plane or or with CSI and Kubernetes for example to to to be able to provide that that declarative interface the other the other thing to consider is in cloud native environments organizations systems often have very scalable systems which which actually change a lot under the covers right so this could be because you're scaling clusters on the man that could be because you're doing upgrades on the man that could be because of you know failovers or availability reasons but but very often you know we underestimate the complexity of ensuring that data follows an application and why is this right because for the longest time storage has been typically presented or made available to a server but now that your applications are containerized and they're portable and they can scale on demand having the data that those applications use being tied to individual servers is potentially less useful so so we've coined this term application centric storage because the the storage needs to be tied to an application needs to be able to move with an application as it moves within within an environment the other thing is platform agnostic right so so what do we mean by this here i'm talking about using software options or or or perhaps services which allow you to use the same client native storage or the same declarative interface wherever you are whether you're you know developing on a laptop environment or or you know in on premise on big bare metal or client environments or or whatever the mix is you really want the cloud native environments to be the same in all of those environments so that your development environment and your production environment can relate to each other and can work together and finally agile and i do admit that this is incredibly cliche but what do i mean by agile well like i said in in cloud native environments the rate of change is high they are designed to scale on demand they are designed to to have to to swap out nodes as part of upgrade processes for example and therefore the client native storage systems need to need to operate in those in those environments and this is really important because at the end of the day you don't want your storage to be managed by humans you want the same automation that you're applying to your Kubernetes cluster and the Kubernetes world to apply to the storage environment too and and and have that automation such that the storage is is consistently available and and and and also is performance under their rate of change and can integrate with your orchestrated environment and provides you know the same protection via namespaces and RBAC and encryption for example that that that is key to deploying to deploy and securing data and applications in in in cloud environments so when we looked at all of this in the CNCFC we we we realized that there was this this huge broad landscape that that's where storage you know is defined and it covers lots of different things everything from you know distributed storage systems to simple local systems to databases and key value stores and object stores and and other things like that so storage storage in the client native world is a particularly broad topic in order to to help to help people understand this we created the storage white paper which is now at version two and what we cover in this paper and it's available at that at that link is you know the different elements of how a storage system can be deployed we cover some of the things around the attributes of the storage system because it's it's more important than ever that that developers can understand what their application needs and therefore what attributes of the storage system they're looking for how the different layers in a storage system in a storage solution affect the different attributes because what we what we often see is that storage systems in cloud native environments have any number of layers and each of those can affect different different aspects of of say availability or scale we talk about the data access interfaces in terms of the volumes and an application apis that are used by applications and we also define the management interfaces which are those those apis that those those apis that are used by the the orchestrator control plane um there was a question about uh pinging the link um i will i'm just trying to do that now i'm not being very successful i will i will ping i'll ping the link as i can in the for for what it's worth um if you if you search for cncf6 storage um all of the all of the white papers etc are in the sig repo too so that's an easy way to look it up um when we when we talk about how the cloud native storage is instantiated and deployed you know there are obviously a number of different options there are still a lot of traditional solutions which are which are deployed as as hardware written a data center but obviously you know that that limits the portability and the the availability of those environments in cloud environments um what i'm going to focus on mostly in in in this talk is is um the the software elements and the cloud services which which um allow uh the cloud native storage to be more platform agnostic um and and in some cases uh like in the case of storage or as for example those those software defined systems can also be deployed as a container and then can be managed and and uh automated by by an orchestrator themselves um so we we also talked about the different storage attributes right um and we when we sat down we talked about this we we we landed on sort of five key um storage attributes which which which are often determined used to determine which type of storage system you might want to use um within the environment um some of the key things are are obviously you know things like availability and scalability um but very often you know performance is a key consideration too um and we mustn't forget uh things like consistency and durability but what what we found was that these different attributes could be measured across um a number of different vectors so for example the ability to to fail over and and and and have applications access um storage in different locations being able to move data between nodes and protecting the data against against um save save failures uh it was was another factor um similarly you know scalability could be um could be in terms of say the number of clients that can access the storage system um the the number of operations that that that might be important say for for a database where where it's all about the transactions per second um but also scalability could be measured in throughput where you know it's um which could be really important if you're running workloads like analytics or something like elastic search for example right um and it's very rare that um one storage system is going to be able to do everything right so so systems that are very often um optimized for availability might have constraints around consistency or performance similarly um when we uh when we try to um optimize for um operations um those are quite different architectures to systems that that optimize for for for throughput for example so so so I think you know trying to understand what your application needs is is is an important point because then you can actually look for particular attributes um in the underlying storage systems and we talked also about you know some of those layers right because what we find what we find is that um there are so many different layers um and and and and abstractions that that often happen within within a storage system everything from you know the the physical non-volatile layer where where data is actually persisted at the end of the day to to the data services that run on top of that like like you know replications and and snapshots um to the different technologies that are used to protect the data like um perhaps raids or racial coding or replicas um and of course you know the the storage topology plays plays a huge part in this so so for example um you know distributed uh topologies might affect latency sharding is often is often a tool that's used um to to to allow workloads to to scale better and to support large number of clients um and hyper converged allows uh it is very popular today because it allows compute and storage workloads to to share the same uh environment and of course you know the orchestrating the host and the operating system um can have any number of of of different um different uh abstractions there so for example if you're accessing um a database or you're accessing the service you know you might have uh increased controllers or load balancers in in the part and and if you're accessing volumes there might be um uh volume managers and things like that in the part and you know one of the key things here that we often find is is really important to understand is the difference between some of those key localities is key topologies i mean these topologies um because those topologies um can dramatically affect a lot of the of the different attributes you know starting off from from local which which tends to offer you know really great um low latency performance and and and fast throughput but but obviously um poor availability and uh and durability but um uh remotes allows you to to sort of disaggregate the the architectures um and and more commonly nowadays distributed um systems allow you to make it easier to scale and to provide uh provide the capability to uh to to provide um storage capabilities across a larger number of components or or nodes um and and capacity um but obviously you know there are um there are complexities in in providing uh distributed systems and you know that was certainly one of the challenges when when which we came across when we're developing storage os and and our control plane with with design creative consensus um um so the when when we talk about data access interfaces um with with workloads um the workloads can typically access um storage through a volume which is probably the more um mature interface when it comes to uh orchestrators or it can um access uh storage through apis um when we're talking about for example say an object store a key valley store or or or a database um one thing that although a lot of the development thus far has been on um put in and container orchestration around volumes we are seeing um now developments with the new um with the new cap uh with the called uh cosy which um is talking about now creating abstraction layers for um object stores as well but ultimately the data access interface also impacts um a number of attributes within the system but what's important is that we don't necessarily um consider um the different attributes purely on a data access interface so so for example um you know object stores um typically have uh slightly higher latency than than say a block uh a block volume in a file system um because uh object stores um have a more distributed nature and the api itself obviously adds adds overheads um but it's not always safe to assume that say a block or a file system uh volume will always have lower latency than an object store in fact you know there are any number of distributed um storage volumes that could actually be built on top of object store um back ends in which case you know the the the some of the attributes that that volume would would inherit are based on those those back end object stores in terms of availability um so we tried in in in the white paper we tried to put together um a few um uh comparisons between you know how the different access interfaces compared to each other this is this is generally you know um generally accepted attributes but like I said it doesn't always apply because very often the layering means that that different systems can be built on on on different underlying components um but typically you know we see um block interfaces are are often the best for for that low latency performance and you know that could be important say for database or message cues file systems especially um uh offering shared capabilities um allow uh multiple pods to to potentially share the same data sets at the same time um and of course you know object stores in this three interfaces are are fairly well um understood and are are great at providing large capability and and typically large throughput but um less well suited for for low latency for individual objects so that was the data access interface um and I'd like to just finish off with some of the orchestration and and management interfaces so typically a storage system is built is split into two components the control plane and the data plane um workloads will be using the data interface to talk to the data plane component of the storage system but the orchestrator will be running um uh will be uh interfacing with the control plane of that storage system and this would be in order to um dynamically provision resources perhaps and also uh to do things like for example attach resources or or or move resources um to different nodes or depending on where the workload moves um at the time um the the standard control plane interface uh for for volumes within within Kubernetes is CSI the container storage interface this is um you know an analogous to the CRI for runtime and CNI for for networks um and effectively you know that provides an ability to um to create and actually attach um uh uh perform snapshots etc um from the underlying storage system some storage systems also have um you know a variety of frameworks and tools and that can also interface with the orchestrator this could be um systems it could be an operator for example that allows um uh the distribution of or the deployment and the upgrade ability of of a storage system within within Kubernetes um it could also be uh it could also be you know additional services like admission controllers which which might help with say data locality uh within Kubernetes so so we talked a lot about the the different um the different options um before actually before before we go into the next stage I just wanted to say if if there are any questions um please feel free to to ask in in in the chat um I'm happy to stop and and answer questions on the fly um as I'm going along to so don't don't uh don't feel like you have to wait until the end um so moving on um I wanted to sort of maybe talk a little bit more concretely about how storage is configured in Kubernetes specifically and try and give um a little bit of an example of how we can use that to automate and and build out um workloads uh safer workloads in in in Kubernetes so the the the most important building block um in a Kubernetes cluster when it comes to storage is in in fact the storage class so so a storage class um is uh allows you to define a set of parameters that will interface with a uh with a driver with uh that that uh is used within the control plane of that of that storage system so so effectively the storage class is the standard interface um that defines a name of the storage system and how to access that that storage system um a developer can then claim raise a claim this is called a persistent volume claimer or PVC um out of the storage class and Kubernetes will then uh using the CSI driver that's defined in that storage class typically will um dynamically provision a PV or a persistent volume um out of the storage class and then that persistent volume can actually then be accessed through any pod or or any stateful workloads um and uh it becomes becomes you know a piece of portable storage that can move around with the pod right so the idea is that by um giving uh dynamically provisioning the claim and giving the claim a name which is then referenced within the pod you have you know a standard building block for how to link storage into into the the applications so i want to give you a little example of of what this looks like in in in real life um you know show me the animal as they say um so this is an example of a storage class it's it's an example for the storage or s um storage class effectively all we're saying here is that um we we create a a storage class uh called storage of s we give it a name um the the the um we define what the provisioner for that storage class is in this case it's the the CSI interface for for storage of s and there may be some parameters that are also defined within that uh within that storage class um and then we can dynamically provision a volume by creating a persistent volume claim and it's you know at a very simple level a persistent volume claim is uh just needs to provide a name in this case we're calling it database volume one it references the storage class so Kubernetes knows which driver to use and which interface to use to create that provision um and we specify the access mode so so if we're doing something like um a database volume for example we would choose um read write once which means um that uh that storage volume is accessible to to one pod at a time but it's also possible to create volumes with read write many which typically uses some sort of shared file system um like NFS for example under the covers to make the to to enable the volume to be accessed by multiple containers at the same time and the other mandatory uh piece of uh data is typically the size of the volume right so in this case we're doing a five gig volume now it's it's it's possible to define different attributes for different systems um in the storage class or in the persistent volume claim so very often it will be possible to define parameters uh like replication or compression or encryption or or or other data services for example which which can be applied either at a storage class level or or or at a individual volume um depending on the on the underlying storage system in the case of storage of s you can create you know different classes with with different classes of data services and then and and you can also create granular uh individual settings for for specific volumes and then we can launch a stateful application so so in this case we're launching um a post address uh a post address uh database um and what you'll see is in in that list we'll see where we're um mounting uh pg data and we're using um we're using the database volume one as the claim for that volume so so what's actually happening behind the covers from a Kubernetes point of view is that the the CSI um uh provisioner will be attaching um that dynamically provisioned volume to the nodes um Kubernetes will mount that volume into the namespace for for the container typically through a bind mount and then um effectively the container starting up and it will see a slash pg data mount point that will be using the dynamically provisioned volume called database volume one um and really is as simple as that so so with a little bit of yaml it's extremely easy to have a complete end-to-end declarative interface to start stateful workloads with storage um and also to template them and build um build your services as you go along again if there are any questions um that come up feel free to ask them in the in the chat window and uh and Paolo will be will be covering some of those off um as we go along too um so I wanted to also then take this one step further and kind of say okay now that we we've explored the planning of storage and what it can do and how it can work for your environment we'll talk a little bit about how this translates to a database and and perhaps you know the concept of moving that database from your um existing uh traditional environment perhaps uh or or non-cloud-based environment and how do you think about that when you're thinking about moving your database into into something like Kubernetes so if we if we look at this you know most systems start off with you know a particularly well-defined server um which might be running you know a large a large database instance many times these database servers are um very server-centric um it's based on a scale-up approach where you know the server might have a number of database instances or a number of databases within a single instance um running on that node um and and and ultimately you know it is problematic every time a new database is required whether it's for development or testing or or or if um databases are required as the application expands um it can be problematic and and often risky to make changes to to you know your database server instance so let's see what this looks like if we if we apply some of these client-negative principles to the concept so you know we start off with um with Kubernetes cluster we have the developer addition of um storage essence off which actually um virtualizes the storage and provides that scale-out distributed storage for the applications and provides those plugins for CSI to to allow Kubernetes to dynamically provision volumes on demand across a storage pool that's aggregated across all of the nodes in the cluster and what we see is that we can you know we can create a database and we can also um then rather than have one big database instance we can um we can uh we can move um individual instances as as as separate um pods within within the cluster which can then which can now be spread out so so rather than have you know um each um rather than have one big database instance where your failure domain and everything else is based on a scale-up architecture you you now have a distributed architecture where it's easier to make changes or to tune um or to scale individual um databases or database instances within your environments and of course it can be extremely um it can be extremely easy to um to to scale this up um every time you know if a developer needs uh a test database or or or indeed you need to fire up a database as part of the CI CD process um the whole thing uh the whole thing can be can be done dynamically on the fly and in fact you know we have we have a number of organizations using storage OS running uh this sort of environment where they're creating and destroying you know tens of thousands of of database instances and volumes uh every single day on a on a CI CD basis um and here's the here's the other thing right we talked about different attributes that uh cloud native storage um can provide so if your underlying storage system like storage OS is providing that high availability for your database you now also have um an automatic failover and and typically the way this works is right because we talked about not just availability but consistency in order to be consistent um the storage system will be taking the the transactions that are being committed to the primary volume of storage and um replicating it to um one or more replicas we typically recommend two replicas to to to provide um additional availability and once the replicas then acknowledge that the replica has been done that uh data is then acknowledged to the the database and we call this um you know strong consistency so it's the difference between strong consistency and eventual consistency is is about um whether you can be sure that a the if if if there is some interruption in the flow or interruption in the system that all the transactions are always committed to the to the replicas and b but when uh the database um actually queries the disk it's definitely going to see the transaction that was last committed um and there is no delay between the two some systems of course optimize for eventual consistency for um for for performance but that's not always great for for many databases but what we see here with this with this underlying system is that if if one of the nodes fails and effectively you know a copy of the data is lost the underlying storage system with liquid storage rest can can actually then automatically um create an additional replica to get you know the desired state of having two replicas back into back to match the actual state um and the database continues to work on the underlying on the new primary volume which is which is promoted from a previous replica um and what we see here is is effectively you know uh an easy way to provide to to tie storage availability to application availability here we we see a database um that can transparently now fail over between different nodes and continue to access the data anywhere um in this in this environment so in conclusion one of the things I'd like to to just sort of um focus on is um cover up a little bit about how we see um most or many organizations take this journey to to plan native um and stateful applications right and most of the time we see organizations um uh start up with uh building out containers and moving their applications to containers um and what that means is that now it lends itself to being orchestrated and of course Kubernetes is that or is that the factor orchestrator but in my view the biggest superpower of Kubernetes is the fact that everything becomes composable and declarative right so a developer can specify um can specify uh environments where they define the containers and the cpu and the networking etc um and Kubernetes will just make it happen and abstract away the infrastructure and also deal with the scaling and automated failovers etc but like we said all applications need to store state somewhere and this is where a glad native storage solution that integrates with Kubernetes um can now automate not just computer networking but also all of the um storage and what this gives you is an incredibly powerful um application-centric storage paradigm right where effectively um we have the ability now to move any stateful application into into Kubernetes whether it's um a database or a message queue or or uh infrastructure components or analytics like elastic search or Prometheus or Kafka for example um but more importantly we can build anything as a service because it's is it's templatable and uh you know with the power of Githops and the power of of of those YAML templates you can effectively build um any type of service whether it's a CICD as a service or a database as a service and we even have organizations now using um projects like kubeverts which actually allow you to manage VMs within um an under within uh an environment um to to actually have VMs managed on cloud native storage um giving you an infrastructure as a service right this is this is um this is incredibly uh exciting now if you want to get into the nitty gritty of how we do it with with storage os you can try the developer edition this is the only bit of plug i'm going to do on storage os you can try the developer edition for free um we have uh a number of different use cases including you know both grass and different databases and how to run them on on kubernetes um and this is a really easy way to sort of experiment and learn in your own kubernetes environments um all the concepts that we talked about today there are a couple of there are a few questions here so one of the questions hi alex hey paul what's really amazing this time is very important uh from the perspective of resilience uh we have uh we have the concerns about how to be to have an application how this application the part of data and not only data and trends but data in rest is resilient it's so much important to focus on how you use will store your data so it's it's amazing tim and we can discuss about it and how what's the better best practice for this uh for day long i i love this this presentation uh we have we have some questions a few questions about uh one for example one specifically them uh about for example uh storage class uh the question is how can specifically how can be is specific to local dc for example vmware hosted nef vi it's possible to be specifically for this kind of uh vmware feature or company there where no oh you can earn me strange oh i can i can hear you now you came back lost everything oh my god sorry i said that is uh amazing because one point important point for applications from the perspective of data not only data in trends but during rest is to how you maintain uh the resilience of the application how you store your or data how you maintain your data through ever uh execution uh so not only during the current execution but then if you fail or if you have a long running process so you can stay uh with your data in some place so it's an amazing time you can apply a day long uh conversation about this we have we have thank you so much was amazing uh i have a pleasure you here with just today uh we have a question about how you if it's possible to uh configure this kind of feature like uh i think our storage class to a specific implementation in uh uh in a specific dc like vmware nfe vi uh company it's possible to drive for a specific implementation like this absolutely so you know it's it's it's it's possible you know there are csi is is is a general driver that allows Kubernetes to to abstract out to any number of different storage systems and and they could be you know traditional storage systems you know like a hardware array in a non-prem data center but it could also be software solutions like like storage os so so effectively you can you can use that in in vmware you know if you're using these these sort of storage solutions which are based on software you can you can use it in vmware you can use it on bare metal you can use it in in cloud instances because because typically they'll they'll apply everywhere you know and it's not just storage os but even you know there are cncf projects like um like rook for example that that provides um similar sorts of things too ready uh so it's uh we have many opportunities to use any anything and anything where in the cloud or not a cloud public cloud or private cloud because you have this capability adapt for with drivers amazing uh we have another question this is about uh what why you'll be recommended for Kubernetes uh three time db replica cluster for example Galera or replicate a single db at storage layer um it's not it right it's it's it's not a straightforward answer it does depend there are different pros and cons right um doing um doing uh replication at the database layer or or even sharding at the database layer is is certainly um you know a very common architectural pattern um and it works to to to a certain extent um the downsides to to doing say you know replication with something like um Galera is that of course you have to use three times the amount of compute for example if you if you have a primary and and a couple of replicas or or a couple of secondaries so if you do replication um at a storage level uh you can potentially save some of those compute resources of course having multiple um compute resources um for for the the primary in the slave can also mean that you know you gain additional scalability because you can use the slaves for for read only workloads or or or to or to run batch reports and or or things like that as well right so so it's it's not always clear cut um the other thing is it doesn't have to be an either or solution right you can use storage level replication as well as database level replication because database level replication can give you the scale that you might need um and that doesn't just apply to you know things like Galera but you know Cassandra, Mungo and and Fittes and and Cochro's DB etc are all defined on that on that same type of architecture um but then on on the the the underlying storage um can also become a challenge when you have um a recovery scenario so so so imagine um you know you have a distributed database and you lose one of the nodes well it's obviously possible to start up another node and let that let the database replicate into the data into the new nodes but what you'll probably find is that the that replication process might degrade the performance of the overall um database for for a period of time um whereas if you also had um replicated storage you might find that the recovery process is much faster and you don't get that uh you don't get that degrade performance uh during the recovery process really uh we have another question about how to manage or across multiple DC across multiple region cloud right so so that is that is um uh that that is that is a fairly interesting question so what we'll what we can see is um you know how I mentioned that a storage system will have control plane and a data plane in a in a distributed storage system that's handling replicas you know like storage or s for example what we can find is that um the control plane and the storage system can automatically place replicas across availability zones in a cloud provider for example and thereby provide additional protection against an individual availability zone or failure domain from from taking out all of the replicas so so replica placement is is is one of the functions the other function though that that that we need to that we need to consider is the the the challenge is um around uh latency right so so if um you are doing replication across large distances um then uh you have to make a consideration around consistency if you want synchronous replication i.e. you know data is always available in all the replicas um then uh higher latency between the different data centers will have a material impact to the performance of of the storage overall um and you may want to choose to use a synchronous replication but that said if you're using for example um you know availability zones or failure domains within a particular region uh in a cloud provider you often get low enough latency that that synchronous replication is possible too i'd like to have a good question in my opinion here from jogging in our uh alternative live chat in the slack uh if you one thing that about scaling stateful workloads like db that i weren't scaling down what happens when you go through from four to three or two zero yes it lost everything well to zero it's lost everything but maybe to one right so so i think i think you have to differentiate between scaling um scaling the storage versus scaling the database uh application parts right so you can have um you can have an application uh that's that's using say distributed storage um and you can scale it up to to to to uh based on demand and then and then scale it down um you can also potentially scale it down to zero and stop running the application altogether but as long as the storage system still has some sort of scale you're fine of course if you are if you want the ability to to um scale the entire cluster and the nodes in general um uh you probably want to have a set of nodes dedicated to um to storage which you which you don't scale down you know so so you might rather than go for a completely hyper converged topology you might go for some sort of hybrid topology where some nodes are dedicated to storage and some nodes are dedicated to compute and you use the compute nodes to to scale up your application and and you maintain the the the storage nodes for for the persisted data great alex we have a great question from yogi but don't have more time here or just have five five minutes to finish so yogi will try to answer your questions then debate about this in our uh in our chat uh with alex and if alex can help us but uh alex is a member co-chair of uh a special interest group a sergeant special interest group alex we have a few time just could you please uh talk a little bit what is what's your uh what's the job of uh a special interest group storage space there's a group how can we participate in and uh how you participate in this group what is be a co-chair i want to be a co-chair what's what's uh what's his work for cncf a special interest group right let me there you go um so so the the sig is um it's an open community um we uh we have uh calls twice a month on the second and the fourth all the calls are open and all the calls are recorded and you can also watch the recordings uh on the youtube um the sig does a number of different roles um we uh we we effectively work with the toc to provide them with um storage expertise uh and storage advisory um so for example you know we help the toc when they're looking at um projects that are joining the cncf we help them evaluate and do the due diligence for those projects whether it's at uh incubation or or graduation for example um but also there are you know lots of projects that that present to the sig because you know it gets the it gets the project out into the community and after they join the sandbox it it's it's a really great vehicle to to get information about the projects there um the the other thing that we do is we provide uh educational services um to to the um to for end users effectively in the cncf community um so things like white the the cncf uh storage white paper that we that i just talked about today um but we also have um a performance uh and benchmarking white paper that we're about to launch um and uh cloud native disaster recovery white paper that that we're working on uh and again you know we we we want people from the community to help with that process um the sig itself is you know constituted by the toc we we don't make any decisions ourselves we we act in an advisory capacity to the toc the toc uh nominates uh and votes for code chairs and uh tech leads uh within within the toc sorry within the sig um and typically it's people who are uh active in the community and trying to help out so you know the easiest thing to do uh if you want to to to have an active role in the sig is to join the community calls um help with uh help with the the documents that we're creating and help with um product reviews and that obviously would get you nominated and allow you to to have a more active role oh really uh alex just to finish my my last question about the storage uh special interest group we have many guys there with specializes in in storage and how lead with with workloads that need to of course storage data etc so if you someone has a question or doubt about this concern it's a good place to reach uh the the channel from sig storage to to chat about and maybe get some help because we know that the the the group has other many many uh work to do but uh when you have a doubt you should have a uh a place to put this up then try to get help it's a good place there absolutely so so i'd recommend um people who are interested to join the mailing list and we also have uh we're also on the cncf um slack um you know if if you have um a project or you have a technical query or or or something that you think would be useful to the community and it needs to be discussed we can add it as an agenda item um but if you mail the mailing list or or uh sort of ask a question in the slack channel um there will typically be somebody who can help with that too amazing thank you alex thanks so much was amazed to have you to get today uh was an honor of course and uh uh i want to see you next opportunity yes i look forward to uh to a kubecon in real life uh sometime soon yeah i suppose in north america we can meet together meet personally uh and meet everyone uh thanks so much alex thanks so much uh thank you everyone for joining us today uh in this uh last episode of cloud native live it was great to have you alex and talk about uh work with this state for workloads in the in the cabinets that is something that not it's not stateful so it's amazing uh we also really love the interaction and the question for the algeance and we bring you the last cloud native cloud cloud name called every wednesday and next week we have another great presentation and thank you for joining us today and see you the next week thank you so much