Data Warehouse Migration – Mike Waas, Datometry

This is texturing TV. Hey everyone, welcome to another tech strung TV segment here kind of first time company that we have not highlighted before. I want to introduce you and a first-time guest.

I should mention I want to introduce you to Mike was Mike is with a company called the Optometry. He's gonna spell it for us and give us the URL. Hey, Mike, welcome to text drug TV.

Hi Alan, great to be here. Thanks. Nice to have you.

So if you don't mind, let's get that out of the way first thetometry. How do you spell it? Where do people go on the web to find the company?

com. Excellent. All right, Mike.

Why don't we start with if you don't mind. Let's give people a little bit of you know, the Mike Watts story and and then a little bit of the detonatory story. Absolutely.

So I'm a database geek. I've been working in databases for the last 30 years first in Academia, then with major database vendors and for the last almost 10 years. I've been doing the Optometry and one thing that while working on databases working on the vendor side was kind of becoming obvious to me was it doesn't matter whether you have to better faster or cheaper database the biggest problem for people to move between databases.

Is that they build all these applications on top of that database? And it's just incredibly difficult slash impossible to move these applications. And so over time major Enterprises end up with this large database Fleet of all sets of databases that they adopted over the years never get to consolidate and never really get to move on.

And so the odometry story is really kind of worn out of that experience both as a vendor but also on the customer side where I was looking at moving an Enterprise out of a database commitment that they've made for a couple of decades and we were unable and so with the Optometry the idea here is what if we introduce an abstraction. Between the application and the database that's its in between and that acts as and as a real-time translator so that your application. Speaking whatever language it speaks what it was originally you developed for can I cannot talk to pretty much any other database?

You wouldn't have to migrate. You wouldn't have to rewrite your code. You wouldn't have to reinvent the business.

Just take your application slap Optometry underage and now you can run on for example of modern Cloud database. That's really the idea behind autonomy. com days.

I worked for what we called in ASP. I help put together an ASV wind upcoming public and everything application service provider and we had a whole Fleet of applications that we were offering in our offering in a hosted environment is before there was a cloud right and and all of ubiquitous family and all of that but the interesting thing is we had a common problem there that even back then people wanted Their you know library of applications to give you an idea of how old it is. We're talking people soft and and Onyx and some of the Oracle things and Lawson and Lotus Notes.

But anyway, Wanted a common data set that ran across. all or not at ran across that all these applications ran on top of Right so that I didn't need a separate database. For each application and that you know, we could because then you could look at you know, the data sets across not just per application and we were always in search of what we called the miracle layer.

That somehow was gonna abstract the database right abstract the data from the database. But would plug in we didn't have apis back then like they do now even but that somehow we were going to write connectors to the individual applications that would allow it to pull from an external data source, which many of these applications back then were not set up for right Oracle apps didn't work without Oracle database. com boom bus came when they went bankrupt everything else.

So are you saying you've now solved this problem? We solve the problem, but with a different technology and technology in the sense that in the past a lot of folks looked at this thing. Hey, can we just unify all databases so that at the application Level?

I see one database. And then all I need is one universal database programming language and I can rule them all and that's the idea of data visualization. It's been around for a long time.

But as you know, it's never really caught on that much and the problem with that is that you first have to migrate all of your applications to use that universal language. But also you're pulling so much functionality out of the database that you basically building a separate database in the middle. And these things just never really seem to have commercially worked out and what we do is kind of somewhat similar yet very different in that.

We don't pull functionality out of the database. We'll let your application come as it is speak to any of these databases as if it was it's native database that it was originally written for and so you can take a Let's say I turn into application and put it on ashes synapse or on Google bigquery and you can just speak with the same language that it had before and you wouldn't have to change the application. You don't need to be aware of that.

And to kind of give you an idea of just how seamless this can work. We recently had a major logistics company. We platform they're workloads off of their own premises data warehouse.

One of the most complex ones in all of India and told move that to a cloud native database and our champion. There was during the implementation. So impressed by how seamless this works that he decided not to tell his users when he cuts them over now.

Keep in mind. This is a mission critical system. This is open heart surgery.

And he cut over 5,000 users on a weekend from one database into a cloud database without telling them. and nobody knew No accidents, like imagine. It operations usually are never smooth but re-platforming a database without telling anybody that's kind of a whole new league.

Yeah, that's crazy. Here people would lose their job for that. But but that's great.

So so where's the magic then? How does this get done? I think you tell us we're good.

Well for self it is engineering. It's hard engineering and when you think about the work that we needed to do was really around. Implementing several surfaces of databases and that's just a really huge amount of work that needs to be done.

and a lot of people when I started out with the commentary said it's probably going to take about 20 years, huh? Do you think? And first off you need the right team and I'm super proud honored and humble to have assembled a team of experts who have that necessary not only skill set and talent but also that conviction to make that happen.

