 Okay, so good morning, good evening, good night, depending on where you are in the world. Thanks for joining today's CNCF webinar, the evolution of cloud orchestration systems for FM rule to persistent storage. I'm Kristi Tien, I'll be moderating today's webinar. We would like to welcome our presenter, Boyan Korsnoff, CPO at StorePool. If you have some items before we get started during the webinar, you are not able to talk as an attendee. There's a Q&A box at the bottom of your screen. Please feel free to drop in your questions and we'll get to as many as we can at the end. This is an official webinar of the CNCF and as such is subject to the CNCF Code of Conduct. Please do not add anything to the chat or questions that would be in violation of that Code of Conduct. Basically, please be respectful of all your fellow participants and presenters. Please also note that the recording and slides will be posted later today to the CNCF webinars page at cncf.io slash webinars. With that, I'll hand it over to Boyan to kick off today's presentation. Take it away. Thanks Kristi. Hi everyone. So my name is Boyan Korsnoff, I'm the Chief of Product of a storage company called StorePool and what we do is very fast and very reliable scale of both storage systems and like you may notice that everyone claims these things like but the difference with StorePool is that we actually deliver on them, we don't just claim them. So what we do is a software defined storage system, it's API controlled, it's used a lot in DevOps and SRE kind of environments. It's strongly associated with new IT as opposed to traditional IT and we have a ton of integrations with popular orchestration systems. StorePool is a CNCF member and it has a Kubernetes CSI driver which is the parts which are relevant to the Kubernetes ecosystem. So as I said, our product is integrated with a number of cloud orchestration systems, OpenStock and CloudStock and OpenNebula and even own up and since about a year or less Kubernetes. So we see some patterns of how storage or persistent storage functionality evolves in these different cloud orchestration systems over time and in this presentation I'll try to give you some kind of correlation between these different systems how they evolved over time compared to Kubernetes. So here's my agenda, I'm going to talk a little bit about Cattle vs. Pets and I know it's kind of an old and tired topic but I'm sure there are some people in the audience who haven't heard of this concept and it will be interesting for them to understand it. I'm going to talk about the separation of code and storage and some historical review of how these things evolve in AWS and in OpenStock and in Kubernetes and I'm going to draw some conclusions at the end. So here we go. So first of all there is concepts of pets and Cattle and you can think of pets as everything that traditional IT did. So these are servers or pairs of servers like highly available pairs of servers which are unique systems. They can never be down, they cannot be automatically deployed, et cetera, et cetera. So these are kind of traditional systems would bring them up based on kind of a written instruction or documentation from say a software vendor and then these would evolve over time with different versions of their software, et cetera, et cetera. Versus Cattle where you have many identical VMs or containers and these are created based on a recipe so at any time you could create more of them or at any time you could bring a completely new environment from scratch based on the recipe you have. And Cattle, so one of the main differences is that in the Cattle concept no individual VM or container is precious to you. You could discard it at any time and you wouldn't lose functionality from your application. The pets concept if you lose a server it's a big deal and it may cause downtime and it causes a lot of people to react to that situation, et cetera. So one thing to understand is that persistent storage is not associated only with pets. So traditional IT is pets, modern IT and kind of DevOps and SRE concepts are mostly Cattle with some small number of pets and even Cattle need, even some Cattle need persistent storage meaning that because you can bring up another instance of your application that doesn't mean the application doesn't need storage. And there's still because this transition to what we call modern IT or new IT is going to take many years. There's still many pets around and because of say migrations of applications from physical to virtual machines or from virtual machines to containers without significant rewriting of these applications. So this causes this kind of a decade, perhaps more, lag of all applications using the newer concept of everything being deployed based on a recipe. So infrastructure is code and deploying from template and treating every individual VM or container as disposable. So in traditional IT to give you one example, code of the application and storage of the application were separated on separate entities, on separate systems. The code would run on say application servers, and these will be standard tech 66 servers. And they would host what's called a multi tier application so that may have say a database and or business logic tier or it may have multiple tiers, say above that it may have a low balance or etc. And local disks in the servers will be used just for the operating systems sometimes if the servers wouldn't even have local disks. And persistence in the in traditional IT is achieved using sun or an us. And this these systems provide above all high availability and longevity of data. So whatever happens to an individual application server, it doesn't affect the availability or persistence of data in the storage system. There are always shared systems, meaning as one of these say sun systems will be used by multiple applications. And in all cases the same data may be accessed by multiple servers. And this is in both cases in the sun case and in the last case now. This concept of a multi tier application and separating where we run code and where we store data also translates directly into modern IT. So in modern IT, with this concept of containers, the main thing we achieve with containers is not is not kind of separating resources or security isolation between different application components. The main thing we achieve with containers is packaging code, packaging the application. What does that mean? It means that instead of installing the application as a software package on a standard operating system and having to deal with all the kind of continuously changing dependencies in that traditional Linux distribution, like say Redcat Enterprise Linux, what we do is we take the application, we package it together with all of its dependencies and we ship it as one whole, so the application and all of its dependencies together in the container image. So we get rid of Debian RPM and NPM and PIP, et cetera, external dependencies which may change over the life of a particular server. And that's the main benefit of using containers. And it also Kubernetes and containers give us this concept of packaging whole complex applications. So you could have, say, a Helm chart which describes a whole application which is multiple containers, multiple pods, which we didn't have in traditional IT. So both of these concepts are new in this new way of doing applications, of doing IT. What's changed also is that initially, in this great new world of everything is going to be a container, persistence or application state was considered to be someone else's problem. So Kubernetes didn't have internal mechanisms of how it could do persistence at all, so it was assumed that you have, say, an external SQL database or an external object store or an external file system or more advanced cases, an external Cassandra cluster. And over time, the idea that we could also take the persistence layer, the storage layer of the application and move it inside Kubernetes was widely accepted and now we have persistence in Kubernetes as well. So it's no longer someone else's problem. So persistence is something, if you think the application has several layers and one of these layers is storage, now storage is considered to be part of the whole application package, you could say, and it runs inside on the same nodes where the application runs. So historically, this pattern that a new, say, cloud service or cloud orchestration system starts with the concept that it's going to support only Cattle and it's not going to have any form of persistent storage. So it has been seen a number of times and in Amazon's AWS service started with this concept, so the ECQ virtual machines initially only had local storage, which means that if the physical holds that are on died, they wouldn't preserve data and then about two years later, Amazon introduced the elastic book storage service. So during these two years, adoption of Amazon, the Amazon ECQ service was very limited because it didn't support kind of this external persistent storage layer or it only supported external storage in object storage, which means for a lot of applications means rewriting them or something like that. Over time, there were more features added to Amazon EBS, so for example, even booting from EBS wasn't a feature in the very beginning when it was released, creating snapshots of it, creating clones, resizing EBS volumes, etc. These are all features which are added after the initial release of the book for each service. Very similar pattern in OpenStack initially released in October of 2010, there was some persistent volumes support added into the main project and that was fairly limited means it had a very small number of drivers or a very small number of supported different storage systems that could integrate with OpenStack and then again about two years after the initial release of the OpenStack project, the standard service was released which gave us the ability to have block storage plugins so that multiple vendors and nowadays it's like 20 plus storage vendors have plugins for Cinder could integrate against Cinder or OpenStack and provide API controlled storage services to it and again features were added over time meaning booting from a Cinder volume wasn't there initially, it was added later, migration from say local storage to Cinder or migration between different Cinder backends, encryption resizing of a Cinder volume offline and later resizing of a Cinder volume online meaning without restarting the virtual machines were all features added later. So the conclusion here is it's the same pattern as AWS, the service starts without proper persistence support and later it has persistence and my understanding is it has persistence because it's required by the users of this cloud orchestration system and in Kubernetes we had exactly the same pattern so the first public release was in 2014. In 2016 the kind of supporting stateful applications became an explicit project goal meaning Kubernetes kind of there was a public statement saying stateful sets or pet sets as they were called initially are very important to us and we support them. There was some persistence volume support added into the main project under flex volumes and then in 2018 which is four years after the initial release we got to the same situation as in OpenStack which is a pluggable architecture for storage backends so that multiple storage vendors like store pool could provide an integrated storage solution with Kubernetes. Similarly to OpenStack and AWS there were and still are features being added over time such as support for a row block instead of just file system, support for cloning for snapshots for resizing etc. So these are features which let's say OpenStack and Sinder had discovered are kind of important for everyone and if you have an API control storage system you should have these features and in Kubernetes and CSI we are again starting from scratch and adding these features one by one. So here's my conclusion. All cloud orchestration systems actually not all the examples where a specific goal of the cloud orchestration system like in CloudSack was to support legacy applications. I have a VM where I want to be able to take that and move it to a CloudSack KVM environment and put it to work. In these cases they didn't start with just ephemeral but in a lot of cases when a new cloud service or a new cloud orchestration system like OpenStack or Kubernetes is started it starts with this romantic view of a pure world where every component of every application is stateless and it doesn't need any storage and then two to four years later reality sets in and we figure out that even some cattle need persistent storage and that there are still many pets that will live for another decade, 10 years or more because of kind of this lag of adoption of the new operational model of everything like which is promoted by the Kubernetes community which is that every application needs to be able to be rebuilt from scratch using some form of recipe. So until we get all applications converted to this new operational model there will still be many pets and pets definitely need persistent storage. So for these two use cases we need persistent storage so every Kubernetes deployment needs storage and you actually need a good solution for that because it's kind of a very important and integral part of your private cloud or public cloud if you want to do these kinds of services and what we do at StorPo is provide this kind of solution so a very good persistent storage solution for Kubernetes. So these were my, this is the end of my presentation and I think we'll open to questions now. Great, thanks Boyan, a friendly reminder to anyone listening in here if you have a question that you'd like to ask there is a Q&A box at the bottom of the screen here we'd love for you to submit your question through there. Looks like we have had a few already come through so I'll just go ahead and start them. The first one is why did StorPo decide to integrate with Kubernetes? Yeah so as I said in the beginning we already have a number of integrations in these kind of open infrastructure ecosystem which is open stack cloud stack etc. And we recognized Kubernetes as essentially the winner in container orchestration and if we had to choose between the different container orchestrations and which one we should have an integration with Kubernetes was the obvious choice at the time we did it. And we recognize kind of containers and Kubernetes as a very important use case and we were always like our product was always strongly associated with new IT or modern IT and adding support for Kubernetes was kind of very natural for us it wasn't some alien concepts that we had to add to the product it's just another API integration with an orchestration system for us. Okay great, our next question is what is the typical customer using store pool and why would they choose it? Yeah so StorPo has let's first talk about in principle not just in the Kubernetes ecosystem. StorPo has many customers who are service providers perhaps like 70% of our customers are service providers of some sort which is hosting companies, public cloud operators, managed service providers etc. And then the smaller fraction of our customers are private clouds which operate in this modern IT or new IT DevOps concept. So in these private clouds they could be used for hosting a production application or they could in some other customers they're used for kind of development or continuous integration testing building etc. And in both cases these are dynamic environments meaning many over the course of say a day many volumes and snapshots are created deliberately sized attached to virtual machines detached from virtual machines etc etc because it's like a dynamic DevOps style environment. Why would they choose store pool? In addition to being like a proper API controlled storage system StorPo is very strong in reliability availability so especially if you're looking to do a production application on a private cloud environment or if you want to a service provider like a managed service provider for example. So availability and performance are some of our kind of strongest features of the product from day one. Yeah. Great okay another question just come in. What is your view about handing stateful services in Kubernetes using Helm charts versus operators? Yeah so operators obviously gives you if you write an operator it gives you more control over these stateful services right so meaning you could in the operator you could define a lot of application specific logic right so Helm charts is a more generic tool so it's like a hammer and you could apply that to running stateful services but if you want like the best possible behavior of a say a database cluster the best way to do that would be with an operator instead of the generic way with Helm charts I think. Okay we're gonna go ahead and give just a minute here for any last minute questions to come through. While we're waiting oh we just had another one come through perfect timing. What is your opinion about using CSI as a way of handling storage in Kubernetes? So CSI yeah I'm not sure I understand the question but I'll give it a try. So CSI promises to to give you like a unified interface to all persistent storage systems and which is two-fold one it defines like a set of APIs that are common to all storage right such as creating a volume deleting a volume resizing a volume etc creating a snapshot creating a clone etc and on the other hand CSI because it's like a very stable interface has a number so tens of different storage providers behind it so if you are as an application developer remember I mentioned about packaging whole complex applications it's something unique in this new Kubernetes and containers ecosystem this is something we didn't have in traditional IT. So once you have packaged your application you could deploy that on different infrastructure regardless of who the storage vendor is so you don't care if it's Dell EMC behind or if it's a store pool or if it's one of these newer like container specific storage solutions right so this gives you a lot of kind of strength amplification once you package your application you could deploy that say with minimal modification you could deploy that on different infrastructure and you could achieve that because of CSI because CSI has tens of different storage plugins behind and it's some complexity that's hidden from you as a user of Kubernetes. Yep. Perfect. Yeah I was going to ask Boyan are you a store pool going to be at KubeCon North America where are some other ways that people can engage with you? So I don't think we're going to be at KubeCon drop us an email at info at store pool com and we'll take the conversation forward. Okay great well thank you again so much for a great presentation. Thank you to everyone who attended today really appreciate it. A friendly reminder that the recording in the slides will be posted later today to the CNCF webinars page that's cncf.io slash webinars. We look forward to seeing you at a future CNCF webinar and stay safe out there. Thanks everyone. Bye. Thanks. Bye.