(upbeat music) >> Reporter: From around the globe, it's The Cube with digital coverage of enterprise data automation and event series brought to you by Io-Tahoe. >> Okay, we're back. Focusing on enterprise data automation, we're going to talk about the journey to the cloud. Remember, the hashtag is data automated. We're here with Lester Waters who's the CTO of Io-Tahoe, Lester, good to see you from across the pond on video, wish we were face to face, but it's great to have you on The Cube. >> Also I do, thank you for having me. >> Oh, you're very welcome. Hey, give us a little background on CTO, you got a deep expertise in a lot of different areas, but what do we need to know? >> Well, David, I started my career basically at Microsoft, where I started the Information Security Cryptography Group. They're the very first one that the company had and that led to a career in information security and of course, as you go along with the information security, data is the key element to be protected. So I always had my hands in data and that naturally progressed into a role with Io-Tahoe as their CTO. >> Guys, I have to invite you back, we'll talk crypto all day we'd love to do that but we're here talking about yeah, awesome, right? But we're here talking about the cloud and here we'll talk about the journey to the cloud and accelerate. Everybody's really interested obviously in cloud, even more interested now with the pandemic, but what's that all about? >> Well, moving to the cloud is quite an undertaking for most organizations. First of all, we've got as probably if you're a large enterprise, you probably have thousands of applications, you have hundreds and hundreds of database instances, and trying to shed some light on that, just to plan your move to the cloud is a real challenge. And some organizations try to tackle that manually. Really what Io-Tahoe is bringing is trying to tackle that in an automated version to help you with your journey to the cloud. >> Well, look at migrations are sometimes just an evil word to a lot of organizations, but at the same time, building up technical debt veneer after veneer and year, and year, and year is something that many companies are saying, "Okay, it's got to stop." So what's the prescription for that automation journey and simplifying that migration to the cloud? >> Well, I think the very first thing that's all about is data hygiene. You don't want to pick up your bad habits and take them to the cloud. You've got an opportunity here, so I see the journey to the cloud is an opportunity to really clean house, reorganize things, like moving out. You might move all your boxes, but you're kind of probably cherry pick what you're going to take with you and then you're going to organize it as you end up at your new destination. So from that, I get there's seven key principles that I like to operate by when I advise on the cloud migration. >> Okay. So, where do you start? >> Well, I think the first thing is understanding what you got, so discover and cataloging your data and your applications. If I don't know what I have, I can't move it, I can't improve it, I can't build up on it. And I have to understand there is dependency, so building that data catalog is the very first step. What do I got? >> Now, is that a metadata exercise? Sometimes there's more metadata than there is data. Is metadata part of that first step or? >> In deed, metadata is the first step so the metadata really describes the data you have. So, the metadata is going to tell me I have 2000 tables and maybe of those tables, there's an average of 25 columns each, and so that gives me a sketch if you will, of what I need to move. How big are the boxes I need to pack for my move to the cloud? >> Okay, and you're saying you can automate that data classification, categorization, discovery, correct using math machine intelligence, is that correct? >> Yeah, that's correct. So basically we go, and we will discover all of the schema, if you will, that's the metadata description of your tables and columns in your database in the data types. So we take, we will ingest that in, and we will build some insights around that. And we do that across a variety of platforms because everybody's organization has you've got a one yeah, an Oracle Database here, and you've got a Microsoft SQL Database here, you might have something else there that you need to bring site onto. And part of this journey is going to be about breaking down your data silos and understanding what you've got. >> Okay. So, we've done the audit, we know what we've got, what's next? Where do we go next? >> So the next thing is remediating that data. Where do I have duplicate data? Often times in an organization, data will get duplicated. So, somebody will take a snapshot of a data, and then ended up building a new application, which suddenly becomes dependent on that data. So it's not uncommon for an organization of 20 master instances of a customer. And you can see where that will go when trying to keep all that stuff in sync becomes a nightmare all by itself. So you want to understand where all your redundant data is. So when you go to the cloud, maybe you have an opportunity here to consolidate that data. >> Yeah, because you like to borrow in an Einstein or apply an Einstein Bromide right. Keep as much data as you can, but no more. >> Correct. >> Okay. So you get to the point to the second step you're kind of a one to reduce costs, then what? You figure out what to get rid of, or actually get rid of it, what's next? >> Yes, that would be the next step. So figuring out what you need and what you don't need often times I've found that there's obsolete columns of data in your databases that you just don't need, or maybe it's been superseded by another, you've got tables that have been superseded by other tables in your database. So you got to understand what's being used and what's not and then from that, you can decide, "I'm going to leave this stuff behind, "or I'm going to archive this stuff "cause I might need it for data retention "or I'm just going to delete it, "I don't need it at all." >> Well, Lester, most organizations, if they've been around a while, and the so-called incumbents, they've got data all over the place, their data marts, data warehouses, there are all kinds of different systems and the data lives in silos. So, how do you kind of deal with that problem? Is that part of the journey? >> That's a great point Dave, because you're right that the data silos happen because this business unit is chartered with this task another business unit has this task and that's how you get those instantiations of the same data occurring in multiple places. So as part of your cloud migration journey, you really want to plan where there's an opportunity to consolidate your data, because that means there'll be less to manage, there'll be less data to secure, and it'll have a smaller footprint, which means reduced costs. >> So, people always talk about a single version of the truth, data quality is a huge issue. I've talked to data practitioners and they've indicated that the quality metrics are in the single digits and they're trying to get to 90% plus, but maybe you could address data quality. Where does that fit in on the journey? >> That's, a very important point. First of all, you don't want to bring your legacy issues with you. As the point I made earlier, if you've got data quality issues, this is a good time to find those and identify and remediate them. But that can be a laborious task. We've had customers that have tried to do this by hand and it's very, very time consuming, cause you imagine if you've got 200 tables, 50,000 columns, imagine, the manual labor involved in doing that. And you could probably accomplish it, but it'll take a lot of work. So the opportunity to use tools here and automate that process is really will help you find those outliers there's that bad data and correct it before you move to the cloud. >> And you're just talking about that automation it's the same thing with data catalog and that one of the earlier steps. Organizations would do this manually or they try to do it manually and that's a lot of reason for the failure. They just, it's like cleaning out your data like you just don't want to do it (laughs). Okay, so then what's next? I think we're plowing through your steps here. What what's next on the journey? >> The next one is, in a nutshell, preserve your data format. Don't boil the ocean here to use a cliche. You want to do a certain degree of lift and shift because you've got application dependencies on that data and the data format, the tables on which they sit, the columns and the way they're named. So, some degree you are going to be doing a lift and shift, but it's an intelligent lift and shift using all the insights you've gathered by cataloging the data, looking for data quality issues, looking for duplicate columns, doing planning consolidation. You don't want to also rewrite your application. So, in that aspect, I think it's important to do a bit of lift and shift and preserve those data formats as they sit. >> Okay, so let me follow up on that. That sounds really important to me, because if you're doing a conversion and you're rewriting applications, that means that you're going to have to freeze the existing application, and then you going to be refueling the plane as you're in midair and a lot of times, especially with mission critical systems, you're never going to bring those together and that's a recipe for disaster, isn't it? >> Great analogy unless you're with the air force, you'll (mumbles) (laughs). Now, that's correct. It's you want to have bite-sized steps and that's why it's important to plan your journey, take these steps. You're using automation where you can to make that journey to the cloud much easier and more straightforward. >> All right, I like that. So we're taking a kind of a systems view and end to end view of the data pipeline, if you will. What's next? I think we're through. I think I've counted six. What's the lucky seven? >> Lucky seven, involve your business users. Really, when you think about it, your data is in silos. Part of this migration to the cloud is an opportunity to break down these silos, these silos that naturally occur as part of the business unit. You've got to break these cultural barriers that sometimes exist between business and say, so for example, I always advise, there's an opportunity here to consolidate your sensitive data, your PII, your personally identifiable information, and if three different business units have the same source of truth for that, there's was an opportunity to consolidate that into one as you migrate. That might be a little bit of tweaking to some of the apps that you have that are dependent on it, but in the long run, that's what you really want to do. You want to have a single source of truth, you want to ring fence that sensitive data, and you want all your business users talking together so that you're not reinventing the wheel. >> Well, the reason I think too that's so important is that you're now I would say you're creating a data driven culture. I know that's sort of a buzz word, but what it's true and what that means to me is that your users, your lines of business feel like they actually own the data rather than pointing fingers at the data group, the IT group, the data quality people, data engineers, saying, "Oh, I don't believe it." If the lines of business own the data, they're going to lean in, they're going to maybe bring their own data science resources to the table, and it's going to be a much more collaborative effort as opposed to a non-productive argument. >> Yeah. And that's where we want to get to. DataOps is key, and maybe that's a term that's still evolving. But really, you want the data to drive the business because that's where your insights are, that's where your value is. You want to break down the silos between not only the business units, as I mentioned, but also as you pointed out, the roles of the people that are working with it. A self service data culture is the right way to go with the right security controls, putting on my security hat of course in place so that if I'm a developer and I'm building a new application, I'd love to be able to go to the data catalog, "Oh, there's already a database that has the customer "what the customers have clicked on when shopping." I could use that. I don't have to rebuild that, I'll just use that as for my application. That's the kind of problems you want to be able to solve and that's where your cost reductions come in across the board. >> Yeah. I want to talk a little bit about the business context here. We always talk about data, it's the new source of competitive advantage, I think there's not a lot of debate about that, but it's hard. A lot of companies are struggling to get value out of their data because it's so difficult. All the things we've talked about, the silos, the data quality, et cetera. So, you mentioned the term data apps, data apps is all about streamlining, that data, pipelining, infusing automation and machine intelligence into that pipeline and then ultimately taking a systems view and compressing that time to insights so that you can drive monetization, whether it's cut costs, maybe it's new revenue, drive productivity, but it's that end to end cycle time reduction that successful practitioners talk about as having the biggest business impact. Are you seeing that? >> Absolutely, but it is a journey and it's a huge cultural change for some companies that are. I've worked in many companies that are ticket based IT-driven and just do even the marginalist of change or get insight, raise a ticket, wait a week and then out the other end will pop maybe a change that I needed and it'll take a while for us to get to a culture that truly has a self service data-driven nature where I'm the business owner, and I want to bring in a data scientist because we're losing. For example, a business might be losing to a competitor and they want to find what insights, why is the customer churn, for example, happening every Tuesday? What is it about Tuesday? This is where your data scientist comes in. The last thing you want is to raise a ticket, wait for the snapshot of the data, you want to enable that data scientist to come in, securely connect into the data, and do his analysis, and come back and give you those insights, which will give you that competitive advantage. >> Well, I love your point about churn, maybe it talks about the Andreessen quote that "Software's eating the world," and all companies are our software companies, and SaaS companies, and churn is the killer of SaaS companies. So very, very important point you're making. My last question for you before we summarize is the tech behind all of these. What makes Io-Tahoe unique in its ability to help automate that data pipeline? >> Well, we've done a lot of research, we have I think now maybe 11 pending patent applications, I think one has been approved to be issued (mumbles), but really, it's really about sitting down and doing the right kind of analysis and figuring out how we can optimize this journey. Some of these stuff isn't rocket science. You can read a schema and into an open source solution, but you can't necessarily find the hidden insights. So if I want to find my foreign key dependencies, which aren't always declared in the database, or I want to identify columns by their content, which because the columns might be labeled attribute one, attribute two, attribute three, or I want to find out how my data flows between the various tables in my database. That's the point at which you need to bring in automation, you need to bring in data science solutions, and there's even a degree of machine learning because for example, we might deduce that data is flowing from this table to this table and upon when you present that to the user with a 87% confidence, for example, and the user can go, or the administrator can go. Now, it really goes the other way, it was an invalid collusion and that's the machine learning cycle. So the next time we see that pattern again, in that environment we will be able to make a better recommendation because some things aren't black and white, they need that human intervention loop. >> All right, I just want to summarize with Lester Waters' playbook to moving to the cloud and I'll go through them. Hopefully, I took some notes, hopefully, I got them right. So step one, you want to do that data discovery audit, you want to be fact-based. Two is you want to remediate that data redundancy, and then three identify what you can get rid of. Oftentimes you don't get rid of stuff in IT, or maybe archive it to cheaper media. Four is consolidate those data silos, which is critical, breaking down those data barriers. And then, five is attack the quality issues before you do the migration. Six, which I thought was really intriguing was preserve that data format, you don't want to do the rewrite applications and do that conversion. It's okay to do a little bit of lifting and shifting >> This comes in after the task. >> Yeah, and then finally, and probably the most important is you got to have that relationship with the lines of business, your users, get them involved, begin that cultural shift. So I think great recipe Lester for safe cloud migration. I really appreciate your time. I'll give you the final word if you will bring us home. >> All right. Well, I think the journey to the cloud it's a tough one. You will save money, I have heard people say, you got to the cloud, it's too expensive, it's too this, too that, but really, there is an opportunity for savings. I'll tell you when I run data services as a PaaS service in the cloud, it's wonderful because I can scale up and scale down almost by virtually turning a knob. And so I'll have complete control and visibility of my costs. And so for me, that's very important. Io also, it gives me the opportunity to really ring fence my sensitive data, because let's face it, most organizations like being in a cheese grater when you talk about security, because there's so many ways in and out. So I find that by consolidating and bringing together the crown jewels, if you will. As a security practitioner, it's much more easy to control. But it's very important. You can't get there without some automation and automating this discovery and analysis process. >> Well, great advice. Lester, thanks so much. It's clear that the capex investments on data centers are generally not a good investment for most companies. Lester, really appreciate, Lester waters CTO of Io-Tahoe. Let's watch this short video and we'll come right back. You're watching The Cube, thank you. (upbeat music)

