Enterprise Databases in the Cloud

Welcome to the KuppingerCole Analyst Chat. I'm your host. My name is Matthias Reinwarth. I'm an analyst and advisor at KuppingerCole Analysts. In each edition, I have one guest joining me, often a fellow analyst or another interesting partner, and we have a 15 minutes chat around an interesting topic, my guest today, and I'm very happy to have him here again is Alexei Balaganski.

Hello, Matthias. Usually I have you, when it comes to security topics and cyber security today, we are talking about something a bit different. Our topic today is enterprise databases in the cloud. And as we are both already for quite some time in the market, and I think back say some 25 years or so, and enterprise databases were products that were relational databases. They were expensive. They were maintained on premises. Of course. And there were names like Informix, Sybase, Oracle. What has changed since then? What our enterprise database in the cloud?

Well, you're right. You mentioned so many names and some of them of course are no longer with us at all. Some still survive or some are looking to reinvent themselves completely to kind of match current completely changed expectations from businesses. But I guess the biggest problem with that phrase, enterprise database in the cloud, everything is new. The enterprises have changed, but the notion of database has changed completely.

And of course we have the cloud with a totally different, if not very new, any more, but still a completely different way to store or to manage, to process your data. And the biggest challenge, I guess, that we are living in a world so different from what it used to be 25 years ago, that old school monolithic relational database management system, it just, it's no longer relevant.

And again, some companies have not survived has changed. We are no longer on the market. The others still are and doing quite well. And we'll probably be talking about specific names later, but the point of that are from the customer perspective, from the enterprise perspective, the database is no longer just a specific product for storing a specific frigidly defined relational data database. Nowadays can mean a lot of things. You now have no SQL. You have Kraft databases. We have document databases. We have time series databases, real time data stores for IOT purposes.

We have data warehouses and other big data frameworks. We have data lakes, you name it. And from the technology experts perspective, those are two completely different and often completely unrelated solutions.

However, from the business perspective, this is still a database and for any sufficiently large and sufficiently modern project beat or a new application, or just migration of a legacy system to the cloud, it will almost surely never rely on a single type of data based solution anymore. So you will now be able to just build your modern application infrastructure. Let's say only on a relational database or only on a specific type of database solution. This is why we are currently planning or currently working on our leadership compass for this topic.

And we will be looking from a completely different, less technological, more business relevant perspective on this solutions. Does that mean that, that you choose the database based on the actual problem that you want to solve on the type of data that you want to store? Yes and no. You now have so many different choices of a potential database to implement in your product, or even more than one database that it became much more strategically important.

I won't even say critical for the success of your long-term project to do the right choice in the beginning, because one of the major problems or of any data management solution in the cloud is a potential vendor. Lock-in if you make a mistake, if you choose a solution which somehow limits your scalability, or doesn't give you a specific functionality your need, and you know, that different database will work for you, but you are, I've already invested so much in our proprietary protocols or interfaces that you just cannot go back without undoing all that long term development.

And in order to avoid these costly mistakes, you really have to approach alert choice of your potential database, much more strategically. Nowadays, I've learned earlier that that a typical reason for vendor lock-in are stored procedures that you have code within databases, which is not portable at all while everything else from the data model could be portable.

It's something like that still around, I would say yes, but this is not kind of the level of challenges we are talking about because even if you have the same database engine on premise, but you migrate to the same database in the cloud for you are fine because he will just take your existing code and procedures and so on and lift and shift it to the cloud. And you're fine in that regard, when you're talking about proprietary interfaces, we are talking about proprietary, let's say SQL extensions when they are, of course still a challenge.

And if you want to migrate, let's say from Oracle to Microsoft SQL server, yeah, that's still a problem for your developers. But if you want to migrate from, let's say Azure cloud to Oracle cloud, it's a totally different level of challenge. If you will, you might still run Oracle in Azure cloud or Amazon cloud. In that regard, you are not limited to a proprietary interface because that hope is still the same Oracle interface, regardless of the cloud.

However, if for example, you want to migrate to the whole range of database services offered natively by a specific cloud provider, then you are facing a totally different challenge. For example, we know that in Azure cloud, you basically have a choice of quote unquote standard databases, which are running on prem, just as fine. And of course you have a number of specifically designed cloud native database interfaces. If you are looking at AWS, for example, and most of those database services would be cloud native, supporting their own proprietary interfaces.

If I am not mistaken, currently you have a choice of over 15 database engines from AWS cloud. Do you want your developers to learn 15 new database interfaces to the one? Even if that one is a really old school and proprietary, that's a tough choice to make. But if I think for about the, say the Recent press say five years back from now, and we look at the, at the promises that graph databases came along with that, of course they talk SQL. They talk traditional interfaces, but they play out their strengths when it comes to using the actual paradigm.

That's behind that the graph approach and the, and the traversal of complex graphs that often requires there, the developer to really change the way that they're thinking, don't they, In a sense you are. And if you are looking toward in the right direction, if I may say so.

So yes, the point of that, when you are thinking about a migration project, if you have a legacy on prem application on a legacy on-prem database, and you want to make something exciting in you and cloud native and massively scalable and geographically distributed. And so on, of course, or your old school database, you'll no longer be physically capable to dealing with it. Even if you just lift and shift your whole application infrastructure, including your database to the cloud, which is perfectly fine for some scenarios.

