 Hello and welcome. My name is Shannon Kemp and I'm the Chief Digital Manager of DataVersity. We'd like to thank you for joining this DataVersity webinar, Modernize Your Data Architecture to Deliver Oracle as a Service, sponsored today by Robin Systems. Just a couple of points to get us started. Due to the large number of people that attend these sessions, he will be muted during the webinar. For questions, we'll be collecting them via the Q&A in the bottom right-hand corner of your screen. Or if you'd like to tweet, we encourage you to share highlights or questions via Twitter using hashtag DataVersity. And if you'd like to chat with us or with each other, we certainly encourage you to do so. Just click the chat icon in the bottom middle of your screen for that feature. And as always, we will send a follow-up email within two business days containing links to the slides, the recording of the session, and additional information requested throughout the webinar. Now let me introduce to you our speaker for today, Rob Martin. Rob is a solution engineer at Robin Systems with more than 25 years of experience with Oracle technologies. Prior to joining Oracle in 1994, he worked in both application development and database administration amid Oracle's database and tools ecosystem across multiple operating environments. Having spent more than 23 years as an Oracle solution engineer and enterprise architect, he is well versed in Oracle's core data platform strategy as it relates to both on-premise and cloud-based deployment models. At Robin, he focuses, his focus includes specializing in the benefits of containerization with the Oracle community by demonstrating the value of Robin's software-defined application orchestration framework and its ability to provide rapid service provisioning and lifecycle management for the entire Oracle stack. So with that, let me turn over to Rob to get to our webinar started. Hello and welcome. Yeah, thanks, Shannon. Yeah, thank you and thanks, everybody, for this opportunity to introduce you to the Robin platform. Basically, in a nutshell, Robin makes it extraordinarily easy to deploy any application on containers. Our real bread and butter happens to be focusing on data heavy type workloads, stateful workloads, of which obviously Oracle is a big part throughout the whole ecosystem of data heavy, data intensive type applications, including that is in the big data landscape, AI ML type pipelines, anything that requires storage persistence, network state persistence, these things have historically been pretty challenging to be able to containerize successfully. And so what Robin brings to the table is essentially a viable Kubernetes platform viable for the types of applications. And so we've coined this phrase, hyperconverged Kubernetes, many folks ask where this comes from. In fact, sometimes it tends to communicate this notion that Robin provides an appliance. Robin is actually a software only stack. In fact, it was the first time that Robin was able to provide an appliance. Robin is actually a software only stack. In fact, it was the first and is still the only Kubernetes distribution, if you will, that combines its own software defined block storage stack. It's actually an application aware storage stack, along with the networking virtualization and the containerized compute virtualization that obviously Kubernetes is well known for. But what Robin does is it solves a lot of the complexity challenges, a lot of the technological gaps inherent in Kubernetes with its ability to be viable for stateful apps. And so that's where Robin tends to focus. So today, of course, we're focusing on Oracle. Oracle is just one of many software stacks that Robin can support. And of course, Oracle's tried and true, been around forever, a very widely and deeply trusted technology, of course, very well proven with its ability to support mission critical apps, of course, being SQL based. Who doesn't know SQL, right? So it's got that familiar sort of language. The track record speaks for itself. There's a lot of history in Oracle. There's a lot of maturity. And not just from a product maturity and proven, you know, from the standpoint of having a proven track record, but arguably Oracle is one of the most innovative database platforms out there, right? So very widely adopted. And therefore, you know, you could probably rock in any direction and hit a DVA or an Oracle developer, right? So very easy to find the skill sets needed to either develop applications on Oracle or to run Oracle databases. And of course, with its long, storied history, you know, there's of course an enormous, you know, partner ecosystem with Oracle. So a lot of history there and a lot of success. But with that, you know, like with any sophisticated, you know, database management system, there are challenges. There are complexities, you know, whether it be around provisioning, right? I mean, any DVA that's been around Oracle for a long time will probably be able to say, well, you know, installing Oracle is not that big of a deal, right? It depends on whether, you know, whether RAC is involved and how much interaction there needs to be with the sysadmin folks, the storage admin, network admin folks to kind of orchestrate all that's necessary to get the infrastructure in place in prep for that type of an install. But all of the mechanics aside, right, typically there's a lot of time spent just in the approval process, right? In any large organization, there's typically a lot of, you know, a large workflow associated with submitting a request to provision a new Oracle database installation. And then once, you know, once provisioned, you have other, you know, you have other types of activities, administrative type activities, dev tests, you know, refreshes, clones, you know, even if it's just a core tech type environment and EBS, something like, you know, E-Business Suite isn't involved. You still have, you know, quite often a continual need for being able to rapidly, not just provision new systems, but to, you know, stay on top of the periodic refreshes that are, you know, that are demanded. From a, you know, hardware cost perspective, right? I mean, this is always a challenge associated with Oracle, you know, as you continue to clone and manage and stand up new systems, to stand up new projects, et cetera, right? You invariably result in a certain degree of sprawl, okay? And, you know, that whole silo challenge that is an age-old challenge, you know, Oracle itself in 10G sought to address this with the whole grid computing model where, you know, RAC was really, you know, maturing and allowing for a great degree of consolidation of applications into a single database cluster. There's been all kinds of initiatives, whether it be from vendors like Oracle or partners of Oracle to try to address these types of challenges. And of course, there's licensing challenges, obviously, that are associated with this as well as a function of the sprawl of that hardware in response to having to stand up more and more databases throughout the, you know, throughout the IT landscape. Remaining elastic, right? Being able to respond quickly, dynamically to the changes in computing demands, whether it be from a CPU or memory perspective, right? So being able to dynamically and elastically scale up, scale it down as you have clustered type deployments, being able to scale out, scale back in, right? This is almost dovetails in with the previous bullet, right? Where you're wanting to make maximum use of the infrastructure to get the most out of that infrastructure, right? Without, you know, wasteful provisioning. Business continuity, right? From the standpoint of being able to ensure uptime, there's all kinds of technologies out there from storage vendors, server vendors, you know, around clustering and so forth to address business continuity. Oracle obviously itself has real application clusters to address HA. You know, there's lots of ways to skin that cat. There's typically additional investment involved, and there's invariably going to be additional complexity involved, depending on which of these technologies is employed, right? So, but in any event, HA is typically some concern to some degree or another, even for those, you know, SLAs aren't really stringent. You know, HA is at least, you know, a lingering, you know, a lingering thought, lingering concern there that needs to be addressed. And then finally, from a cloud migration perspective, cloud is obviously increasingly popular. There's folks that either are making wholesale shifts to the cloud or they're just, you know, dipping their toes in the cloud. There's a fundamental need to be able to move to the cloud and back out to on-prem or do something in between to move across cloud. With that comes challenges associated with migrating applications. And in this context, migrating the application or the Oracle database from on-prem into the cloud as folks seek to, you know, to embrace that type of deployment model. Okay, so what's needed basically here is this notion of, you know, database as a service and agile, you know, Oracle as a service type model. Development in QA, you know, they want self-service provisioning. They want it, you know, such that it can be done very, very quickly, you know, without having to go through all the red tape and necessarily, you know, typical as part of that process through, you know, corporate processes. They want simplified, you know, management, streamlined management of those environments to go along with that quick self-service provisioning. And they need performance, right? Performance standardization. From an IT perspective, platform standardization is particularly interesting, right? It's challenging for DBAs to have to manage databases across multiple operating systems, multiple platforms. So some sort of standardization is always a great value from an IT, you know, an ops perspective across platforms. Maintenance and support, lowering the cost associated with these, streamlining that you know, and freeing up their cycles to be able to innovate, right? Is also critical. Cost reduction, IT being highly, you know, regarded as essentially a cost center. There's always pressure to control costs, cut costs from that standpoint. And from a business perspective, it's all about, you know, again, innovation, but, you know, faster time to market generating new, you know, new ideas and from those ideas to, you know, to produce, you know, new innovative products to the market, right? Faster time to value the market. And then obviously, you know, cost reduction and building out a platform that's going to have legs, right? That's, you know, from a longevity perspective, future-proofing that platform you know, to make that investment really, really count in the long run. So, you know, so how can Robin help? Well, I mean, Robin essentially provides, you know, as was, you know, stated initially, right? It's a software-defined application orchestration framework. It's a unified platform that provides really everything in a single stack. It provides really uniquely the ability to work with their own self-service rapid provisioning capability. So, you know, deploying things like Oracle database homes, databases there and, you know, as much as an order of magnitude faster through that process than, you know, than is otherwise available. Being able to do lifecycle management tasks, then, you know, subsequent to that initial provisioning, being able to snap not just the storage, but to be able to snap the entire application, in this case the entire home, including all the, you know, all the various capacity settings, in the case of RAC, the topology of the cluster, right, whether it's a 2, 3, 4, 6, 20 node cluster. And then being able to clone that for whatever purpose, right, whether it's a typical refresh type operation or perhaps a matter of wanting to clone an environment from production to dev test in order to be able to, you know, perhaps reproduce a problem that might have been encountered in production. And then, you know, making good on the promises of containerization and virtualization, right, to the extent that folks really try to make good on that by truly consolidating and, you know, doing more with less infrastructure, consolidating densely. You can, you've got the inherent capability with containers to be able to consolidate much more densely than you can with, you know, a hypervisor based virtualization strategy. And so, you know, there's a lot of promise there. And but unfortunately without the ability to provide any sort of workload management or resource management capability, a quality of service type layer in there to ensure that all these disparate workloads that might have previously been running on silos, right, in their own isolated fashion, bringing those all into a single shared grid type deployment model, you know, now you're looking at that noisy neighbor effect that typically is going to ensue, right, all those disparate workloads are conceivably going to start stepping on one another. Right, so having a mechanism in there, quality of service management piece for being able to guarantee SLAs to be able to guarantee that those, all those workloads are going to play, you know, play nicely together is critical. And that's something else that Robin brings to the table. And dynamic scaling up, scaling down, scaling out, scaling in, regardless of the application. And this presentation we're focusing on Oracle, but again, Robin can support any application workload, any distributed application, any composite, you know, type stack, you know, RAC is the best example in the context of Oracle in which, you know, it's clustered. And so, you know, being able to scale that out very dynamically just as you might need to scale it up or back in or back down is key. And for those folks who aren't necessarily adopting RAC, whether it be, you know, for cost reasons, for whatever kinds of reasons, there may still be the need for HA. And so, you know, Robin brings inherent HA to the equation simply by the fact that it enforces the containers running in the Robin platform to always be up and running. So in the case of a single instance Oracle database should the container fail for whatever reason, you know, Robin automatically ensures that that container will be restarted somewhere else in the cluster. And through its Appleware storage layer, right, is further able to guarantee that through its persistent storage mechanisms, you know, it's going to be able to bring Oracle back up successfully somewhere else in that cluster. And then finally the ability to ease that process for making that step into the cloud, for migrating an application from on-prem into the cloud, running hybrid cloud, running multi-cloud, et cetera. We help to make that simpler as well. Okay, so let's take a look at one of the first key value propositions here around, you know, being able to empower users with their own self-service provisioning capability. So when you pull up Robin, basically Robin presents a marketplace-like feel, sort of this app store-like interface, if you will, through the console whereby any user, you know, any consumer of any one of these technologies can very easily simply click on that application. And then upon doing that, they're presented with the provisioning workflow. And this is a consistent workflow regardless of whether it's Oracle of Oracle Single Instance, RAC, or any other application. This, in the center here of the screen, is what that workflow begins to look like where you're given the opportunity to give the application a name. You know, it might be like my Oracle database, for example. You choose a network settings. You've got some various other settings here around storage, the compute, the memory sizing, and this just happens to be a RAC database. And so you're able to specify the number of RAC nodes in the cluster. But these are, you know, these are just a few simple inputs, most if not all of which are actually defaulted according to a YAML file that's part of what we call a bundle. So behind each one of these applications, Oracle, Elk, Hortonworks, whatever, there's what we call a bundle. And that bundle is comprised of a manifest file. It's the YAML file that is used to render this dialogue in the center of the screen. It defaults pretty much all of these values. But through the workflow provisioning process, you can easily come in here and tweak some of these values, change the sizing, change the number of compute cores, memory, et cetera, whatever. And then specify anything else that might be particularly relevant to this application. So in this case, it's RAC. And actually as you'll see here coming up in the demo, you have provision for specifying both the public and the private IP address, the scan, some of the things that are unique to this particular application. But the point is that there's a consistent process by which any of these application stacks can be, the provisioning for these can be rendered to the end consumer of that technology to very easily just pick the app, perhaps make a few tweaks to some of these inputs and then simply click provision application. And upon doing so, then Robin automatically provisions all the storage necessary. In this case, if it's RAC, it's using ASM for example, and under ASM as most, if not all of you are aware, there's raw storage needed. Robin handles raw storage just as well as it handles cooked file system type storage. It does all of this. And so it provisions all the storage volumes according to the inputs on that screen. And then also according to these inputs, it provisions the number of containers needed. Obviously there's going to be one container for each of the RAC nodes. And each of those containers is going to be allocated the certain amount of compute and memory capacity as defined here as well. And so that's it. And from a RAC perspective, for example, everything is done for you. The entire installation from the ground up, everything that which otherwise would have required coordination with storage admins to present raw storage to the nodes that you're going to be using to form that cluster under the RAC installation. The networking configuration of the public and the private interfaces on all the nodes. All that has to be coordinated with those CIS admins. And then just from a pure Oracle installation perspective, you're installing the grid infrastructure and ASM, and then you're installing the Oracle binaries and RAC and creation of the database. There's lots of steps in there. All of that is being compressed and abstracted into just literally this screen here. And again upon clicking provision app, then you literally in minutes have an entire standalone fresh new Oracle installation running in this case a RAC database. So let me just jump over here and show y'all what that looks like. So here I'm going to log in as Robin to the Robin console. And upon doing so I'm brought to the dashboard here, but what we're going to do is we're going to jump straight over to our application bundle screen. This will be consistent with what you just saw on that slide here, but in this case we just have a couple of bundles added to this particular cluster. And if I click on that application, that RAC app, so to speak, then here's that dialogue that's rendered from the manifest file. And so I give my app a name and I've got my different IP pools that have been created here. I've got one you can disregard the default, that's actually a Calico network pool, but I have both a public and an IP, I'm sorry a private IP pools created here. And then I go in and I just decide I want a two node RAC database and I can take the defaults here. For storage, defaults in this particular bundle happen to be set to solid state flash drives. In this particular cluster I did not have enough flash available, so I'm going to just switch these over to spinning disks, but I can keep the sizes there. And then I've got some additional parameters here. This is where I would specify the private interconnect and actually I had forgotten to specify the scan. So I've got some additional resources here, obviously specific to RAC. So I specify the single client access name and then I come down in here and I've got some other environment variables. So the bundle, this bundling concept is an open concept. You can create your own bundles. We have reference bundles that are provided with the product but through the bundle and through the manifest you're able to pass in parameters. Again, they can be defaulted or changed. And then another really key thing about Robin is the ability to control the placement of the resources out on the physical cluster. And I had to change this here because I only have a two node physical cluster for Robin for this demo. And I had a rule set in place there that would not allow me to put more than one RAC instance on the same physical node. And I need to be able to disable that because in a later demo I'm going to scale out. So it would have failed had I had a rule in place that would prevent me from doing that. But that's another really interesting capability with Robin is because of all the IP that's been invested in the built-in storage stack and the fact that the storage is app aware, we can do some very creative things around placement rules, whether it be data locality, isolation constraints or what have you. This is really important. So then I have my RAC database is created now. I have a two node RAC database. And I can see the two containers that represent each of those RAC nodes. And I can see some of the information, the IP addressing for those, the public and the private, the actual host name that was given, the physical Robin host on which each is running. And we make it very easy to jump down into the container by simply clicking on either one of those containers and clicking on the console. And so now I'm brought actually inside the container. I'll just log in as Oracle and I'll set my environment. And I just want to show you all real quickly that we do in fact have a RAC database up and running now. So I set the environment and then for those of you that are familiar with RAC, I'm just going to use SRV CTL here to do a status on the database. The database was named Robin. That was just something that was passed in from the bundle. Again, that could have been changed at the time we deployed. So you can see here we've got our two RAC instances, Robin 1 and Robin 2 each running on the two container nodes, the virtual nodes that we provisioned as part of the Oracle provisioning process in this case. And I can just go ahead and connect to SQL Plus and do something similar by querying VDollarView to again show that we have a RAC database up here that's basically a fully functional RAC database. So we've got two instances that are both active on that shared database and I can just exit out of this. And then basically that's it. Provisioning an Oracle RAC database was literally as simple as what you just saw there. So moving on then, let's look at refreshing. So Robin again is unique in its ability to provide through its Appleware storage, it uniquely provides for snapshotting and thin cloning of the entire stack. So if you look at traditional approaches to doing database refreshes with Oracle, typically you're looking at one of two options. Of course there's a number of utilities that are available for doing cloning. RMAN duplicate might be one approach for creating a clone of a database. You might be doing export import, data pump, what have you. Those would be two fundamentally different approaches and where you probably need to make a decision based on any kind of implications there may be for the application for doing one over the other. A lot of folks typically will do for that very reason because it's less invasive to the application or there's less implication with respect to the application will opt for doing a full database copy. Well the problem with that is sprawl. So typically what folks will do is to offload the stress on that production database, they'll first create a copy, they'll create a gold copy so to speak and then from that gold copy they'll start to create dev test type clones of that environment. Well for every time you do this of course you're essentially replicating the entire database and more specifically you're consuming that much additional space and storage real estate very costly, very expensive. You can't always count on these organizations to tear down their environments when they're finished and so before you know it it gets out of control. But what if you could do the same thing, you could effect the same exact cloning process but without that storage penalty. So that's where Robin comes into play. So with Robin what you would first do is you create a snapshot and Robin does redirect on write as far as its approach to doing snapshots and so what you're doing here is you're snapping the entire stack, you're snapping all the volumes that are associated with your database all your different data volumes but you're also snapping the root disk and you're snapping your Oracle home thereby capturing the installation, the Oracle binaries. But on top of that we're capturing in that snapshot, we're capturing all the QoS settings we're capturing all the settings for compute and memory. We're capturing every characteristic of that database because that can evolve over time. There's a lot of self-service available here in all those regards and being able to make changes in all those regards and so we're capturing all that as part of that snapshot and then subsequently thin cloning off of that snapshot. So these thin clones can be shared with other organizations for whatever reason but the point here is that upon doing so you're consuming a fraction of the space and a fraction of that storage out there. You've got minimal impact from doing the snapshot itself based on the redirect on right approach versus copy on right for example but you're also minimizing the amount of space consumed as a function of creating all these copies. So you can create numerous copies here with minimal storage utilization. So let me jump over again and show you an example of that. Again I'm using Rack here and not all of you may be Rack users. The main reason I'm using Rack as an example here is because it does tend to be harder to crack when doing any of this whether it's initial provisioning or things like what we're continuing to do now here with snapping and cloning. But as you can see here taking a snapshot of this entire two node Rack database happened in a matter of seconds. And from that snapshot I can use that as sort of a way to augment my backup strategy. So over time I might be able to roll back to that consistent point in time and again rolling back not just the data but rolling back the configuration. If I added a node to that Rack database and I need to roll back I'd be rolling back to the original incarnation of that the way it was initially provisioned rolling back from a three node to a two node Rack database. So we're rolling everything back. So here when I create the clone from that snapshot I'm going through a similar process as I would when initially provisioning the new database. I can either keep all these things because they're essentially with the exception of the networking because we need different IP addresses. It's capturing what it knows to already be in place because I'm basing this clone on that snapshot. So the placement rules all that kind of stuff is essentially going to default to what's sitting in the snapshot. But I have the latitude to be able to change these if I want. So creating the thin clone from the snapshot is also a very efficient process. Really it's just a matter of minutes. And then now I effectively have an entirely new standalone two node Rack database in this case that was based on the snapshot from my original two node Rack database. And it was all done quickly and conceivably by any end user. So I've got the Rack database here and you can see in a way as I look at all my Oracle applications it appears it's just another app just like the original one from which it was created. So that was cloning. So let's look at consolidation. So again as we look to try to really maximize infrastructure utilization we look to try to consolidate as densely as possible. And again when we do that we run into typically run into challenges with the noisy neighbor effects of multiple disparate workloads running in the same pooled collection of resources whether it be compute or storage. And so what Robin provides first of all is a pretty rich multi-tenant type framework including a rich RBAC layer, role-based access control layer. So first off there's the ability to carve up the cluster potentially into multiple isolated resource pools. So you can therefore deploy application components into certain resource pools guaranteeing that these workloads are isolated from other workloads in the cluster. So you have that technique if you will as a means for being able to provide a sort of degree of workload management. And then anytime you've got the ability to support many users across multiple groups of users multi-tenants in other words you need the ability through some sort of role-based access control mechanism to be able to set limits on these users' ability to provision memory, to provision CPU so that no one user can gobble up all those resources. So you can set limits and quotas across tenets for specific users within tenets and to give them appropriate access accordingly. So in addition to that, another technique again and a lot of this stems from Robin's unique storage proposition here with its Appleware storage, Robin actually tags all IOs with metadata that identifies the application initiating the IO all the way down to the specific storage volume to which that IO is traveling. So I've never actually tried to see this slide on WebEx as it's been presented to me so I don't know how well you guys can see this but the idea here is to try to illustrate that even for a specific storage volume, even for the same storage volume, two applications which might be sharing that storage volume can be governed or throttled in terms of their IO consumption down to that storage volume. So you can set IOPS rules for example to kind of govern how much storage any particular application on a per volume basis can actually consume IOPS. So this is in addition to being able to control CPU allocation, memory allocation and be able to be able to change that flexibly dynamically over time this is the rest of that quality of service story that Robin brings to the table is through its storage layer, Appleware storage layer, they're being able to provide very granular control over the way in which the physical resources in the cluster might be consumable across all the different applications as they're deployed across these virtual containers throughout the cluster. So scaling, so let's look at how easily we can scale up first of all so any application that you pull up in Robin or that's actually been deployed in Robin, you can easily pull that application up if you find that that application seems to be CPU bound for example at some point in time then you can very easily go out and allocate additional compute for the container that supports that particular application component or in the case of a single instance Oracle deployment of course it's just going to be for all of Oracle basically in that case but my point there being that for a composite application in which the bundle itself is actually comprised of multiple elements of the stack you can on a per component basis tweak the compute and or memory for that particular component or role in other words. So scaling up is really just simply a matter of using these slider bars and adding compute adding memory. The GPU scale here is typically reserved for those folks that are doing analytics big data type activity so there's GPU support for that. But it's as easy as that right so it's not about having to make a decision up front as to picking a small, medium, large or extra large shape if you will in this kind of otherwise private cloud environment. You just provision it according to whatever you think you might want but over time at any point in time you can very easily and granularly slide up and down, scale up and down the amount of compute and memory for that. So scaling out is the same thing and again this is an Oracle presentation so we're using RAC as an example but there are many other examples of composite applications, cluster distributed type applications where scaling out makes equal sense but scaling out is very similarly done to scaling up. So we just go and pull the application up, we say that we want to scale that out and in this case we just say that we want to add, we use the slider bar to scale out RAC by 1, 2, 3 or 4 additional nodes and then just simply click scale out and then Robin takes care of all the automation, all the plumbing behind the scenes in accordance with adding those additional instances first of all the containers but then standing up the instances and all the subsequent Oracle specific stuff, creating additional threads of redo and all the related storage provisioning and so forth Robin automates every bit of that and it does it really just a matter of minutes. Sorry about that. So let me jump over and show you what that looks like. I realize we're coming up on time for Q&A. I'll try to hopefully get through this. So we had our 2-0 RAC database and a classic example of wanting to add another node, obviously if you're CPU bound you want to add a node, that would be one use case for wanting to scale out but you might also want to test scalability of the application itself. You might want to say, okay this thing is scaling pretty well from 1 to 2 nodes but as I add a third node how linearly is that going to scale? If you've got any experience with RAC you're probably aware of the fact that that's the biggest hit that you take in scalability on RAC is going from 2 to 3 nodes and so it would be a classic sort of use case or test case to add a third node to determine the linearity with which the app itself is able to scale on that cluster database. So we just simply say that we want to scale out by one additional node. There was some provision in there to kind of tweak some of the variables but we don't need to do that. We simply say scale out and then behind the scenes Robin is going to provision a new container and then once that container is provisioned it's going to activate the various hook scripts that are also part of that bundle or doing all the Oracle specific activity associated with creating a new instance starting that instance mounting the database and all the various things associated with that. So just a matter of minutes we were able to add that third node. So when we close that screen and this screen here refreshes we can see our third node and we now have a three node RAC database in order to demonstrate that or to prove that. Again we can very easily jump down into the container itself. This would be again just like jumping onto the SSHing onto the actual RAC node itself. Just set our environment and again I'll just use SRBCTL to do a status on the database so we'll query the clusterware to see that yep we have now three instances running. You can see the newly provisioned V node. We can query some of the other node apps. You can see the additional resources, cluster managed resources that were created. Go into sql plus again and just query the V$ instance or in this case the GV$ instance view. So we've got our third instance and we've got our database that's fully active across now three nodes in the Oracle database cluster. So it's as simple as that. Now I believe in this demo I actually went and conversely showed how you can scale back in. We can take any one of these nodes in the cluster and we can remove it. So we don't have to deprovision the last one that we added. We can go in and remove the first or the second one as well. So all we have to do there is simply delete the container and then behind the scenes Robin is going to take care of all the necessary basically coordinating that with Oracle, with the grid infrastructure to deprovision that node, to deprovision the instance from the cluster registry so that we now have a cleanly pruned cluster from three back down to two nodes. So this is important. It's important to be able to be elastic as you're trying to make the best use of the physical cluster resources. You need to be able to expand and contract both vertically as well as horizontally. And so that's why I think it's important to be able to scale back in a rack database as easily as it is to scale it out. We're just requeering the grid infrastructure again just to test and make sure that we have successfully removed that instance. I think in the interest of time, why don't I just I'm just going to go ahead and flip back over to the presentation here where that's going. So failover. So finally being able to provide business continuity for the Oracle database without necessarily having to make the additional investment in a cluster manager, some sort of clusterware product some sort of storage vendors product or real application clusters itself. I mean arguably rack is going to be the superior approach to providing Oracle database HA but not everybody wants to make that investment. Not everybody has that sort of SLA in place to justify that investment but still has some sort of need for continuity. So it's important to note that with Robin, Robin is automatically going to maintain the state of all the containers. If the state of that container is such that the expectation is that that container always be up and running, then Robin is going to do everything it can to enforce that. So in the event of a node failing, Robin is going to detect that the container has failed. Or if a container has failed on an otherwise healthy node, Robin is going to detect that and Robin is going to restart that container automatically somewhere. And then all of the associated storage, you know, migration if you will is also taking care of automatically. Again, Robin is fully aware of all the mappings from that particular application and its container at that point in time with all the various storage volumes that had been provisioned to it and mapped to it. So it maintains that mapping and therefore is able to automatically remount that storage accordingly in the event that that has to be started back up again. So I actually do have a quick demo for that just to show you that come back up. I know we're running up on the edge of time here but if you all bear with me. This is actually a different environment here. This is actually a three node Robin environment. That's a different non sort of rack enabled environment if you will. So I have a single instance Oracle database running here. And what I want to do here is to show you a case where, you know, in this case we can see that the instance is currently running where this container is currently running on that EQX01 back in 10 system. That's actually the physical Robin host in the cluster. And so what I'm going to do is I can show first of all in a planned fashion how we can gracefully migrate that container over to another node in the system. So we might want to perform some sort of maintenance on EQX01 back in 10. So we might want to gracefully migrate or kind of live migrate if you will. Everything that's running on that physical host somewhere else in the cluster. And so this is what we've done here. We've just simply moved that all the app or in this case the Oracle application that was on that box. We moved it over to EQX04. So we can see there it's now running on that physical host in the cluster. But now let's show like an unplanned downtime event. So here we know that it's now running on EQX04 back into 5. And now what I'll do is I'll SSH into that box itself and I'll reboot the box. So let's just simulate a failure of that host. So we had our Oracle instance that was running on that. And you can see here that Robin has detected the failure and so Robin is going to automatically migrate that back over to one of the other healthy hosts in the Robin cluster. So as you can see here it was in fact moved back over to EQX01 back in 10. And all of that was done automatically. Alright so finally migration to the cloud. So basically this is important to a lot of folks. Looking to try to embrace the cloud whether it be for some if not all of their Oracle deployment. So there's a lot of ways to move an Oracle database or an entire Oracle stack into the cloud. Robin makes it about as easy as anybody can. And it can be done in a number of different ways. We talked about cloning earlier in the presentation with the related demo and that's actually one of the techniques we can use. We can also do backups to S3 storage and then use those backups to instantiate the application in the cloud. But this will start out very similarly to the way you might do any sort of clone for your first snapshot. So you've got a number of snapshots from which you might determine to be the best candidate or basis for that clone. You create the clone and then you're essentially going to... You've got your Robin cluster running in the cloud, in whichever cloud it may be. And then you move that clone into the cloud and spin that up in the cloud accordingly. So it's just about as simple as that to actually leverage that to be able to make that migration. So I realize we only got about 10 minutes left for Q&A. Just a quick wrap up here. The value proposition of Robin is I think it's largely twofold. From an ops perspective, it's about simplification. It's about making better use of the resources, the physical resources in the data center by maximizing utilization, a lot less idle infrastructure out there. Fewer islands, if you will. Better consolidation and maximization of that investment. Providing various organizations, dev tests, dev ops with that self-service type capability and being able to keep folks isolated through a pretty good multi-tenant foundation built into the platform itself is key. And then finally from an agility perspective, containers bring a great amount of agility. But when you start to bring in the notion of having to stand up applications on containers that agility tends to be compromised without some framework in place to be able to provide the automation needed to orchestrate the deployment of those containers. And particularly for more complex applications, all the plumbing and the stitching needed among those different containers to make sure that all the pieces talk to each other, that they're accessible from outside of the container platform in other words for the application connectivity into the database. From a Kubernetes perspective, there's a great deal of complexity with understanding all the different Kubernetes resources that are in play to stand up any given application to ensure that all those pieces are talking to one another to ensure that they're exposed to the outside world and such. And so Robin abstracts all that complexity and fills the gaps from a technical perspective and through its storage and through the built-in storage and the networking and the compute to be able to really bring that to bear, really make that viable for all applications. So that's pretty much all I had. I guess at this point we can open up to questions. For more information basically I would encourage y'all to contact us certainly. Tim Lawler would be your contact for getting you routed to the right folks whether it be me or anyone else. We're happy to come out. We're happy to do whatever makes sense for y'all as far as any kind of follow-up, deeper dive type discussions around the technology and maybe identify some use cases that y'all may have and once again I appreciate everybody's time. So with that Shannon I guess we can open up to questions. Rob, thank you so much for this presentation and if you have questions feel free to submit them in the bottom right hand corner of your screen in the Q&A section and just to answer the most commonly asked questions just a reminder I will be sending a follow-up email to all registrants within two business days containing links to the slides and to the recording of this session for everyone. And Rob early on there was a question that came in asking what is CPU cores? What are CPU cores? Correct. So in the, well in this context you can think of a core as essentially being like a virtual CPU. Specifically when we talk about allocating CPU cores to an application or on behalf of an application we're essentially taking what is otherwise physical CPU capacity on that particular node where that container is running and we're practically reserving time on that CPU on that socket basically from any one of those cores the presumption here is that it's a multi-core CPU and we're essentially reserving time on behalf of that particular container because again we're virtualizing the compute, we're virtualizing that physical CPU and basically just assigning a portion of that CPU or CPU core to the application that's running on the container. Does that, I hope that answers the question. I believe so and again if you have questions feel free to spend on the bottom right hand corner everyone's being very quiet right now. A lot of information you've given them Rob what's the most commonly asked question that you get from your customers? You know we do despite having mentioned it earlier in the presentation we do often get asked is there any kind of because the whole notion of hyperconverge always throws people and they ask is there any kind of hardware as part of the Robin solution and so again no there's not it's a pure software only product, software defined. Everything is software defined including the storage and there's no dependency on any sort of cloud service any sort of storage vendor. This is actually something that you'll find if you're looking out there at some of the other orchestration vendors and I won't name any names but they will quite typically look to either another storage vendor or another storage, a particular storage product line within their own offering within the company because they don't, the orchestration framework itself does not it's not delivered with its own built in storage stack and so that again is something that really is unique to Robin in its ability to do a lot of the things that we talk about around application awareness you know specifically the quality of service being able to get more granular and more intelligent with respect to placement constraints. Being able to you know to do a lot of that stuff that is really dependent on app awareness in the storage you know to be able to do a lot of those things, the snapping and the cloning again you know another example. So and there's a question here Robin just a licensing question Mark. So how do you handle that? So that is another well I'm going to kind of take liberty with that one because it is that's another common question is the implication like the Oracle licensing implication for bringing an Oracle database into this cluster you know a Robin cluster I'm assuming that that's kind of where that question stems if not I can maybe address the other side of that from a pure Robin perspective but you know Robin itself does not introduce any additional licensing implications. The implications are really the same you know from an Oracle perspective the same as you are going to encounter with any other virtualization platform. So if you've ever successfully and I challenge anyone to say that they have successfully managed to grasp the licensing rules so to speak as they relate to VMware as an example. Licensing the database for example in VMware I could spend an hour talking about that I dealt with that for years and with all the Oracle VMware customers nothing changes in short nothing changes right so the economy with regard to bringing Oracle into this kind of a platform right it's certainly going to be a function of how much Oracle you're retiring out on otherwise bare metal or perhaps even VMs and bringing into the Robin cluster because it's quite conceivable that there could be huge savings. I mean we have a large Oracle customer right now for example running several hundred rack databases on Robin for them it was about it was about license management as much as it was self-service provisioning and all the good functional technical stuff that I talked about here but they were able to significantly reduce their license spend or more specifically support spend by ultimately reducing the number of licenses required you know from their current state into their you know or I should say now their current state into their now current state on Robin because the net difference was far fewer cores and of course they were processor based in their licensing agreement and so but you could just as easily run into a situation where it might cost more if you're just running one Oracle database today on four cores you know you've got two processor licenses if it's on intel you pull that into a Robin cluster you're more than likely going to have more cores in your Robin cluster and that might you know result in a net increase in Oracle licensing but more often than not it's going to be a savings you know again predicated on moving a lot of Oracle into Robin because you are going to be able to do as much as you're doing today with less hardware less compute essentially and you're going to be able to more successfully have all those different workloads you know co located in the same grid so to speak you know more successfully by way of some of the QoS capabilities and you know the resource management that we have which simply is not available unless you're unless you're running in exadata or you're running on you know pillar storage or some specific storage subsystem which Oracle where Oracle does have IO resource management you know that's few and far between that's what we're bringing to the table here well rather does bring us to the top of the hour there is a quick there's a couple extra questions here that I'll make sure and get to you and Tim for answers make sure we get those answers back to those attendees well thank you again for this presentation and thanks to our attendees for being so engaged and hanging out with us today thanks so much for everything and I really appreciate and hope you all have a great day Rob thank you so much and thanks for having yes thank you everybody