Caylent’s Ryan Gross on Using AI to Accelerate Application Modernization

Hey guys, thanks for the throw. We're here with Ryan Gross, who's head of data and applications for Calin, and we're talking about the challenges that organizations face when they need to migrate databases, which is happening a lot more often than it used to for sure. Ryan, welcome to show.

Yeah, thanks for having me. I think one of the challenges we've always seen is when it comes to lock-in and the, the, the part of the stack that gives us the most amount of trouble has always been the database and the formats and the data and everything that's locked into that. Um, and I guess everybody's kind of hoping, you know, is that gonna get easier to move from one database to another?

Because that seems to be the crux of the matter and the reason why so many people are running legacy platforms from far longer than they probably want. Yeah, absolutely. That is something we, you know, I've been hearing throughout my career leading data and AI teams for a long time.

You always hear the phrase data has gravity, right? All of the cloud providers and everyone wants to get your data onto their platform because they are relatively aware that once that data is sitting there, it's gonna be much, much harder to move off of that plan. What people don't often talk about under that is that the data itself, because networking and other things has gotten so good over the years, it's not that hard to move like the raw data from one place to another place.

What is much harder though is that you have all sorts of processing over top of that data. And so the combination of both of those things moving both the data itself and everything that you do to gain insights from that data across platforms is really difficult. I've talked to some people where, you know, they can migrate the virtual machine and even the database, but the data itself might take them years after in that effort.

And that's kind of goes into all kinds of weird calculations as to whether or not it may be worth migrating off a platform versus sticking with it even though the licensing costs may keep going up. Yeah, exactly. And that for the longest time I'd say that that ROI equation was upside down for most companies that that fit the profile of starting with a database oriented infrastructure, maybe like 2005 to 2010 timeframe, where that was the primary way you built any application, maybe even earlier than that.

And then 10 years of building up more and more and more logic and processing and analytics around that data made it such that the cost and the risk of changing the underlying platform was so high. You know, you're talking projects that would last two years with very large teams and then, you know, maybe you're saving a million dollars, but a two year 10 person team is a lot, lot more than a million dollars. So how do I foot that equation and get right side up?

Yeah, I, I think the key thing here that's changed over the last year, year and a half is the advent of generative AI and specifically generative AI's capability to understand process and write code. And um, that gets coupled with its ability to understand and process and analyze data because really in a database code, application layer or in the database, you are trying to process both the data and the code together. Typically you would need to go have a team of, you know, 10 people each out there paralleled across lots and lots of different data processing logic, each going through reading all of the code, trying to understand what it's doing, remembering the differences between the platform it's on today and the platform it needs to move to tomorrow.

Rewriting that code, installing the, you know, the newly rewritten code, moving all of the data across onto the new platform realizing they got something wrong, going back to the drawing board and trying that again. And it just became this very cumbersome and tedious process. And the key thing that that really changed is generative ai.

You know, agents if you will, can do a lot of that rote work, not as well as humans. No, you're not as well as human database data engineering experts, but at such a larger scale at a lower cost that it makes it possible to take all 5,000 database queries that need to be rewritten and process them all in parallel, understand what went wrong, iterate on only the chunk that didn't go well and continue to go down that path. And what I've seen and experienced is that you can go somewhere between two and a half and five times faster with the average kind of being three times faster in terms of effort required when you use an AI driven process versus a manual process.

I think everybody's had at least one bad experience where they tried some sort of modernization project and they called in a global SI and then a busload of graduate students pulled up and moved in for two years and the cost went up through the roof. And boy that a few people probably lost their jobs and as a result, but is this getting now down to a point where I can take on a project like this and get it done in something I can measure in maybe weeks and months rather than years? Yeah, it is.

And I think the team size too, like you don't need the bus. Maybe a, a small van will get the team there these days. And so both a smaller team and also a shorter project duration obviously leads to significant amount of savings, but it also really dramatically reduces risk and overhead.

So I think the, the biggest problem that actually stopped companies after they had, you know, they got burnt once by the scenario you just described was not that it took a boatload of people at the beginning of the project, it's that there was so much undiscovered complexity that ended up making it take a boatload of people for two years instead of one or two boatloads of people in order to get it done. So they, their costs that they estimated and budgeted for upfront ended up ballooning by the time they actually got done with the project. And so the AI get driven approach because you're able to actually analyze all of the code in parallel using AI in the same way you can process it in parallel using AI both gets it faster because of the, you know, processing as described earlier better because you have to drive, uh, you know, a test driven approach into this, uh, you, you need to verify what came out and you know, compare the data on the old platform, the data on the new platform and, and much more reliably as well in terms of estimates that you come up with upfront are much closer to what the actual outcome looks like.

So you're talking, you know, a team of four to five people for four months for a big complex database that's been built up over 10 to 15 years. You also hear a lot about smaller projects, but they're just as annoying and it usually goes something like this. A developer creates an application and they downloaded some database that they built it on and then, uh, you know, they're running it for a couple of months and then they gotta move on to the next project and they're looking for a DBA to dump it on and then the DBA looks at it and says, well I'm not supporting that particular database and now I gotta go convert that app into the databases that we are using.

And that requires effort as well. So can we turn that down into something that maybe we can do in days? Yeah.

On, on something where you've got a limited amount of processing and especially where that processing was done, you know, with more recent technology, if the application layer is using ORM object relational mapping and the database code itself is written in some, you know, if it's multi-step processing using something like DBT, it's much easier to understand and translate those types of code than these, you know, stored procedures that have a thousand lines and call five SQL functions that are typical of, you know, a decade old or more projects. So in those cases, yes, you can oftentimes go much faster and also you can take the risk down by using a little bit more of like the AWS schema conversion tool approach where you've got a little bit more of a, um, rules based approach versus an AI driven approach to doing some of that translation where it's more modern code. What will be the incentive to kind of consolidate or shift from one database format to another in the age of ai?

