 From around the globe, it's theCUBE with digital coverage of PostgreSQL Vision 2021, brought to you by EDB. Hello everyone, this is Dave Vellante for theCUBE and we're here covering PostgreSQL Vision 2021, the virtual version, the CUBE virtual, if you will, and welcome to our power panel. Now in this session, we'll dig into database modernization. We want to better understand how and why customers are tapping open source to drive innovation, but at the same time, they've got to deliver the resiliency and enterprise capabilities that they're used to that are now necessary to support today's digital business requirements. And with me are three experts on these matters. Abdul Shake is global CTO and president of Cintra. Young Hill Cho, AKA Charlie, is the high availability cluster sales manager at DAWON CNS and Alan Villalobos is the director of development partnerships at IBM. Gentlemen, welcome to theCUBE. Thank you Dave, nice to be here. Thank you Dave. All right, let's talk trends and frame the problem Abdul. I want to start with you Cintra, you're all about this topic, accelerating innovation, using EDB Postgres, helping customers move to modern platforms. And doing so, you got to do it cost effectively, but what's driving these moves? What are the problems that you're seeing at the organizations that you serve? So let me quickly introduce Abdul Shake CTO, quickly introduce Cintra. So we are a multi-cloud and database architecture MSP and we've been around for 25 plus years, I quoted in New York and the UK, but as a global organization, we're serving our SMB customers as well as large enterprise customers. And the trends we're seeing certainly in this day and age is transformation and modernization. And what that means is customers looking to get out of their legacy platforms, let them get out of their legacy data centers and really move towards a modern strategy with a lower cost base, while still retaining resiliency and freedom, ultimately in terms of where they're going. The key words are really, I see the driving this. Number one is choice, right? They've been historically locked into vendors, I would limited choice with a high cost base. So choice, freedom to choose in terms of what database technologies they apply to which workloads and certainly EDB and the work that has been done to closely marry what enterprise RD events platforms offer with EDB's work that they've done in terms of filling those gaps and addressing where the resiliency, monitoring, performance and security requirements are certainly required from an enterprise customer perspective, choices driving the move that we see and choice towards a lower cost platform that can be deployed anywhere, both on-prem modernization, customers looking to retain on-premise platforms or moving into any multi-clouds, whether it's an infrastructure cloud play or a platform cloud play, and certainly with EDB's offering in terms of the latest cloud native offerings are also very interesting. And lastly, aside from just cost and the freedom to choose where they deploy those platforms, the SLA, the service level model, where is the resiliency requirement, where which system is going to bronze over gold, which ones are the tier one revenue platform, revenue generating platforms, which ones are lower utility platforms. So a combination of choice, for a combination of freedom to deploy anywhere and while still maintaining the resiliency and the service levels that customers need to deliver to their businesses. Abdul has a beautiful setup and we got so much to talk about here because customers want to move from point A to point B, but getting there, they need help. It's sometimes not trivial. So Charlie, dial one is a consultancy, you got a strong technical capabilities. What are you seeing in this space? You know, what are the major trends? Why are organizations considering that move? And what are some of the considerations there? Well, like in other country in South Korea also, our, a lot of customers, bankings, manufacturers and distributor, they are 90 or 90% they are all using an Oracle DB and Rack system. As the previous presented pointed out, a lot of customers got sick of the Oracle and they have to undergo the huge cost of maintenance cost. They want to move away from these cost of stress. And secondly, they can think about their providing service to customer on their cloud base, which is a private or the public. So we cannot imagine running on database, Oracle database running on the cloud system that's not matches on this cloud. And first and second, and finally the customer, what they want is the cost and they want to move away from the Oracle locking. They cannot be just a slave of the Oracle for a long time and the premium for the new cloud service for the customer. Great, thank you for that. Oh, go ahead. Did you have something else to add, Charlie? Go ahead, please. No, no, that's all. Okay, great. Alan, welcome to theCUBE. It's very interesting to us, IBM. Of course, you're a big player in database. You have a lot of expertise here and you've partnered with EDB, you're offering Postgres to customers. What are you seeing? Charlie was talking about Oracle and Rack. The thing there is obviously, we talked about the maintenance cost, but there's also a lot of high availability capabilities. That's something that IBM really understands well. Do you see this as largely a cloud migration trend? Is it more modernization? Are you interested in what's IBM's perspective on this? Yeah, I think modernization is the right word. The points that the previous panelists brought up are on point, right? Lower TCO, lower cost in general, that kind of agility and then availability for developers and data scientists as well. And then of course, hybrid cloud, right? You want to be able to deploy on-prem or in the cloud or both and then that makes sure of all of that. And I think what ties it together is that customers are looking for insights, right? And especially in large organizations, there's a myriad of data sources that they're already working with. And we want to be able to play in that space. We want to give an offering that is based on Postgres and open source and be able to do what they're strong at. And kind of on top of that, a layer of need that we see is seamless data governance across all of those different stores. All right, I'm going to go right to the heart of the hard problem here. So if I, I mean, I want to get from point A to point B, I want to save money, I want to modernize. But if I'm the canary in the coal mine that the customer I'm saying, guys, migration, scares me, how do I do that? What are the considerations and what do I need to know that I don't know? So Abdul, maybe you could walk us through what are some of the concerns that customers have? How do you help mitigate those? Whether it's other application dependencies, freezing code, getting again from that point A to point B without risking my existing business processes, how do you handle that? Yeah, certainly I think customers need to understand what the journey looks like to begin with. So we've actually developed our own methodology that we call Racket Cloud, which is also part of our cloud modernization strategy that builds in a database modernization strategy built into it, starts with an assessment in terms of current state discovery. Not all customers totally understand where they are today. So understanding where the database estate is, where the risks lie, what are the criticalities of the various databases, what technologies are in use, where we have Rack, where we don't have Rack, where we have Data Guard, where we have encryption and so on. That gives the customer a very good insight in terms of the current state, both commercially and technically. That's a key point. Now to understand how they're licensed today and what costs could be freed up to free the journey, to effectively fund the journey is a big topic. But once we do that, we get an idea and we've actually developed a tool that we call Racket Discovery that's able to discover a larger state without knowing the database list. We just point the scripts at the database service themselves and it tells us exactly which databases are suited to be effectively migrated to Postgres in terms of the feature function usage, in terms of how heavy they are with stored procedures in the database, the amount of business logic, use of technologies like Rack and Data Guard and how they convert over to Postgres specifically. That ultimately gives us the ability to give the customer an assessment and that assessment in a short, sharp few weeks can give the customer a view of my hundreds of databases, here the subset of candidates for Postgres and specifically then we do the schema advisor tool, the actual assessment tool, FOMA-EDB, which gives us a sense of how well the schema gets converted and how best to then also look at the stored procedure conversion as well. That gives the customer a full view of their architecture mapping, their specific candidate databases, and then a cost analysis in terms of what that migration looks like and how we migrate and also how we also run and maintain those platforms once we're on EDB. Thank you for that, again, very clear, but so you're not replacing doing an organ transplant, you may, I don't mean this as a pejorative, but you're kind of cherry picking those workloads that are appropriate for EDB and then moving those and then maybe through attrition or over time sunsetting those other core pieces. Exactly. Charlie, let me ask you, so we talked about RAC, Real Application Clusters, Data Guard, these are kind of high profile Oracle capabilities. Can you really replicate the kind of resiliency at lower cost with open source, with EDB Postgres? And how do you do that? That's my turn, sir. Yes, please. Quite technically, again, I go on, but it's in depth and technically, the RAC, RAC system is so called, is the best tool to protect the data and especially in the Unix system. But apart from the RAC, EDB has some nice data replication solution which is stream replication and log shipping and something of, and they monitor PAM and EFM solution, which is Enterprise Failable Manager. So even though if you compare Apple to Apple, RAC versus with the EDB solution, we can definitely say that RAC is more stable one, but after migration, whatever, we can overcome the drawbacks of the HA cluster system by providing the EDB tools. So whatever, the customer feel that after successful migration, utilizing the EDB high availability, available solution, they can make themself feel at home. So that's how we approach with the customers. So, Alan, again, to me, IBM is fascinating here with your level of involvement because you guys are sort of historically the master of proprietary mainframes, VCAM, CICS, DB2, all that stuff. And then, IBM was the first, I remember Steve Mills actually announced, we're going to invest a billion dollars in open source with Linux and that was a major industry milestone and of course the acquisition of Red Hat. So you've got now this open source mindset, this open source culture. So it's all about recovery in database and enterprise database and all of asset properties and two phase commits. And we're talking about the things that Charlie just talked about. So what's your perspective here? IBM knows a lot about this. How do you help customers get there? Yeah, well, I mean, the main interest right now, IBM has offering called IBM Cloud Pack for data, which you've made for probably about. Absolutely. And which runs EDB, right? EDB Postgres runs on top of Cloud Pack for data. But I think going back to Abdul's points about migrating whatever is needed and whatever can be migrated to Postgres and maybe migrating other things to other places, we have data virtualization and auto sequel, right? So once you have migrated those parts of your database or those schemas that can be, having a single point where you can query across them. And by the way, being able to query across them before or during and after migration as well, right? So you kind of have that seamless experience of sequel, layer of sequel, and now with auto sequel of Spark sequel as well as you're as you're migrating and after is I'd say, you know, key to this. What's the typical migration look like? I know, sorry, but it's a consultant question, but thinking about the, you know, the average in terms of timeframe, what are the teams look like? You know, who are the stakeholders that I need to get involved if I'm a customer to really make this a success? Maybe Abdul, you could talk about that and Charlie and Alan can chime in. Sure, I think, well, number one, you need an exact sponsors brought into it in terms of the business case, supporting the business case. An architect who's got a big picture understanding not only database technology, but also infrastructure that they're coming from as well as the target platforms and how you ensure that the infrastructure can deliver the performance. So the architect world is important. Of course, the core DBA that lives within the scope of the database understands the schema, the data model, the business logic itself and the application owner. And that's key, specifically around the application certification, testing, connectivity and the migration of the code. And specifically in terms of timeline, just to touch on that, you know, quickly, I mean, in our experience so far, and we're seeing the momentum really, really take off in the last 18 months. A small project with limited business logic within the database itself can be migrated, you know, in a couple of months, but typically with all the testing and rigor around that, we typically say a three month timeline, a medium size complexity projects, a six month timeline, and a large complex project can be anything from nine months and beyond. But it really comes down to how heavy the database is with business logic in the database and how much effort it will take to re-engineer, effectively migrate that PLC for business logic into EDB. Given the compatibility level between Oracle and EDB, it's a relatively, certainly an easier path than any other target platform in terms of options. Yeah, from our perspective, that certainly looks like the composition of a team and timeline. Charlie or Alan, anything you guys would add? Yeah, yeah, yeah. So I think all those personas make sense. I think you might on the consumer side of the consumer, the consumer of the data side, the data scientists often we see, you know, during migrations. And then obviously the DevOps, I think, or any operations where you have to be heavily involved. And then lastly, you know, you see more and more data steward role or data steward type persona, CDO office type type person coming in to make sure that, you know, whatever data governance that is already in place or wants to be in place after the migration is also part of the conversation. Good point. Why EDB? You know, there's a lot of databases out there. Yeah, it's funny. I always say like, you know, 10 and 15 years ago databases were kind of, it was kind of a boring market, right? It was like, okay, you got to work or whatever. And now it's exploded. You got open source databases, you got, you know, not only SQL databases, you got graph databases, you got cloud databases. It's going crazy. Why EDB? I wonder if you guys could address that. Alan, why don't you go first this time? I'll compliment your answer. Yeah, I mean, again, it goes back to, to the, I guess, varying needs in enterprises, right? And I think that's what's driven this explosion in databases, whether it's a document store, like you're saying, or new types of our DBMS, the need that we talked about at the beginning, like lower TCO and then push to open source. But, you know, the fact of the matter is that, yes, there is a myriad and ecosystem of databases that pretty much any organization. And so, yeah, we want to tap into that. And, and why EDB, you know, EDB has done a great job of taking Postgres and making it enterprise-ready. You know, that, that's what they're, they're good at. And, and that, you know, fits very nicely with, with the IBM story, obviously. And, and so, you know, and, you know, and then they've worked with us as well. They have an operator on the runs on Red Hat OpenShift. So that makes it portable as well. Also part of the IBM Plot Pack for Data story. And, and yeah, you know, we want to break down those silos. We realize that that need is there for all of these, you know, there's this ecosystem of databases. And so, you know, we're, you know, we see our role as being that platform, you know, whether it's Red Hat OpenShift or IBM Plot Pack for Data that unifies and kind of gives you that, that single pane of glass across all of those sources. And Charlie, you're obviously all in. You got EDB in your, in your, in your background. Yeah, yeah, yeah, yeah. Why EDB for you? You, you know, Before talking about EDB, you asked about the previous question about how the migration was difficult from Oracle to EDB. We had a couple of success stories in Korea, Telecom and some banking area. And it was not easy. So EDB provided an MTK tool as people know, it wasn't appropriate, like 90%. So we are the channel partner of the EDB for four years. So what we have done was to hire the Oracle Expert. So we train Oracle Expert as an EDB expert at the same time so that they can approach customer and make it easy. So you have no worry about that. Just the migrating EDB, Oracle to EDB, there's a no issue, no strata. It includes all the tests, you know, strata test and training and POC with that. So by investing that Oracle Expert that we could overcome and persuade the customer to adopt EDB. So why EDB? Simply I can say that, is there any database they can finally replace Oracle in the world? Why is there is an interoperability between Oracle to EDB as many experts pointed out? There's no other DB they can, you know, 90% compatibility and interoperability with EDB. That's why of course there's some budget issues, maintenance issue, cost issue, escape from Oracle Lock-in. But I think the number one reason was the interoperability and the compatibility with EDB in Oracle database, that was the reason I guess. Right, Abdul, we've talked about, we all know the as is. You got high maintenance cost, you got a lot of tuning and it's just a lot of complexity. What about the 2B? Maybe you could share with us sort of the outcome, some of the outcomes you've seen, what the business impact has been of some of these migrations? Sure, I mean, I'll give you a very simple example then just the idea of running Oracle on-prem. A lot of customer systems teams, for example, will drive a virtualization VMware strategy. We know some of the challenges of running Oracle on VMware from a licensed perspective. So giving the business the ability where one particular customer in the financial services market in New York, heavy virtualization strategy, the ability for them to move away from Oracle on, you know, expensive hardware onto Postgres EDB on virtualization, just leverage existing skill sets, leverage existing investment in terms of infrastructure and also give them portability into AWS, the other clouds, you know, in terms of a migration. More from a business perspective as well, I would say about some of the islands points in terms of just freeing up the ability for data scientists and data consumers to consume some of that data from a Postgres perspective, more accessibility, spitting up environments quicker, less latency in terms of, so agility is another keyword in terms of the tangible differences of the business, lower cost, agility and the freedom to deploy anywhere at the end of the day. Choices, I think the key word that we keep coming back to and knowing that we can do that to, Charlie's point specifically around maintaining service levels. And as architects, we support some of the big names out there in terms of airlines, online cosmetic retailers, financial services, trading applications, hedge funds and they all want one thing as architect for us to deliver their resiliency and stand behind them and as the MSP were accountable to ensure those systems are up and running and performing. So knowing that the EDBs provided the compatibility but also plug the specific requirements around performance management, security availability that's fundamentally been key. Yeah, so I mean, having done a lot of TCO studies in this area, Oracle's different. Normally the biggest component of TCO is labor with Oracle the biggest component of TCO is license and maintenance costs. So if you can virtualize and reduce those costs and of course, of course Oracle will fight you and say we won't support it in the VMware environment. Of course, you know, they will but you got to really, you got to battle. But so here's my last question. So if I'm a customer in that state that you described, you know, a lot of sort of Oracle sprawl, a lot of databases out there, high maintenance costs, the whole lock in thing, I got a choices, you know, a lot of choices out there. One is EDB, you guys have convinced me that you've got the expertise. It's, you know, if I can partner with firms like yours, it's safer route. Okay, cool. My other choice is Oracle's, the Oracle sales rep's going to get me in a headlock and talk about Exadata and how their Oracle cloud and how they've invested a lot there and they have and I can pay by the drink, all this sort of modern sort of discussion, you know, Oracle act like they invented late to the game and then here we are. So help me, what's the pitch as to, well, that's kind of compelling. It's maybe the safe bet. They're working with my CIO, whatever. Why should I go with the open source route versus that route? It sounds kind of attractive to me. Help me understand that, each of you, maybe take me through that. Abdul, why don't you start? Yeah, I'd say, you know, Oracle's being the de facto for so many years that people have just assumed and defaulted saying, high availability, right? DR, data guard, you know, and I'll apply it to any database need I have. And at the end of the day, customers have a three tier database requirement. The lowest, you know, less critical bronze level databases that really don't need rack or a high availability. The silver tier that are departmental solutions that need some level of resiliency. And then you've got your gold revenue producing, you know, brand impacting databases that are there down. And certainly day one, you see no reason why the bronze and silver databases can be targeted towards EDB. Admittedly, we have some of our largest customers running platforms, they're running $5 million an hour e-commerce platform or airlines running large e-commerce platforms. Exadata certainly has a place. Rack has a place in those scenarios. When I was saying that EDB is a solution for everything in all scenarios, but apply the technology where it's appropriate, where it's required. And, you know, generally where Oracle's been the de facto and it's been applied across the estate, that's fundamentally what's changed. It doesn't have to be the only answer. You have multiple choices. And now EDB provides us with the ability to probably address, you know, more than 50% of the database estate and comfortably cope with that and just apply that more expensive kind of gold tier one cost-based but also capability, you know, from the highest requirements of performance and availability where it's appropriate. We have very pragmatic approach, Abdul. Thank you for that. Charlie, what's your perspective? Give us your closing thoughts. Well, Oracle has been dominating in Asia and like South Korea has marked it over many years. So customers got tired of this and continue spending money for the maintenance costs and there is no discount. There is no negotiation. So they want to move away from expensive stuff. And they were looking for flexible platform with the easy going and the high speed and performance open source database like you're possibly as career. And now the EDB cannot replace 100% of existing legacy Oracle, but 10%, 20%, 50% as time goes on, the trend will continue and it will be reaching some high point of replacing the existing Oracle system. And it can also leading to good business chance to a channel partner and EDB steps and other related business in open source. Great, thank you, Charlie. And Alan, bring us home here. I think my co-panelists have hit the nail on the head. It's a menu, right? That's as things become more diverse and as people make more choices and as everybody wants more agility, you have to provide a menu. And so that's where that's coming in. And I like the way that we'll kind of split into gold, silver and bronze. Yeah, and I think that's where we're going, right? I mean, you should ask your developers, right? Are your developers like just pining to start up a new instance of Oracle every time they're starting a new project? Probably not, reach for their Postgres, right? And so because of that, that's where this is coming from and that's not going to change. And yeah, that ecosystem is going to continue to thrive and there will be lots of different flavors in the growing open source ecosystem. Yeah, I mean, open source absolutely is the underpinning of the bedrock of innovation these days. Gentlemen, great power panel. Thanks so much for bringing your perspectives and best of luck in the future. Thank you, Dave. We'll try to match your backgrounds. Ah yes, next time we'll up our game. Okay, thank you for watching everybody. This is Dave Vellante for theCUBE. Stay tuned for more great coverage of Postgres Vision 21, right back.