 Well hello everybody and welcome again to another OpenShift Commons briefing. This time we have Iran Tamir, who is our OpenShift Container Storage Product Manager, and he's going to talk about a topic that's new to me, though I'm very interested in this one, the multi-cloud object gateway. So I'll let Iran introduce himself, there's live Q&A at the end, and as always this will be uploaded onto the YouTube channel for our OpenShift and along with the slides. So Iran, take it away. Thank you Dejan, and today as Dejan said, we will talk as part of the OpenShift Commons briefing, we will talk about the multi-cloud object gateway, which is part of a product called the OpenShift Container Storage. So let's start. Let's start with what is OpenShift Container Storage actually. So the OpenShift Container Storage is a component, it's a product available as part of the Operator Hub, available on every OpenShift 4.2 and higher. And what we try to do with this product is to create a very highly scalable and production grade persistent storage that is really optimized to run with OpenShift targeting stateful application. We try to create a very integrated user experience, which means that everything starting from the installation and ending and going through the installation process itself and the monitoring data operations, everything is integrated within the OpenShift console. So you can learn very easily what to do. You can very easily make sure that you have everything in place to run your applications and use this storage. And of course from a commercial point of view, it's very easy to work with one vendor. And that's in a high level. If I may say what is the main thing for me, I would say that becoming a diagnostic layer for the storage is the most important part. Because if I'm looking at OpenShift as a platform, the fact that it's agnostic, you can run it anywhere, you can have it the same experience on-prem and in the cloud. OpenShift container storage is the layer for storage that would now allow it for the data and for the stateful applications. So what do we have in the OpenShift container storage? We have three services. We have the block, we have the file, and we have the object. And today we will actually focus on the object story. But just to give you the full picture, that's how it looks like. So wherever you are working with OpenShift, OpenShift container storage will be there for you and provide these three services by default. No need to configure anything. Simply deploy OpenShift container storage and you will get these three services and get all the value that I mentioned before. Now we will drill down to the multi-cloud object gateway, which is one of the components. The idea there is that you can start lean in a very lightweight way, which means that once you deploy the services up and running, you can start using it. It's very easy to get the endpoint access key and secret key and have a service which behaves like Amazon S3 compatible storage, but it's running in your OpenShift. It's running locally. And whenever you move your application, so if you are using the Dev environment and then you're moving to test staging and production, it will behave exactly the same way. And from the application point of view, you don't need to change any code and I will explain what I mean soon. The second phase would be scale. How can I scale? And you can easily scale internally by using local volumes. You can scale by using internal storage in your data center if you're running in the data center. And of course, you can use the native cloud storage for hybrid and multi-cloud scenarios. So let's start to talk about what are the attributes, what are the characteristics that we have for the multi-cloud object gateway. So first, it's important to understand that it's mainly data management. I mean, we do provide an S3 API and that's the interface for the applications and I will explain it in the next slide. But by that, we actually embed many functionalities. And for example, every data that is written to this component will actually have it compressed. We will have an in-land need application and everything is secured in transit and interest, which means that whenever you're writing data, we actually have our own format in the backend. And we always have a backend. We always have something we call backing store. And by default, whenever you're running on-prem, by default, it's on a component, internal component, the RGW, if you know it. If you're running in the cloud, it's the cloud native storage. So it's always a very nimble storage underneath, but you will always get all these benefits by using the OCS API here. On top of that, we have data management, meaning that you don't need to take hard decisions before you start running. You can simply start using OCS and start using the multi-cloud object gateway and then take a decision of like, okay, where do I actually want the data? Do I want it on-prem? Do I want it on-prem and mirror to the cloud and so on? And I can take this decision, I can take various decisions along the time. And I will show you in a second. Important to say, and that's the logo that you see here, the entire multi-cloud object gateway component is based on Nuba technology. Personally, I'm coming from that startup acquired by Reddit about a year ago. And that's the, that's this logo that you see currently in the slide. And that's how it looks like. So if you're looking at OpenShift and we have OpenShift container storage installed, we have Nuba, we have the multi-cloud object gateway provided by default. And that's how it looks like. So on the left side, we have the applications. The applications are any application that can currently use AWS S3. It can be a custom application, it can be existing application, any vendor that has an application like backup application, so on. They usually have S3 API integration. So you can use that as well. So these are the applications. They always use this S3 API provided by the multi-cloud object gateway. On the right side, we have all the flexibility hidden underneath. So as I mentioned before, by default, you can immediately start working. You don't need any configuration. But when you want to start progressing and scale and start thinking about the DevOps and how are you going to deploy it for customers in productions, you can start playing with this flexibility. As I mentioned before, you can use local resources on-prem. You can use the local PVs that we also provide as part of OCS. You can use cloud-native storage, regardless if you're running on-prem or in the cloud. It will always be available for you. And you can have a combination of any mixture of this native cloud buckets or local storage to create hybrid buckets. And you can take this decision for every bucket of data. So one bucket can work locally. Another bucket can work in the cloud or have multiple mirrors in the cloud. We support it all. When we are talking about even more advanced configuration that will be part of the near future in OpenShift itself, it opens many additional opportunities to walk, to have locality, for example. So we can have multi-cloud object gateway in each one of the environments. And we can replicate data between these clusters. So customers or applications that are running on the upper cluster can use the data and have it locally, which might be important for performance, for example. But also whatever it's written here, it will be replicated to the cluster on the bottom and so on. So it actually expands more and brings to the table more opportunities. I didn't mention the UI. Sorry. I did mention the user experience before. And also for this component, we have its own UI. As you can see, it's very easy. It's very clean. And one of the things that we are currently doing is to bring most of the value directly to the OpenShift dashboard so you don't even need to go to this area by default. We are bringing all this information directly to the OpenShift dashboard, and it's already part of our versions that are running currently under OpenShift itself. Now I would like to have a little deep dive. It's not that deep, no worries, but it's important to explain a bit how it's working to understand that we actually bring also many solutions for security issues, for example, and questions that usually start popping up when you're talking with customers about cloud usage, for example. So whenever an application is writing data to the multi-cloud object gateway, we have fragmentation. So we chunk every data to multiple chunks. We have the deduplication. So if something is already written, if it's part of a movie, if it's part of a text file, if it's part of a presentation, if it's a picture that we already saved, we will eliminate it. We will not go on and write the data. We have the compression and we have the encryption. So whenever we are writing data, we can actually decide that we are storing the data in one of multiple locations, and then the result would be that all the metadata data is, we keep all the metadata inside the multi-cloud object gateway, together with the keys, and the data itself is encrypted in small chunks, and it's either on-prem or in the cloud, but it's always the same, always encrypted, always small chunks. For part of the customer's separation between the key and the data is very important, and also the fact that they can control the keys, and even if someone breaks into their cloud accounts, the data is not really usable. I would like to mention additional security features, again, because this is part of the first questions that we usually get about encryption. So as I mentioned before, we have encryption in rest and in motion. Anonymization masking is something that we also have for every bucket. We have triggers, so the customers can build their own processing flow. So for example, I want to scan any every object that are writing to the bucket and make sure that it does not include a social security number or a credit card information. I can do it. I can trigger a function that will scan my object. Let's assume it's a log. It will scan the log, make sure that it does not include any private information, any privacy concern that will mitigate it by that, and then it will be written to another bucket, for example, that is actually in the cloud. That's just an example. If we have genomics information, we can actually chunk it by a preset and decide that this part of the data will be written to a private location. Another one will be replicated to the cloud. If there is a health record, we can take the patient information, write it to the database, remove it from the health record, and then write it to the cloud, and so on. All this enabled by having functions and triggers as part of the buckets in the multi-cloud object gateway. Another mechanism that we have, and it's going to help us when we will introduce the warm support, is the fingerprinting. We have a fingerprint for every data that we keep, and we keep tracking and checking it and make sure that the data is always intact. If we discover that something is wrong, we quarantine it, we delete it, and we restore it from a trusted location, and everything is automatic, of course, and the idea is to create a very high trust with every storage that we are using underneath. Last slide before moving to questions. It's about the technology. As I mentioned before, the multi-cloud object gateway is based on Nuba technology. It's now an open source project. You can read about the Nuba project in nuba.io. We have a GitHub rapport for our core technology for our operator and CLI, and so on. Everything is available for you to read and interact, and, of course, to contribute code, if you like. The Android version is part of OpenShift container storage. We released it on January 2020. We get a lot of good feedback about all the features that I mentioned, so that's our current journey. You can read more about OpenShift container storage under openshift.com slash storage, and I'll be happy to take any questions that you may have. All right. Well, thank you for that, and we do have a question from the audience. Rob is asking, is there a suggested configuration by Red Hat to optimize the performance in an OpenShift cluster? Is that true that OpenShift has the best performance on HW? Is that high availability, maybe, clusters, or with the right configuration? You're talking about hardware? Hardware. Okay. Sorry. I had my head up the high-availabilities alley. Okay. So that's a very timely question. We are going to release our bare metal version next month, and we're currently testing it, so we'll be able to recommend, but in general, you don't need to have anything special. More than that, in one of the next versions, not in the one next month, but the one right after expected on May, we will have auto-scaling. So whenever you start, it starts as an entry level, but if there is load, if there is an activity that requires more resources, the auto-scale will kick in and we'll try to support it by simply creating more endpoint that will serve the data transparently. So we do have all the mechanism. We do have all the tools, I would say, to support performance, and I hope that we'll be able to provide the numbers as well. So at the moment, I'm not seeing any other questions, which usually means our speaker has done a great job covering off most of the answers. Thank you, Erin. And again, if you are coming to KubeCon in Amsterdam, coming up in a few weeks, actually March 30th, we're going to be hosting a container storage hand-drawn workshop at the OpenShift Commons gathering, and I will put all into that in the chat. And if you'd like to, that's for the price of admission for the gathering, which I think is 49 euros, you can have an all-day, or a half-day rather, hands-on workshop on container storage and learn a little bit more about this. So if you're looking for those details, I'll add them into the blog post, which will have this YouTube video embedded in it, and we will hopefully answer some more questions in person in the coming weeks. Again, OpenShift.com slash storage is sort of the landing page for all things storage that we're working on, and the new page on GitHub has a lot of the information as well around the multi-cloud gateway, object gateway stuff. Any last words, Aaron? No, thank you very much for having me. It was fun, and hopefully I will see you at KubeCon. Me too. I'm looking forward to it. So, I'll prepare everybody and join us again next week for another couple of OpenShift Commons gatherings on lots of different topics. You can always find it at commons.openshift.org slash events as the updated calendar. Thanks again.