But then also really understanding what's the architecture that we need for this. This is something that is a bit akin to a query Optimizer ultimately and that's kind of generally considered one of the most complex components of a database and so we've taken a lot of database research from that space and brought that into into our product and lastly we've also used kind of technology that we knew will allow us to be much more productive in the space. So we're using what is kind of carry a great platform called online OTP that was really written for taking packets off the network doing something to them and putting them back on.

And that's really The Sweet Spot of that language very very popular in telcos in telecommunication and that just happens to be the sweet spot for us as well. And so that has been an enormous productivity boost for us. Have we done this in kind of conventional technology?

I think it would have taken a number of years more but it really is coming down to tough engineering and and research actually, so it sounds like the I don't say the use case, but the the driver for for people looking at denimentary is you know as they're moving from an on-prem sort of database solution to a cloud-based. Solution it's also a good time. Usually to change it not a good time because never a good time perhaps but it's also a time where people look to change the database there aren't so it's more than just running Oracle here in Oracle there or no sequel here and there it's really changing, you know databases and you might as well do it when you're changing location as well.

exactly so that now of course in real life things there's never there's fewer greenfields than there are brownfields and people don't just migrate from on-prem to cloud in one Fell Swoop You know, there's a there's a migration and that migration can take months years even. How does how does? How does the solution work there?

Yeah, we we really if you will disrupt that whole notion of you need five years or even 10 years to move your critical data assets. We've been able to pull some of really complex data warehouses into Cloud databases within three quarters within less than 10 months and that by itself is if you will a record but it goes much further and that is We are not really a migration tool granted. The migration use case is a very obvious one and is one where the entire industry is clamoring right now because everybody is pushing to Cloud everybody is eager to replace their kind of conventional databases with platform native databases databases are deeply integrated into the cloud infrastructure.

But think about it. We're really extraction good makes a lot of other things now happen almost like a Swiss army knife off database connectivity and the next step here is every major Enterprise today. As I mentioned at the beginning has a lot of different databases.

And recently I asked an IT leader at a major Investment Bank here in the US. Databases do you have right now? How many database types and very quickly they came up with about kind of ballparking it about 150.

And then I asked him. So how many do you really think you need? And they couldn't really enumerate more than about eight.

All the other stuff on databases that they effectively picked up at some point in time, but couldn't shed and there was never enough time money to shed these because the application running on them and they're perfectly fine never change a winning team. And so they ended up with this massive database Fleet The Next Step here story is really about consolidation the classic virtualization benefit if you will that yeah, you can put 10 20 of these different application Stacks now back on to just one database. Or onto five databases, but you don't need 150.

And so that's kind of really The Next Step here and it's the same. To the beauty about it. It's not like we're building something new for this.

It's the same technology that enables that and then one level up after that in the journey is what you mentioned at the beginning. You want your applications to test to to access data in different databases? And you don't want to travel the data back and forth.

And so with our technology you make that also happen because now you application can pull data from database. One two, three hands on and so forth completely seamlessly. And so there's a really large Journey that enterprises are currently embarking on migration is really just the starting point for us.

The classic virtualization benefits of consolidation and optimization and just really streamlining it is what we're going for in the next chapter here. Okay. I having fitting where I sit right unique view of the market and I often say to people when they find out about a company about the time, you know, say the name for me again.

I don't mess it up. Optometry, yep, you know people say wow. Where did this company come from?

This is great. They what a great solution. It's like, you know, and it's like yeah, it's another one of those 10 year overnight successes, right people don't realize as a Founder, you know, you put your Blood Sweat and Tears for and you build something and it takes You know a lot of things don't get built in three months or six months or even a year.

It does take takes time to build the company and take time to build Solutions and it takes time to build the market. And but one day it's like you burst on the scene right people like oh my God, wait this come from but it sounds like you know, that's kind of your story here. You guys have been added and you've perfected it and congratulations to you and the whole team.

You know, thank you so much. Great. and that's really interesting point in there just to highlight this and that is That whole idea about making databases interchangeable and abstraction of the database as you said before that's been in people's minds for a long time as long as they have been databases because it's been one of the problems that database are always had.

But what really made that possible is kind of where the market moved in the last couple of years and that is that pushed to the cloud that's been kind of an external forcing function for really everybody to say. Hey, we need to reevaluate whether we should stay on that database or not. And that has kind of really created an earthquake across the industry that really has shaken up everybody and had it not been for that.

I think it would have been much tougher to kind of break into the market. But that's kind of an external enabler if you will. A great agreed that hey before we go one last time give them the website.

com absolutely, check it out Mike. Thanks for coming our text on TV and keeping us posted on this. It sounds great.

We look forward to hearing more from you. Thanks all for having me. com.

I might watch here on Tech strong TV. We're gonna take a break and we'll be back here in a moment. our texture