(upbeat music) >> Reporter: From around the globe, it's The Cube with digital coverage of enterprise data automation and event series brought to you by Io-Tahoe. >> Okay, we're back. Focusing on enterprise data automation, we're going to talk about the journey to the cloud. Remember, the hashtag is data automated. We're here with Lester Waters who's the CTO of Io-Tahoe, Lester, good to see you from across the pond on video, wish we were face to face, but it's great to have you on The Cube. >> Also I do, thank you for having me. >> Oh, you're very welcome. Hey, give us a little background on CTO, you got a deep expertise in a lot of different areas, but what do we need to know? >> Well, David, I started my career basically at Microsoft, where I started the Information Security Cryptography Group. They're the very first one that the company had and that led to a career in information security and of course, as you go along with the information security, data is the key element to be protected. So I always had my hands in data and that naturally progressed into a role with Io-Tahoe as their CTO. >> Guys, I have to invite you back, we'll talk crypto all day we'd love to do that but we're here talking about yeah, awesome, right? But we're here talking about the cloud and here we'll talk about the journey to the cloud and accelerate. Everybody's really interested obviously in cloud, even more interested now with the pandemic, but what's that all about? >> Well, moving to the cloud is quite an undertaking for most organizations. First of all, we've got as probably if you're a large enterprise, you probably have thousands of applications, you have hundreds and hundreds of database instances, and trying to shed some light on that, just to plan your move to the cloud is a real challenge. And some organizations try to tackle that manually. Really what Io-Tahoe is bringing is trying to tackle that in an automated version to help you with your journey to the cloud. >> Well, look at migrations are sometimes just an evil word to a lot of organizations, but at the same time, building up technical debt veneer after veneer and year, and year, and year is something that many companies are saying, "Okay, it's got to stop." So what's the prescription for that automation journey and simplifying that migration to the cloud? >> Well, I think the very first thing that's all about is data hygiene. You don't want to pick up your bad habits and take them to the cloud. You've got an opportunity here, so I see the journey to the cloud is an opportunity to really clean house, reorganize things, like moving out. You might move all your boxes, but you're kind of probably cherry pick what you're going to take with you and then you're going to organize it as you end up at your new destination. So from that, I get there's seven key principles that I like to operate by when I advise on the cloud migration. >> Okay. So, where do you start? >> Well, I think the first thing is understanding what you got, so discover and cataloging your data and your applications. If I don't know what I have, I can't move it, I can't improve it, I can't build up on it. And I have to understand there is dependency, so building that data catalog is the very first step. What do I got? >> Now, is that a metadata exercise? Sometimes there's more metadata than there is data. Is metadata part of that first step or? >> In deed, metadata is the first step so the metadata really describes the data you have. So, the metadata is going to tell me I have 2000 tables and maybe of those tables, there's an average of 25 columns each, and so that gives me a sketch if you will, of what I need to move. How big are the boxes I need to pack for my move to the cloud? >> Okay, and you're saying you can automate that data classification, categorization, discovery, correct using math machine intelligence, is that correct? >> Yeah, that's correct. So basically we go, and we will discover all of the schema, if you will, that's the metadata description of your tables and columns in your database in the data types. So we take, we will ingest that in, and we will build some insights around that. And we do that across a variety of platforms because everybody's organization has you've got a one yeah, an Oracle Database here, and you've got a Microsoft SQL Database here, you might have something else there that you need to bring site onto. And part of this journey is going to be about breaking down your data silos and understanding what you've got. >> Okay. So, we've done the audit, we know what we've got, what's next? Where do we go next? >> So the next thing is remediating that data. Where do I have duplicate data? Often times in an organization, data will get duplicated. So, somebody will take a snapshot of a data, and then ended up building a new application, which suddenly becomes dependent on that data. So it's not uncommon for an organization of 20 master instances of a customer. And you can see where that will go when trying to keep all that stuff in sync becomes a nightmare all by itself. So you want to understand where all your redundant data is. So when you go to the cloud, maybe you have an opportunity here to consolidate that data. >> Yeah, because you like to borrow in an Einstein or apply an Einstein Bromide right. Keep as much data as you can, but no more. >> Correct. >> Okay. So you get to the point to the second step you're kind of a one to reduce costs, then what? You figure out what to get rid of, or actually get rid of it, what's next? >> Yes, that would be the next step. So figuring out what you need and what you don't need often times I've found that there's obsolete columns of data in your databases that you just don't need, or maybe it's been superseded by another, you've got tables that have been superseded by other tables in your database. So you got to understand what's being used and what's not and then from that, you can decide, "I'm going to leave this stuff behind, "or I'm going to archive this stuff "cause I might need it for data retention "or I'm just going to delete it, "I don't need it at all." >> Well, Lester, most organizations, if they've been around a while, and the so-called incumbents, they've got data all over the place, their data marts, data warehouses, there are all kinds of different systems and the data lives in silos. So, how do you kind of deal with that problem? Is that part of the journey? >> That's a great point Dave, because you're right that the data silos happen because this business unit is chartered with this task another business unit has this task and that's how you get those instantiations of the same data occurring in multiple places. So as part of your cloud migration journey, you really want to plan where there's an opportunity to consolidate your data, because that means there'll be less to manage, there'll be less data to secure, and it'll have a smaller footprint, which means reduced costs. >> So, people always talk about a single version of the truth, data quality is a huge issue. I've talked to data practitioners and they've indicated that the quality metrics are in the single digits and they're trying to get to 90% plus, but maybe you could address data quality. Where does that fit in on the journey? >> That's, a very important point. First of all, you don't want to bring your legacy issues with you. As the point I made earlier, if you've got data quality issues, this is a good time to find those and identify and remediate them. But that can be a laborious task. We've had customers that have tried to do this by hand and it's very, very time consuming, cause you imagine if you've got 200 tables, 50,000 columns, imagine, the manual labor involved in doing that. And you could probably accomplish it, but it'll take a lot of work. So the opportunity to use tools here and automate that process is really will help you find those outliers there's that bad data and correct it before you move to the cloud. >> And you're just talking about that automation it's the same thing with data catalog and that one of the earlier steps. Organizations would do this manually or they try to do it manually and that's a lot of reason for the failure. They just, it's like cleaning out your data like you just don't want to do it (laughs). Okay, so then what's next? I think we're plowing through your steps here. What what's next on the journey? >> The next one is, in a nutshell, preserve your data format. Don't boil the ocean here to use a cliche. You want to do a certain degree of lift and shift because you've got application dependencies on that data and the data format, the tables on which they sit, the columns and the way they're named. So, some degree you are going to be doing a lift and shift, but it's an intelligent lift and shift using all the insights you've gathered by cataloging the data, looking for data quality issues, looking for duplicate columns, doing planning consolidation. You don't want to also rewrite your application. So, in that aspect, I think it's important to do a bit of lift and shift and preserve those data formats as they sit. >> Okay, so let me follow up on that. That sounds really important to me, because if you're doing a conversion and you're rewriting applications, that means that you're going to have to freeze the existing application, and then you going to be refueling the plane as you're in midair and a lot of times, especially with mission critical systems, you're never going to bring those together and that's a recipe for disaster, isn't it? >> Great analogy unless you're with the air force, you'll (mumbles) (laughs). Now, that's correct. It's you want to have bite-sized steps and that's why it's important to plan your journey, take these steps. You're using automation where you can to make that journey to the cloud much easier and more straightforward. >> All right, I like that. So we're taking a kind of a systems view and end to end view of the data pipeline, if you will. What's next? I think we're through. I think I've counted six. What's the lucky seven? >> Lucky seven, involve your business users. Really, when you think about it, your data is in silos. Part of this migration to the cloud is an opportunity to break down these silos, these silos that naturally occur as part of the business unit. You've got to break these cultural barriers that sometimes exist between business and say, so for example, I always advise, there's an opportunity here to consolidate your sensitive data, your PII, your personally identifiable information, and if three different business units have the same source of truth for that, there's was an opportunity to consolidate that into one as you migrate. That might be a little bit of tweaking to some of the apps that you have that are dependent on it, but in the long run, that's what you really want to do. You want to have a single source of truth, you want to ring fence that sensitive data, and you want all your business users talking together so that you're not reinventing the wheel. >> Well, the reason I think too that's so important is that you're now I would say you're creating a data driven culture. I know that's sort of a buzz word, but what it's true and what that means to me is that your users, your lines of business feel like they actually own the data rather than pointing fingers at the data group, the IT group, the data quality people, data engineers, saying, "Oh, I don't believe it." If the lines of business own the data, they're going to lean in, they're going to maybe bring their own data science resources to the table, and it's going to be a much more collaborative effort as opposed to a non-productive argument. >> Yeah. And that's where we want to get to. Data apps is key, and maybe that's a term that's still evolving. But really, you want the data to drive the business because that's where your insights are, that's where your value is. You want to break down the silos between not only the business units, as I mentioned, but also as you pointed out, the roles of the people that are working with it. A self service data culture is the right way to go with the right security controls, putting on my security hat of course in place so that if I'm a developer and I'm building a new application, I'd love to be able to go to the data catalog, "Oh, there's already a database that has the customer "what the customers have clicked on when shopping." I could use that. I don't have to rebuild that, I'll just use that as for my application. That's the kind of problems you want to be able to solve and that's where your cost reductions come in across the board. >> Yeah. I want to talk a little bit about the business context here. We always talk about data, it's the new source of competitive advantage, I think there's not a lot of debate about that, but it's hard. A lot of companies are struggling to get value out of their data because it's so difficult. All the things we've talked about, the silos, the data quality, et cetera. So, you mentioned the term data apps, data apps is all about streamlining, that data, pipelining, infusing automation and machine intelligence into that pipeline and then ultimately taking a systems view and compressing that time to insights so that you can drive monetization, whether it's cut costs, maybe it's new revenue, drive productivity, but it's that end to end cycle time reduction that successful practitioners talk about as having the biggest business impact. Are you seeing that? >> Absolutely, but it is a journey and it's a huge cultural change for some companies that are. I've worked in many companies that are ticket based IT-driven and just do even the marginalist of change or get insight, raise a ticket, wait a week and then out the other end will pop maybe a change that I needed and it'll take a while for us to get to a culture that truly has a self service data-driven nature where I'm the business owner, and I want to bring in a data scientist because we're losing. For example, a business might be losing to a competitor and they want to find what insights, why is the customer churn, for example, happening every Tuesday? What is it about Tuesday? This is where your data scientist comes in. The last thing you want is to raise a ticket, wait for the snapshot of the data, you want to enable that data scientist to come in, securely connect into the data, and do his analysis, and come back and give you those insights, which will give you that competitive advantage. >> Well, I love your point about churn, maybe it talks about the Andreessen quote that "Software's eating the world," and all companies are our software companies, and SaaS companies, and churn is the killer of SaaS companies. So very, very important point you're making. My last question for you before we summarize is the tech behind all of these. What makes Io-Tahoe unique in its ability to help automate that data pipeline? >> Well, we've done a lot of research, we have I think now maybe 11 pending patent applications, I think one has been approved to be issued (mumbles), but really, it's really about sitting down and doing the right kind of analysis and figuring out how we can optimize this journey. Some of these stuff isn't rocket science. You can read a schema and into an open source solution, but you can't necessarily find the hidden insights. So if I want to find my foreign key dependencies, which aren't always declared in the database, or I want to identify columns by their content, which because the columns might be labeled attribute one, attribute two, attribute three, or I want to find out how my data flows between the various tables in my database. That's the point at which you need to bring in automation, you need to bring in data science solutions, and there's even a degree of machine learning because for example, we might deduce that data is flowing from this table to this table and upon when you present that to the user with a 87% confidence, for example, and the user can go, or the administrator can go. Now, it really goes the other way, it was an invalid collusion and that's the machine learning cycle. So the next time we see that pattern again, in that environment we will be able to make a better recommendation because some things aren't black and white, they need that human intervention loop. >> All right, I just want to summarize with Lester Waters' playbook to moving to the cloud and I'll go through them. Hopefully, I took some notes, hopefully, I got them right. So step one, you want to do that data discovery audit, you want to be fact-based. Two is you want to remediate that data redundancy, and then three identify what you can get rid of. Oftentimes you don't get rid of stuff in IT, or maybe archive it to cheaper media. Four is consolidate those data silos, which is critical, breaking down those data barriers. And then, five is attack the quality issues before you do the migration. Six, which I thought was really intriguing was preserve that data format, you don't want to do the rewrite applications and do that conversion. It's okay to do a little bit of lifting and shifting >> This comes in after the task. >> Yeah, and then finally, and probably the most important is you got to have that relationship with the lines of business, your users, get them involved, begin that cultural shift. So I think great recipe Lester for safe cloud migration. I really appreciate your time. I'll give you the final word if you will bring us home. >> All right. Well, I think the journey to the cloud it's a tough one. You will save money, I have heard people say, you got to the cloud, it's too expensive, it's too this, too that, but really, there is an opportunity for savings. I'll tell you when I run data services as a PaaS service in the cloud, it's wonderful because I can scale up and scale down almost by virtually turning a knob. And so I'll have complete control and visibility of my costs. And so for me, that's very important. Io also, it gives me the opportunity to really ring fence my sensitive data, because let's face it, most organizations like being in a cheese grater when you talk about security, because there's so many ways in and out. So I find that by consolidating and bringing together the crown jewels, if you will. As a security practitioner, it's much more easy to control. But it's very important. You can't get there without some automation and automating this discovery and analysis process. >> Well, great advice. Lester, thanks so much. It's clear that the capex investments on data centers are generally not a good investment for most companies. Lester, really appreciate, Lester waters CTO of Io-Tahoe. Let's watch this short video and we'll come right back. You're watching The Cube, thank you. (upbeat music)

