 The first step is to of course learn about how to connect your database or database services to your applications. And we have Mike Pesh from Red Hat who is here to speak to a very interesting solution that his team has been working on. Mike is a VP and a general manager for cloud storage and data services. And he's leading the Rode initiative at Red Hat that he's going to talk to us about today. So over to you, Mike. First off, thanks so much for the warm introduction. I'm super excited to be in front of OpenShift Commons here. This is actually my first time presenting here. So that's exciting and very honored to have the keynote slot here. And I personally and passionately believe in this particular area that we're putting a lot of investment into. So I hope you'll also find it worthy of keynote here, given all the things that we're talking about today. I hope this will be a nice framing for the data-related solutions and technology discussions that we'll be having for the rest of the day. Again, my name is Mike Pesh. I'm vice president general manager of a business unit at Red Hat called Data Services or Cloud Data Services. We today have, we were formed out of pieces of some other BU's cloud storage and we have some brand new technologies that have come out of the office of the CTO here. So this is very much a small and new part of Red Hat with exciting growth areas that we're doing very new things in. Another thing to note about what this business unit and what I'm about to talk about is in terms of a business model and a delivery model is that these are managed services. So the technology that we're talking about here is offered in as a service, software as a service SaaS model, which is a new area is a different thing from what Red Hat has done in the past and what Red Hat is known for. So keep that in mind that from that angle what we're talking about here is new for Red Hat. Now, so to dive down into the specifics of the topic at hand here, we're talking about database access for developers and management of that access for administrators of OpenShift customers clusters and OpenShift environments more generally. So the types of concerns that we're gonna talk about here are cross cluster and very much representative of the hybrid cloud environment and hybrid cloud strengths that Red Hat is known for. So let me first sort of set it up. The premise here, the starting point for what we're trying to do is that connections should be easy, right? And connections in a Kubernetes environment in a highly distributed, complex, multifaceted environment can seem daunting. And if done, shall we say suboptimally, if done in a not intentionally managed sort of way, connections and working with data can quickly become crazily unwieldy. And what we wanna do is we wanna make connecting to a database as simple as plugging your ethernet cable into your router, right? So connecting should be easy. So Jalem talked a little bit already about some of our own research data around the prevalence of data bases and data related workloads in OpenShift environments and more generally in cloud environments. And I'm gonna reshow that slide in a second here just to put a finer point on just how amazing, how widespread that phenomenon is. But here's another statistic from IDC who says that 90% of enterprises are already actively moving production data to the cloud or adopting cloud databases for new workloads or will do so within the next three years. So 90% pretty impressive number. So that's big enough that it's probably fair to say that most of you out there are firmly in that camp. You're doing cloud-based data, cloud-based databases, cloud-based data services. And again, just to re-highlight the point Jalem made from our own survey data earlier, 76% of the top workloads in Kubernetes environments include databases and data caches, right? So this is, you know, it's easy to say, yeah, every application needs a database, you know? And here's some of the real numbers to just show how dramatic the share of workloads really is. Now in a cloud environment, there are at least two broad categories of how you might set up a database and more generally your data environment, right? They're self-managed, right? So you can go in your OpenShift cluster today, whether it's something that you're running on-premises or whether maybe you're running it, you know, on Amazon or Microsoft Azure or Google Cloud and go ahead and have your administrator install a database and set that all up and somehow communicate and publish connect strings and all the data that your developers and application engineers need in order to connect to and use that data. And, you know, that as a self-install, do-it-yourself type of setup, that gives you a lot of flexibility, but it also implies a fair amount of burden of setup and administration on the part of your own IT department. And just to be fully fair and open and disclosure, you do have more control over the bandwidth, right? You, as an internal setup, you can optimize sort of connection bandwidths and so on. Database as a service is the idea of having a database managed by somebody else out there in the cloud and an application developer and, you know, later the operator slash maintainer maintains just a very lightweight client-side connection and all the grunt work of, you know, the redundancy, the backups and so on is all handled by that database as a service provider, right? So in contrast to the self-managed scenario, you've got easy signups, it's managed for you. You can set parameters to enable auto scaling so you're not having to worry about scale up, scale out, all that sort of thing, sharding, et cetera. There is, you know, part of what you trade off in order to get that is you trade off some flexibility, right? You're at the mercy of what has been exposed through APIs. You do have lower complexity. And then of course, you know, since you're connecting to this database over, you know, the internet, depending on, you know, you might both be in Amazon and both be in the same region. So that could be pretty good if, you know, you're in a private data center and you're connecting to somewhere, you know, let's say in Azure. Well, you know, so you've got to make sure that you understand the bandwidth capabilities and what your particular problem domain needs. But that's a quick side-by-side of those two scenarios. Now, managing database as a service in, you know, a typical larger enterprise or even medium-sized enterprise where you've got, you know, probably not even just one, but multiple OpenShift clusters. You've got many applications. You've got many development teams carrying out different activities at different stages of an application lifecycle, right? You might have mature applications that just are connected to one or several databases and there's not too much to do there. You might have some early development where you've got a lot of experimentation, a lot of standing up and tearing down of database connections. So, you know, you can imagine that if you've got app developers, you know, in one or more clusters, you know, just willy-nilly reaching out and putting in their credit card data and signing up for database as a services, things can quickly get kind of crazy, right? You can end up with lots of redundant instances. You end up with potentially, you know, unconstrained usage. You can end up with a lot of redundancy and the actual connections. So inefficiencies in how different applications coming from one place are connecting to a single database instance. And then, you know, probably most important from the admin side of the house is like, all these developers are making all these connections and they have no way of knowing what's going on. There's no way to monitor the traffic or set any sort of policy, let alone, you know, control what's actually going on. And just to put a finer point on that notion of, you know, unconstrained access, there was an article a couple of weeks ago and Cyclic, an online media property, great title, why sometimes you should press the 100K button. And without going into why he's arguing that that's a good thing, the sort of representative kind of snippet here is, you know, with the JSON data flowing, data scientists are onboarded, life is great for a while until one day at one of the many status meetings, the leadership points out that your group has burned through the entire year's cloud budget and it's only May. So you go into, you know, somebody goes into the cost explorer in Amazon and that trickle from multiple fire hoses, all these different developers, data scientists doing all this stuff has accumulated an S3 storage bill of almost $100,000 a month, right? So that's, you know, a very real phenomenon out there and very much the kind of thing that we're trying to address with the technology I'm about to talk about. Now, another aspect of that, the challenges slide that I just went through is, you know, so setting up a database as a service, like let's just do a quick walk through that, right? So you go out to the service, in this case I'm using MongoDB Atlas as an example and to be clear, right? This is no disk on Mongo, it's a fine workflow and the others have a similar sequence, right? So you go fill out some stuff, you verify email, then you get into a welcome screen, you start choosing, you know, various configuration parameters, you know, you're free or what kind of price tier you wanna be at, you set up a shared cluster, you set up some security parameters and credentials, you know, so basically, you know, a dozen steps and you're at a point now where you've got a cluster set up, you've got a login username, you've got a password, you've got the credentials you need that you can now go back into your application development environment, enter that data and connect to this database. Now, again, fine workflow makes a lot of sense to do, you know, that setup time, you know, on an infrequent basis. Now you imagine, you know, many, many developers in a typical development environment all doing this every time they wanna go do a database, well that's obviously pretty inefficient and fraught with potential errors, developers might not know what a lot of the configuration parameters even mean and what to choose, et cetera. So this is exactly the problem that, one of the problems that we're trying to address with Red Hat OpenShift Database Access or affectionately referred by its acronym as ROTA. Now, the idea here is to take database as a service connections, have an administrator be able to pre-configure them, preset them up and put them on the shelf, so to speak, in an OpenShift environment, then thereby allowing developers to just go connect to that already set up local representation, local instantiation of that database as a service without having to go through those dozens or so steps that I just highlighted previously. So, and we'll see in a moment just how much simpler that is for the developer, but now you can also see that by virtue of having this kind of centralized kind of management of a set of connections to databases as a service for a given OpenShift environment, we now have some data, we now have the ability to monitor, we now have the ability to put some control, some policies and so on, some access control over these different database as a service connections, right? So just in a nutshell, faster and easier self-service for the developers, more efficient connection and database utilization and then that centralized monitoring and that consistent control plane for the administrators. So let's get concrete this, and we'll see in our timeline in a little bit, but this technology, this offering is in early access right now. So it just went from, from alpha to what we're calling service preview in the last 24 hours. So we've added some new features beyond what we started with back in November, but anyway, this is what it looks like in a nutshell today, right? So if I'm a developer, right? And I'm in my OpenShift environment and I'm looking at my topology view here, I've got a test app all set up and I want to add a connection to a database as a service and have a database from my app. I click on add, I get a screen with a number of different types of things to add. I go into the connected database area. That gives me a number of options and as we'll highlight, we're coming out the gate here with three database as a service partners. We've got MongoDB Atlas, we've got CrunchDB and Crunchy Bridge as they call their service and CockroachDB. So I go ahead and I connect to that. Now there may be multiple databases within a given database as a service setup in that OpenShift environment there. So in this case, there was only one. So that's the one I select, but I could have more and select which one of those I want to go. And then I get back to my topology environment and I can literally drag and drop a connection from my application to that newly instantiated connection to that database as a service and have all of the connection string and so on injected into that application without even writing any specific additional code for that. So that six step process is a very quick and easy workflow for the developer using a Rota connection that has been set up by an admin. Now on the admin side, so the admin in order to set up a connection, they'd go through the 12 steps and set up for each of the database as a service providers they wanted to enable within a given OpenShift environment. And then what I just won't re-walk you through all of that workflow, but what I did want to show you right here is that here's an example of the visibility, of the monitoring screen where the admin can see what clusters are connected to what services and what users and what apps, right? So there's, and we'll be sort of further flushing this out over time, remember we're in Alpha Service Preview right now so we're in that stage where we're getting input from our early adopters, early users and learning all the use cases and learning all the desired metrics that our administrators are going to want to track as their developers get more comfortable and start really using these databases as a service connections at scale. I want to highlight a couple of kind of use case categories, you know, this is a very general purpose capability. Obviously, you know, almost any app needs some kind of data management. So the possibilities are endless, but I did want to highlight two particular categories where using a database as a service versus standing up an internal self-service database might be just the thing, right? Now one of these is an enterprise that may be highly distributed that has many open-shift clusters, many open-shift environments, but where they want their developers and their applications to share have easy access to sharing data again across that distributed estate, right? So that's one area where rather than having a self-managed database in let's say one of the data centers or one of the domains under that enterprises control, if they're using a database as a service, it's super easy and it's the same access for basically any of their environments, whether they're on hyperscale or public cloud environments or on-site, you know, self-managed on-prem setups or some hybrid combination thereof. A second category is if you've got an enterprise where you've got lots and lots and lots of transient setup and tear-downs of different databases, whether that's a lot of let's say agile new app development, maybe that's data science, machine learning, model training, and we'll spend a couple more seconds on that in a moment. But in any case, there are many environments out there where just super easy, super fast setup and tear-down for the developer with minimal overhead, right? With minimal, oh, I gotta go ask IT to set this up for me or I gotta contact my cluster admin. This database as a service setup within OpenShift could be just the thing for that type of environment. So just again, hardly comprehensive, but two example categories and types of use cases where this could be very important and very helpful. So a quick note on ROTA with AI and ML, in data science types of environments. I wanna highlight our sister offering here, Red Hat OpenShift Data Science, ROADS, that is also in field trial. So just about to flip the GA. So more than beta, but just a hair under GA is it's kind of state right now and you can look at that separately. But the idea here is these are sister products and in many machine learning data science types of environments, you have a lot of this rapid setup and tear-down for whether it's model training, whether it's sort of feature engineering, all that sort of thing. And the self-service and ease of setup nature of the database as a service approach, we expect to see a lot of opportunity, a lot of synergy for those sorts of environments. And this diagram here just depicts the sheer variety of personas you have, data engineers, data scientists, the app developers and so on and all of the different phases of an application that incorporates machine learning, all the different stages and the different data implications of those stages. So as more and more enterprise applications involve more and more learning and data science capabilities, there's just going to be a lot more of this transient and again, quick set up tear-down of data stores for which database as a service would be a great benefit. Just to highlight the, okay, why Red Hat? Part of what we're bringing to the table for sure is that expertise and that respect, that reputation in what we do in a hybrid cloud environment. So we're very open and inclusive and you'll see in a moment, the idea here is to bring in as many good partners as we can get set up here. It's a fully managed cloud service, as I mentioned at the beginning of the presentation and that is an aspect that you're gonna see increasingly in Red Hat offerings. And as we, our SRE team is top notch and we are investing heavily in this area because this is where many of our customers are going. They want Red Hat to manage more and more of their technology estate on their behalf. So the as a service model is just exploding. Goes without saying, but where Red Hat is all open source. So everything we're talking about here is very much, it's up on GitHub, you can go look at it, you can participate all the usual benefits of that dimension to the Red Hat kind of way of doing things. And then finally, partners, which are super important in this environment because again, what we are fundamentally doing is enabling partner database as a service providers. We ourselves are not running a database as a service. We're running, we are enabling connections to partner database as a services. And just again to highlight, the first three out of the gate here, we've got MongoDB Atlas, we've got Crunchy Bridge, we've got Cockroach, they've all put skin in the game, helped work on building those OpenShift operators to enable the workflows that I showed earlier. And we have our own team who has worked with them and done a lot of work as well to make those operators super easy to install, very reliable, et cetera. So the partnership there is super important and look for that list to grow over time. So just in the interest of time here, try to keep us on schedule. And funny enough, timelines, what the slide's about. So as I mentioned, we went out with our alpha of this back in November. So we've been live for a couple of months and gotten a bit of input and feedback so far. We have just today flipped over into the next sort of level of, let's say, doneness of rigor and testing and additional features. And we're calling that service preview. We expect to go to beta in the sort of mid-April timeframe. And as of right now, depending on the feedback that we get and the kind of usage patterns we start to see and what we feel we really need to add to make this thing ready for showtime, we're looking to see that field trial and get closer to GA by the end of the year. So that's the kind of the timeline in a nutshell. On that service preview, this is again, something that you'll see increasingly as Red Hat moves into managed services. We'll put new services out there in this alpha or service preview type of mode where it's free. We just wanna get folks logging in, setting up accounts, doing, working through the tutorials, trying things and giving us feedback. And that's how we wanna make this a solid relevant product solving problems that you out there in the community have. And ultimately to make this something that's valuable, something that our customers are really gonna want to use in the long run. So I will end with this note, go to red.ht slash dbaccess and from that URL, you'll log into your Red Hat console, you'll see how to get started with Rota Red Hat OpenShift Database Access. And basically, you know, it's all free. You'll get, you are able to set up a free trial database with those three providers I mentioned. There's an email address there for support, dbaccess-alpha-support-redhat.com and we invite you to come in, try it out, kick the tires and feedback, feedback, feedback. That's what we need to make this thing awesome and so that you guys all love it. So thanks so much for listening. Wish you best of luck in your data related projects on OpenShift out there. And we really look forward to working with you as we go forward with this.