'cause I'm asking the question 'cause some folks are thinking, well I don't have to worry about that anymore. The AI agent knows how to access all that stuff and we'll pull it and then they'll share it amongst themselves and gimme some sort of output. But is there some benefit to be gained by modernizing the underlying database structures?

There certainly is. Uh, so ultimately the AI agents will allow you to generate whatever queries you want these days quite effectively, but it doesn't necessarily mean that those queries are going to run efficiently on the underlying data and the way that that data is structured. So oftentimes natural language query opens up a whole new audience of people who can then come in and write queries that end up knocking your database over in, you know, proverbial terms there and the DBAs are getting calls about the CPU being on fire, that storage is uh, continually getting churned 'cause you're out of memory.

All of those types of things that DBAs have been dealing with forever. Maybe in a more cloud modern platform you can just scale up the compute that's allocated here that just leads to the CFO coming and, you know, banging down your door saying why are you spending, you know, millions on this underlying database platform. So there is certainly something to be said for AI actually exacerbating the problem of some of these legacy structures, legacy databases because it brings so much more accessibility to a wider audience to be able to bring queries versus the DBA driven approach of the past.

Mm-hmm. And then I, I will say that the licensing costs in this case are not solved by ai, right? The, if your underlying data is sitting on a platform like Microsoft SQL DB two Oracle that has significant per core licensing, AI does not magically make that go away.

Do you think that as we get into the age of ai, the volume of data that we're gonna be playing around with is certainly gonna exponentially increase? And is that also gonna force a database consolidation conversation just because it will be too unwieldy to manage across so many different formats, especially if they're older formats? Yeah, I think that's a lot of what we've been seeing is, uh, the companies that want to undertake these projects, the licensing cost helps it get over the, the hump right now of being able to justify the project cost in a pure simple to understand financial means.

But really the teams that we're, that I'm working with are out there that trying to do this for agility reasons, they wanna move on to a cloud native platform. Oftentimes you've seen more and more even over the last couple of months consolidation towards Postgres as the defacto standard there with, you know, Databricks and the acquisition of a Postgres given company, uh, based company. Snowflake doing the same thing.

Obviously Amazon has for a long time with Redshift and Aurora had a strong footprint in that space. And the reason you want to go there is because it can become very scalable. You can scale horizontally, you can replicate the database without any licensing constraints.

You can look at rewriting the backend, how you store the data in different ways to take on analytical processing versus transactional processing in a way that still optimizes underneath the hood so that your end users don't need to care about how the data is structured. And so that move from per core license databases towards open source databases is both to save the money of not having to pay those per core licenses, but also to be able to get the agility and flexibility to scale to that expected onslaught of AI demand for data. So is there something that organizations should be doing today to make sure they don't get locked in tomorrow when it comes to databases and data file formats and everything that goes with it?

Because I think it's pretty easy to still, you know, find yourself locked into something, but are there particular formats that I shouldn't be saying, Hey, we need to make sure we adhere to this, otherwise we'll pay a hard cost tomorrow? I do think that the, like I mentioned before, the two standards that seem to be becoming defacto if you're starting a net new project today are for database protocol. The, you know, the Postgres Pro protocol and the various implementations of that are now supported across most major database platforms for both applications and analytics.

And then for the raw storage of mass volumes of data, um, Apache Iceberg seems to be becoming the defacto standard. And so in those types of greenfield scenarios, you oftentimes can just start building out on top of those protocols. And then again, you still need to think through in both of those cases, how do you actually structure the underlying data in order to be able to support both efficient queries with lots of filtering as well as, you know, machine learning and AI type use cases where you want to get data in bulk and to see that as somewhat orthogonal to the targets here of moving onto that modern platform.

But very few companies are out there really truly starting Greenfield. It's almost always that you have to maybe set that up as your platform of the future and then move your current legacy footprint towards that platform while also building the new things there. So what's that one thing you see organizations doing over and over again and just makes you shake your head and go, folks?

I think we need to be a little bit smarter than that There. There's certainly a couple of them that come to mind here. If I had to pick the number one thing that I've seen, it's starting the process of building something without actually thinking about it from a data first lens.

So we're going to build this application, mainly we care about the screens or the way that that AI agent is going to be able to respond in the, you know, the tone it's going to use and then the data is just ah, whenever, we'll, we'll throw it in there however we need to right now. And then over time we'll just keep hacking a layer on top of that and a layer on top of that and a layer on top of that until we're able to meet the end user functionality that we want to deliver. And that's what all these companies that we're talking to today about trying to modernize these platforms that they basically thought that they had gotten themselves trapped into, that was the exact pattern they followed that led them to be in that scenario.

And so it's interesting to still, still see companies doing this today, just take the, you know, the latest trend on vector database. Oh yeah, we'll just throw everything in some JSON, we'll throw a vector store on it and that should solve all of our problems. And then as you need to make that perform, taking that same data set and taking a process where you are packing off little bits of it and storing it structured and continuing down the path of keeping that all in one database, you're just setting yourself up for a tech debt remediation problem four or five years down the line.

Hey folks, you heard it here. All good and bad things stem from that initial decision you made about the data. So be careful out there.

Hey Ryan, thanks for being on the show. Really appreciate it. Really enjoyed the conversation.

Thank you. And back to you guys in the studio.