>> Live from Orlando, Florida. It's theCUBE. Covering Microsoft Ignite. Brought to you by Cohesity, and theCUBE's ecosystem partners. >> Welcome back everyone to theCUBE's live coverage of Microsoft Ignite here in Orlando, Florida. I'm your host, Rebecca Knight along with my cohost Stu Miniman. We're joined by Joachim Hammer, he is the Principal Product Manager at Microsoft. Thanks so much for coming on the show. >> Sure, you're welcome. Happy to be here. >> So there's been a lot of news and announcements with Azure SQL, can you sort of walk our viewers through a little bit about what's happened here at Ignite this week? >> Oh sure thing, so first of all I think it's a great time to be a customer of Azure SQL Database. We have a lot of innovations, and the latest one that we're really proud of, and we're just announced GA is SQL Managed Instance. So our family of database offers had so far a single database and then a pool of databases where you could do resource sharing. What was missing was this one ability for enterprise customers to migrate their workloads into Azure and take advantage of Azure without having to do any rewriting or refactoring and Managed Instance does exactly this. It's a way for enterprise customers to take their workloads, migrate them, it has all the features that they are used to from sequel server on-prem including all the security, which is of course as you can imagine always a concern in the cloud where you need to have the same or better security that customers are used to from on-prem, and with Managed Instance we have the security isolation, we have private IPV nets, we have all the intelligent protection that we have in Azure so it's a real package. And so this is a big deal for us, and the general purpose went GA yesterday actually, so I heard. >> Security's really interesting 'cause of course database is at the core of so many customer's businesses. You've been in this industry for a while, what do you see from customers as to the drivers and the differences of going to public cloud deployments versus really owning their database in-house and are security meeting the needs of what customers need now? >> Yeah sure, so, you're right, security is probably the most important topic or one of the most important topics that comes up when you discuss the cloud. And what customers want is they want a trust, they want this trust relationship that we do the right thing and doing the right thing means we have all the compliances, we adhere to all the privacy standards, but then we also offer them state of the art security so that they can rely on Microsoft on Azure for the next however many years they want to use the cloud to develop customer leading-edge security. And we do this for example with our encryption technology with Always Encrypted. This is one of those technologies that helps you protect your database against attacks by encrypting sensitive data and the data remains encrypted even though we process queries against it. So we protect against third-party attacks on the database, so Always Encrypted is one of those technologies that may not be for everybody today but customers get the sense that yes, Microsoft is thinking ahead, they're developing this security offering, and I can trust them that they continue to do this, keep my data safe and secure. >> Trust is so fundamental to this whole entire enterprise. How do you build trust with your customers, I mean you have the reputation, but how do you really go about getting your customers to say "Okay, I'm going to board your train?" >> That's a good question, Rebecca. I think as I said it starts with the portfolio of compliance requirements that we have and that we provide for Azure's SQL Database and all the other Azure services as well. But it also goes beyond that, it goes, for example, we have this right to audit capability in Azure where a company can come to us and says we want to look behind the scenes, we want to see what auditors see so that we can really believe that you are doing all the things you're saying. You're updating your virus protection, you're patching and you have all the right administrative workflows. So this is one way for us to say our doors are open if you want to come and see what we do, then you can come and peek behind the scenes so to speak. And then the other, the third part is by developing features like we do that help customers, first of all make it easy to secure the database, and help them understand vulnerabilities, and help them understand the configurations of their database and then implement the security strategy that they feel comfortable with and then letting them move that strategy into the cloud and implement it, and I think that's what we do in Azure, and that's why we've had so much success so far. >> Earlier this week we interviewed one of your peers, talked about Cosmos DB. >> Okay. >> There's a certain type of scale we talk about there. Scale means different things to different sized customers. What does scale mean in your space? >> Yeah so you're right, scale can mean a lot of different things, and actually thank you for bringing this up so we have another announcement that we made on namely Hyper-Scale architecture. So far in Azure SQL DB, we were pretty much constrained in terms of space by the underlying hardware, how much storage comes on these VMs, and thanks to our re-architectured hardware, sorry software, we now have the ability to scale way beyond four terabytes which is the current scale of Azure SQL DB. So we can go to 64 terabytes, 100 terabytes. And we can, not only does that free up, free us from the limitations, but it also keeps it simple for customers. So customers don't have to go and build a complicated scale out architecture to take advantage of this. They can just turn a knob in a portal, and then we give them as much horsepower as they need to include in the storage. And in order for this to happen, we had to do a lot of work. So it doesn't just mean, we didn't just re-architect storage but we also have to make fail-over's faster. We have to continue to invest in online operations like online index rebuild and create to make those resumable, pause and resumable, so that with bigger and bigger databases, you can actually do all those activities that you used to do ya know, without getting in the way of your workloads. So lot of work, but we have Hyper-Scale now in Azure SQL DB and so I think this is another sort of something that customers will be really excited about. >> Sounds like that could have been a real pain point for a lot of DBA's out there, and I'm wondering, I'm sure, as a PM, you get lots of feedback from customers. What are the biggest challenges they're facing? What are some of the things they're excited about that Microsoft's helping them with these days? >> So you're right, this was a big pain point, because if you go to a big enterprise customer and say, hey bring your workload to Azure, and then they say oh yeah great, we've got this big telemetry database, what's your size limit? And you have to say four terabytes, that doesn't go too well. So that's one thing, we've removed that blocker thankfully. Other pain points I think we have by and large, I think the large pain points are we've removed, I think we have small ones where we're still working on making our deployments less painful for some customers. There's customers who are really, really sensitive to disconnects or latent variations in latency. And sometimes when we do deployments, worldwide deployments, we are impacting somebody's customer, so this is a pain point that we're currently working on. Security, as you said, is always a pain point, so this is something that will stay with us, and we just have to make sure that we're keeping up with the security demands from customers. And then, another pain point, or has been a pain point for customers, especially customers sequel server on-prem is the performance tuning. When you have to be a really, really good DBA to tune your workloads well, and so this is something that we are working on in Azure SQL DB with our intelligence performance tuning. This is a paint point that we are removing. We've removed a lot of it already. There's still, occasionally, there's still customers who complaining about performance and that's understood. And this is something that we're also trying to help them with, make it easier, give 'em insights into what their workload is doing, where are the weights, where are the slow queries, and then help them diffuse that. >> So thinking about these announcements and the changes that you've made to improve functionality and increase, not have size limits be such a road block, when you're thinking ahead to making the database more intelligent, what are some of the things you're most excited about that are still in progress right now, still in development, that we'll be talking about at next year's Ignite? >> Yeah, so personally for me on the security side, what's really exciting to me is the, so security's a very complicated topic, and not all of our customers are fully comfortable figuring out what is my security strategy and how do I implement it, and is my data really secure. So understanding threats, understanding all this technology, so I think one of the visions that gets me excited about the potential of the cloud, is that we can make security in the future hopefully as easy as we were able to make query processing with the invention of the relational model, where we made this leap from having to write code to access your data to basically a declarative SQL type language where you say this is what I want and I don't care how to database system returns it to me. If you translate that to security, what would be ideal the sort of the North Star, is to tell it to have customers in some sort of declarative policy based manner, say I have some data that I don't trust to the cloud please find the sensitive information here, and then protect it so that I'm meeting ISO or I'm meeting HIPPA requirements or that I'm meeting my internal ya know, every company has internal policies about how data needs to be secured and handled. And so if you could translate that into a declarative policy and then upload that to us, and we figure out behind the scenes these are the things we need, you need to turn on auditing, these are where the audit events have to go, and this is where the data has to be protected. But before all that, we actually identify all the sensitive data for you, we'll tag it and so forth. That to me has been a tremendous, sort of untapped potential of the cloud. That's where I think this intelligence could go potentially. >> Yeah, great. >> Who knows, maybe. >> (laughs) Well, we shall see at next year's Ignite. >> We are making handholds there. We have a classification engine that helps customers find sensitive data. We have a vulnerability assessment, a rules engine that allows you to basically test the configuration of your database against potential vulnerabilities, and we have threat detection. So we have a lot of the pieces, and I think the next step for us is to put these all together into something that can then be much more automated so that a customer doesn't have to think technology anymore. They can they business. They can think about the kinds of compliances they have to meet. They can think about, based on these compliances, this data can go this month, this data can go maybe next year, or ya know, in that kind of terms. So I think, that to me is exciting. >> Well Joachim, thank you so much for coming on theCUBE. It was a pleasure having you here. >> It was my pleasure too. Thank you. >> I'm Rebecca Knight for Stu Miniman, we'll have more from theCUBE's live coverage of Microsoft Ignite coming up in just a little bit. (upbeat music)