And if you will still work fine, it will probably even work faster than on-prem and it will be cheaper to operate, but it will be just that lift and shift it. Won't give you all those new, fantastic capabilities of the cloud. As soon as you are starting to evaluate those new, fantastic capabilities, you'll have this, I would even say almost religious kind of choice.

Do you want to go for a large combination of best of breed individual services, and quickly end up with an application infrastructure, which requires 15 different databases, but that will be the fastest and the smoothest type of database. And it will be the most secure and scalable blockchain. It will be the fastest and the cheapest data lake, but two will be a mess of a dozen of different application stacks and interfaces.

Or do you want something which is, let's say, quote, unquote, good enough, but we'll give you a single set of interfaces, a set of tools, which the developers are already knowledgeable with. And of course it will give you the opportunity to query all your data from a single source. Instead of juggling, let's say some data from a relational database, with some graph data and some files from a data lake, then you will have to run an additional level of obstruction just to make a query across all three sources. That's this, this is this fine balance or for which there is no single right answer.

It depends only on your projects, requirements and timescale and budgets and skills. And so many other factors, Some, some databases that I've seen in the cloud come with a promise of being multimodal so that they are graph and they are relational, or at least they mimic this functionality and even more key, key value pairs and all this kind of stuff. Do they deliver on that promise?

Well, I guess some probably do some others might be not yet. If you have a choice between like a large numbers to enter like Oracle, for example, on the one hand and here they are database, is it promises to be multimodal and deliver that single queering capability across different data models, which at least on paper sounds extremely interesting to a developer, but of course an Oracle database is still a monolithic piece of software. You cannot run it across, or you cannot build a database which would seamlessly span different cloud regions.

And of course, if you, if this is something that you're looking for with probably be looking for some cloud native solutions like new or DB, for example, or if you are okay with our no SQL approach or Mongo DB, these are our, the specifically designed for how to grow across multiple clouds, for example. And then again, you are, you have to either learn a new set of interfaces or you have to rely on those or connect to conspirators or emulation layers because some of those modern databases come for example, like an Oracle emulation.

Okay, got It. Maybe for the, for the final minutes of this episode, let's shift the focus towards a feature that KuppingerCole is really always very much interested in that's compliance, that's governance, that's security and data protection. The more organizations are moving critical data into enterprise databases in the cloud. The more they will require data protection and cryption data hiding all mechanisms that make sure that access to this information. It's really only granted to those who should have, how is the market here?

Is, are they capable of protecting strongly this data in the cloud? Well, this is first of all, something which cannot be solved with one single approach. Actually last year, we have released a leadership competency specifically focusing on database and big data security solutions. And as we can see, there is also this agony of choice.

If you will, you can rely on built in security controls of a specific database, which of course have a massive advantage of being within the database course, or they are faster, more reliable, sometimes even more secure because they have access to intimate internals of the database engine. On the other hand, those have a major flaw if they are not vendor agnostic.

So as soon as your project involves more than one database, I will have to install more than one database security solution, or you have to look for additional alternative approaches that for example, focused on securing the information and not the database. And again, there are some really interesting aspects of that information centric, data centric, security, which you could probably discuss in this episode, if there is one take away from this one with regards to database security, that database security in the cloud is not something which comes free with your cloud contract.

So yes, the cloud provider will secure the infrastructure. Your database is running on. Sometimes there will be one encrypt your data in the database, but it's still your own responsibility. If something breaks, if the data is leaked because of that, this is how the shared responsibility model for the cloud works. So if you store your data, you know, insecure S3 bucket on AWS and it leaks, you know, you are responsible, not AWS, for example, the same applies to any kind of database in the cloud. Okay.

As we're getting to the end of this episode, what I've taken away is that people interested in more details around that topic should be carefully waiting for the leadership compass. That's upcoming about enterprise database and the cloud. In the meantime, they should pick up the leadership compass for data security that you just mentioned, database security and big data security. That was something that they should look into. And I know that you have already executed a set of webinars around that topic with, with various vendors, which they could also have a look at at our site.

Anything else that you would recommend where people can learn more than we could convey in just say 15 minutes? Well, first of all, I have to add to all the list. You already mentioned that the data security in the cloud is impossible without securing the cloud itself. So I think we have quite a lot of research published on cloud provider selection and assurance what to look for in a specific cloud service provider when you are signing the contract with them. And of course, security and compliance is a huge aspect of that.

And I'm sure that we have all those major providers cameras in our research already. And of course we are always open to specific questions and we are ready to support you in any future products. Okay. I think I will. The latest invite. You look for that topic again, when the leadership compass is published so that we can dig into more details here for the time being, thank you very much Alexei for being here with me again, some final words from your side.

Well, thanks again for having me. So to say, definitely looking forward to discuss some of these topics in more details, of course, looking forward to, to do this in a more visual form, like a webinar or a physical event, or when this whole crisis is over or stay safe, stay healthy and looking forward to meeting all our attendees sometime in the future In real life. Okay. Thank you very much, Alexei, thanks to the audience for their time. And I hope that was valuable to them, bye.