Oracle Open World 2017 Delphix and DBVisit

Editor's Notes

• #3: Need Mike’s intro slide…
• #4: 83% of development is currently performed in the cloud, so we can’t discuss development today without including the cloud. Delays are not an option- including those in hardware and IT allocation. This pushes a need for the cloud that previously we hadn’t experienced. The ability for developers to allocate an environment and start working within minutes is essential to agile
• #5: Of the 935 professionals surveyed, 35 percent say that they lack the experience or the expertise to confidently perform a system migration. No surprise then that a worrying 44 percent of businesses experienced a migration failure in 2015-2017 In addition, 57 percent of migrations required more resources to perform the migration.
• #6: I speak to many DBAs about DevOps as the third option for the future of their career. It’s not just about operations or development, but a hybrid of both and the power of automation. Our natural skill sets will benefit this. Now data is at the center of the hold on DBAs, but it can be mitigated and eliminated. Really? You’re all saying this, I know.
• #8: Data is center of this. I’m a DBA, I know this. Data sources are central to most development projects and as applications and code is migrated to the cloud, so must the data source. For a typical Fortune 1000 company, just a 10% increase in data accessibility will result in more than $65 million additional net income. Leveraging data coupld increase revenue by as much as 60%
• #9: Data Gravity has two definitions and both revolve around data sources. For the first, there are larger data sources every day. Databases are at the center of this friction and the natural life of a database is growth. By 2020, a third of all data will be on the cloud and 58% of data will be comprised in big data. In the last two years, we’ve created more data has been created in the past two years than in the entire previous history of the human race. Data isn’t going to slow down, either. By the year 2020, about 1.7 megabytes of new information will be created every second for every human being on the planet. By 2020, we’ll grow from today’s 4.4 zettabyets to an approximate, but staggering 44 zettabytes, or 44 trillion gigabytes. And by 2020, a third of that data will pass through the cloud.
• #10: For the second, Data gravity is the ability of bodies of data to attract applications, services and other data. ... IT expert Dave McRory coined the term data gravity as an analogy to the way that, in accordance with the physical laws of gravity, objects with more mass attract those with less.
• #11: And yet we state that we won’t need DBAs? That data isn’t the center of challenge?
• #12: Per Forbes, by the year 2020, about 1.7 megabytes of new information will be created every second for every human being on the planet. more data has been created in the past two years than in the entire previous history of the human race. That data has to be stored somewhere and there’s a large chance it’s going to be in a relational data store.
• #13: Everything on prem needs to move to the cloud. There’s commonly one over all project with three sub projects that will accomplish all of this. DBAs will be working to move the database and all the data. Application and development will work to migrate the application and support files Administrators will work to prepare the cloud environments if it’s IaaS.
• #14: Data gravity suffers from the Von Newmann Bottleneck. It’s a basic limitation on how fast computers can be. Pretty simple, but states that the speed of where data resides and where it’s worked with, (i.e. processed) is the limiting factor in computing speed. This is why we have numerous local cache to address memory issues while processing data. Microsoft researcher Jim Gray has spend most of his career looking at the economics of data, which I think is pretty cool! This is why DBAs spend so much time on the cost based optimizer, as moving or getting data has cost. After all is said and done, this is the fundamental principle of data gravity and why DBAs get the big bucks.
• #15: We’ll start with three areas that solve the problem of data gravity and data friction in agile development, We Virtualize.
• #17: RMAN duplicates, cold backup to restores, datapump and other archaic data transfer processes are time consuming.
• #19: By virtualizing, we remove the “weight” of the data. We know that 80% of the data won’t change between copies, so why do we need individual copies of it. Our source is then deduped and compressed to conserve more space.
• #21: Each Virtual Database, (VDB) will no longer require space, (only background and foreground memory for SGA/PGA, etc.) and local redo logs. This is a considerable savings, but… If we take this a step further by embracing write changes only on blocks changed from the source, then we’ll experience 10-20 copies of a database in about the same space that one database requires.
• #22: The business is able to provision new environments or refresh existing ones in a matter of minutes. Developers and testers who’ve worked with bookmarks and branching of their code changes can now do the same with database changes, rewinding and refreshing as they need without impacting the DBAs day. This allows the DBA to do more with their time. Having tools that includes the database in the Agile development cycle makes a pivotal change in how the DBA is capable of being part of DevOps.
• #24: ** Please replace DBVisit logo with a better graphic to describe the replication engine! Feel free to add more slides to go into full detail of what it does, etc. The goal is to say that we’ll add this replication to both the Dsource, (golden copy) and the target or virtual images/data pods.
• #27: The next step is moving to data pods. Containers are a buzz area of technology right now. If we’re talking Docker or Kubernetes, we know this is the way of the future. Instead of having locked, unique environments, the ability to package them as one, in a lighter and more flexible unit makes incredible sense. As a DBA, I rarely, if ever, just released code to the database. It was commonly to the database, the application and linked products. The ability to package and manage as a Data Pod is an impressive enhancement to the Developer, tester and DBA.
• #28: The next step is the ability to migrate to the cloud or from one cloud to another. Right now, 60% of customers are using 2-5 clouds on average. The ability to move a Data Pod from one cloud to another is incredibly powerful. Companies are spending increased time now just migrating to the cloud, but to other clouds and if it would be as simple as migrating a Data pod with a few changes to the new storage location, (i.e. cloud) that could save companies millions of dollars.
• #29: With virtualization, we virtualize it all- the database, data sources, application and flat files. We containerize it into a Data Pod
• #30: With virtualization, we virtualize it all- the database, data sources, application and flat files. We containerize it into a Data Pod
• #31: By doing so, it’s easier to life and shift to the cloud. It’s lighter and we can move 20 + environments in the same space as one.
• #33: Full refreshes are excellent, but for progressive deployments and releases, replication can offer an added layer to cloud migrations.
• #35: Need to fill this out with DBVisit diagrams and solutions into the dynamic data platform slides I’ve built…
• #42: So we evolve from being a DBA to embracing more DevOps skills, including more scripting, scheduling and automation, then include DataOps to create a flexible, agile solution. There are two areas that the DBA can build out on their path to DevOps that are database centric and crucial to the solution- Virtualize Data pods to package environments. By doing all these things, impressive changes can be made by the DBA to any team and they can become valued as a key member of the agile development cycle.