SlideShare verwendet Cookies, um die Funktionalität und Leistungsfähigkeit der Webseite zu verbessern und Ihnen relevante Werbung bereitzustellen. Wenn Sie diese Webseite weiter besuchen, erklären Sie sich mit der Verwendung von Cookies auf dieser Seite einverstanden. Lesen Sie bitte unsere Nutzervereinbarung und die Datenschutzrichtlinie.
SlideShare verwendet Cookies, um die Funktionalität und Leistungsfähigkeit der Webseite zu verbessern und Ihnen relevante Werbung bereitzustellen. Wenn Sie diese Webseite weiter besuchen, erklären Sie sich mit der Verwendung von Cookies auf dieser Seite einverstanden. Lesen Sie bitte unsere unsere Datenschutzrichtlinie und die Nutzervereinbarung.
But we’re only discussing part of the solution- it’s often geared towards apps, but applications are often extremely light and easy to move. What about when data is involved? Containers help, but are they the answer? Are traditional containers the answer? This session is going to go into a distinct solution around that discussion.
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
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.
Migrating what results from that development process from dev, to test, to production is another story.
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%
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.
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.
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.
And yet we state that we won’t need DBAs? That data isn’t the center of challenge?
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.
So after all that, you may still ask, why is all this data talk still important to a discussion on Agile and containers? Currently we perform 40,000 search queries every second (on Google alone), which makes it 3.5 searches per day and 1.2 trillion searches per year. If we start to multiply this by all the web searches, business searches, applications, etc. You realize how important data is to the solution to moving faster with a lighter, more packaged solution.
This has become an oxy-moron. It becomes a cog in the wheel of development and we aren’t able to contain something that’s become to large to contain.
We can’t eliminate the majority of data We can optimize the code and the applications, but data is still data- i.e. large. It will continue to grow This solution I’m about to show you has many uses, but the although you’ll see huge benefits, my demo will show you the added benefit when things DON’T go as planned.
We’ll start with three areas that solve the problem of data gravity and data friction in agile development, We Virtualize.
RMAN duplicates, cold backup to restores, datapump and other archaic data transfer processes are time consuming.
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.
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.
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.
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.
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.
Once final tests are done- you are testing. Perform final migration, final sync to prod and downtime to switch from on-prem to cloud.
With virtualization, we virtualize it all- the database, data sources, application and flat files. We containerize it into a Data Pod
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.
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.