Thanks for tuning into EDB’s audio blog series, The Builders, where business and tech thought leaders weigh in on top database industry trends and insights.
In this episode, EDB Cloud CTO Ben Anderson discusses the concept of freedom in the context of database vendors and software, focusing on how organizations can achieve freedom from vendor lock-in, especially in the realm of open source databases like Postgres.
Want to learn more? Check out our on-demand webinar, Postgres: Your Compass for Navigating Hybrid and Multi-Cloud Terrain.
Transcript:
So, I want to talk a little bit about these ideas of freedom. You know, I think EDB, especially, but a lot of other database vendors and vendors in software in general, want to talk about freedom as a positive counter to vendor lock-in, right? In particular, freedom in the context of Postgres, this big popular open-source community. A lot of organizations want to adopt an open-source strategy. We see a lot of folks adopting open-source strategies, whether that's government-mandated, as is happening a lot in the EU, or maybe just good business practices trying to avoid vendor lock-in, and they want to get freedom out of that, right? They want to get the ability to move from one vendor to another. And that makes a lot of sense, right? But in a lot of cases, what we find at EDB, and what I found in previous experience in databases as well, is that this idea of freedom is kind of a layered thing, right?
You might choose to use Postgres, an open-source database that more or less conforms to an ISO standard for SQL, right? You think, "Well, I can take my SQL anywhere. I can take my SQL to another standard database. I can take my SQL to MySQL or some other database that purports to support the ISO standard." And I think most people in 2023 more or less understand that's kind of not true, right? Like, everybody's close to the ISO standard, but there's a lot of variance out there. And so taking an open-source, a very stable, popular open-source database like Postgres that's been around for 30 years, it's going to be around for another 30 years. It's a pretty good bet in terms of having the flexibility to take your applications where you need to take them and have that quote-unquote freedom.
But, you know, there's a lot of variants of Postgres out there. EDB has variants of Postgres, and we have Postgres Advanced Server, which is Postgres, largely Postgres compatible but has some syntactical differences to make it compatible with Oracle. I mean, there's a lot of variance of Postgres out there, but you know, within the hand wave, it's all Postgres.
You can take your applications anywhere. But I think to some extent, that's a bit of a simplistic point of view on the whole problem, right? Because your application, especially in 2023, maybe 30 years ago, this is a bit different, but especially in 2023, your application is not just your app talking to your database and what protocol are they using, right?
Do I need to rewrite the SQL that my application sends to my database to retrieve data when I want to move from one platform to another? That's an element of portability, that's an element of freedom and freedom from vendor lock-in, but it's far from the only element, right?
Building an application in 2023 has a lot more infrastructure, for better or worse, around it that is deeply tied into how your business operates, right? So things like, how do you provision your database, right? How do you, how does it, in let's say, your dev test pipelines, how do you spin up a database to test your application against so that you can validate that your application is operating successfully, you can ship it to production, right? That's part of your application's lifecycle, right? That's a really important part of how you deliver software and how you do business.
And so if you focus only on the transactions between your application and your database, you miss this broader context of how do I deploy my databases? How do I deploy the infrastructure that my databases run on? How do I configure my databases? What configuration is supported from my databases, right?
If you're running Postgres yourself, right? You've got that SQL-level compatibility, you can run that on any cloud. You can run it on-prem. That's more or less gonna solve that problem. And if you're doing it yourself, you're not using a managed vendor, then you can build the orchestration that you need. You can build all of these APIs and things like that that you need to be able to say, "Okay, now my dev test pipeline is gonna spin up a Postgres, now it's gonna upgrade that Postgres because I want to test upgrades, I want to test schema migrations, whatever, right?" But that's a lot of work, right?
And it's 2023 and everybody's going to fully managed cloud services. And if you're buying RDS, right? The way that you need to build your dev test pipeline is coupled to the AWS RDS APIs, right? And there is lock-in, there is a lack of freedom because you've coupled this important part of your business, right? How do I deliver software to production to my customers, to AWS's APIs?
Even though you've got freedom in your transactional interactions through your database, you've lost freedom in terms of how do I actually deploy my applications, right? And this is where multi-cloud comes in, obviously, and people, this is not a new idea. People have been talking about multi-cloud for a long time, but sometimes it's this sort of abstract thing. It's not really a very concrete idea. A lot of folks are sort of saying, "Well, I want that flexibility, but I don't really know why I might want it. It just makes me nervous to be locked into a cloud vendor."
And to be clear, it's very hard, right? The cloud vendors, these platforms are extremely complex. They look very similar from a superficial point of view, but when you get down to it deeply, they are very, very different. It can be expensive to build an application or a database that interacts natively with multiple cloud platforms.
So when we talk about what we're doing at EDB, what we're talking about doing with EDB Big Animal, where we're trying to really build a properly multi-cloud database platform, a lot of that is about giving customers the ability to deploy in a multi-cloud fashion, right? Giving customers the freedom to deploy in a multi-cloud fashion, because yes, it's Postgres, right? And our Postgres is Postgres, and AWS's Postgres is basically Postgres, right? You're going to get that SQL compatibility and the freedom there.
But with an independent vendor like EDB running on an independently managed database service, like Big Animal, you end up getting that freedom for the infrastructure around your application, right? Deploying a database on Big Animal on AWS is the same as deploying a database on Big Animal on Azure, right? Obviously, you need to pick an EBS disk versus an IO2 volume, right? Azure versus AWS, but you're not using a completely different set of APIs. You're not using different authentication mechanisms, right?
The way that your dev test pipelines need to interact with your database platform and deploy a database so that you can get your software out to your customers and you can upgrade that software and so on and so forth is the same if you're on AWS or Azure, right? And that's an important part of freedom. It's an important part of that flexibility, right? This is a really concrete idea of like, I can take my application is not just the SQL that my app uses to communicate with the database. It's a lot of things that surround that, right? It's my pipeline. So it's all of these other bits.
And it's important that those things, for a lot of organizations, it's important for those things that those things are vendor-agnostic, right? That don't result in lock-in. That's where you get freedom, right? And it's not just dev test pipelines, right? I've been using dev test pipelines, it's an example. And that's fine. That makes sense. I think that, you know, a lot of folks concretely understand that. But if you're in a traditional DBA organization, maybe you're in a security organization, the same problem applies to things like, um, configuration governance, right? How do we deploy our databases on multiple clouds in a way that conforms to a standard configuration benchmark like CIS or DISA STIG, right? How do we ensure that when applications are working with databases, they're not drifting configuration away from that benchmark, right? And again, if you're doing this directly with the cloud services, you're going to have to build a bunch of infrastructure independently, right? Just completely different infrastructure. And you're going to have to abstract over the cloud services.
And as somebody who's been building multi-cloud services for a couple of years, I can tell you that's very expensive and a pain to build. Or you can work with a system like Big Animal, a company like EDB where we're doing all that multi-cloud abstraction for you and giving you the same interfaces either way, right? And that's valuable for dev test, it's valuable for build pipelines, it's valuable for things like configuration governance, right? There's a lot of different angles on this.
Now, another angle here, right, that's probably important to address is that not a lot of folks are trying to build, actually build an application that runs both in AWS and Azure at the same time, right? That's not a pattern that we see a lot. It certainly exists, but it's not a pattern that we see a lot of. A lot of what folks are looking for with the freedom is the optionality, right? If I need to, I can migrate from one platform to another at low cost, right?
And so the, there's a bit of, you know, you get into some of these interesting debates about the value of multi-cloud and what is multi-cloud and why do I want multi-cloud? Because a lot of folks are rightfully pointing out that they don't need to be able to do that at the same time. It's just kind of an optionality thing that maybe their boss wants. But there is an important separate angle of this, which is basically that, you know, in a large, every large enterprise is a multi-cloud enterprise, right? There are very, very few big organizations that have picked, say, AWS or have picked Azure, and every business unit in every application is running on that cloud platform. You know, they, they certainly exist. You know, it's not a hundred percent, but most large organizations have got some footprint in AWS, they've got some footprint in Azure, they've got these weirdos that are running in GCP, you know, it's all over the place.
And when you have, again, going back to these governance organizations, things like CISOs, um, DBA organizations, consistency across multiple clouds when they're supporting business units and applications that are deployed in multiple clouds can be really valuable. And we see that a lot with our customers, right? It's not just about the single application, it's about the whole enterprise's cloud strategy. And how do you ensure that you're building a secure, scalable, reliable platform at an enterprise level that you can then build your business on top of, right?
So, that's kind of the freedom thing, right? Um, I think that's a really important part of what we're doing with Big Animal. You know, we talk a lot about Oracle compatibility, we talk a lot about the availability features that we're building with EDB Postgres distributed. Um, and we talk a lot about multi-cloud, right? Multi-cloud is a significant chunk of the value that we're delivering to our customers with Big Animal.
But there's another significant angle here that comes up quite a bit, um, which is, you know, who's, there's another significant angle here that comes up quite a bit around how am I consuming your services? How am I buying the services? Where actually is my database deployed, right? If you're on-prem and you're running your databases, you know exactly what those databases are, right? They're in your data center.
If you're buying from a managed cloud service, um, you're buying from AWS. AWS is provisioning VMs and running those, quote unquote, in your AWS account, right? So you're, you, you see a, you see an RDS instance that has an IP address in a subnet that you've defined inside of VPC that you own, um, that's in your AWS account if you go to, and that, that, that's, you know, a very nice thing about buying. I want to rewind that a little bit.
Um, so I want to go all the way back to the start of the second section, right?
So the end of the multi-cloud bit. Um, so that's kind of multi-cloud, right? We talk a lot about Oracle compatibility, we talk a lot about the availability features that we're delivering with EDB Postgres distributed, and we talk a lot about multi-cloud, right? Those are the really the core values that we're bringing to our customers with, uh, with EDB Big Animal. Um, there's an interesting sort of second-level consideration here, though, that, um, comes into play when we start talking about, well, you are an independent vendor. EDB customer comes to us, say EDB, you're an independent vendor. Um, I don't want to pay you for infrastructure from AWS, right? I've already got committed spend deals with AWS, right? I've got reserved instance management with AWSs, I don't want my data going off to some third-party vendor, right? I don't buy, let's say, you know, you look at how MongoDB works with MongoDB Atlas, right? You're buying database instances. You're buying virtual machines from MongoDB and putting your data in database instances that are managed by MongoDB. And we run into customers on a fairly regular basis that are very concerned about this, right? It's not about our status as EDB, a small vendor, um, nothing like that. It's more a function of I want my data to stay mine. I want it to be in my AWS account.
So when we launched Big Animal, one of the most important things for us was to really respect that and really to support our customer's needs to own their data and to know exactly how their data's being managed. And so we actually deploy Big Animal inside the customer's account, right? So the customer comes to us, they say, I want, I want a managed cloud service. And we say, okay, that's great. Drop this little bit of control plane inside your AWS account so that we can provision EC2 instances on your behalf, and we'll deploy a fully managed cloud service inside your AWS account, right? You can lock us out, you can revoke our privileges if you want to. The data is yours at the end of the day, right? Um, this is running in your account in a meaningful sense. You're paying AWSs for the cloud infrastructure. And for a lot of customers, that's a really big win, right? We've talked to many, many customers. This is, this is not easy, right? It's not easy to build everybody's, these enterprises have very sophisticated controls on how things can be deployed inside their account and all that kind of thing. Um, but for a lot of enterprises, you know, we go and talk to them about where, how they want to control their data and how they want to work with software vendors regarding their data, which is really, in a lot of cases, you know, the lifeblood of their organization, and giving that data to a third-party vendor is just completely out of the question, right? It took them 10 years to get to the point where they would run on an AWS, that second leap to a third-party, whether it's EDB, whether it's Mongo, whether it's Oracle is a big leap for them, right? So they want to keep that data in some meaningful sense for themselves.
And so this "bring your own account" offering from EDB Big Animal is really valuable here for them, right? This really solves a big problem for our customers where they want that. I don't like to use the word control, but like, they want that control. They, they want, they want the feeling of the ownership of the data. The data doesn't leave their account. They understand what infrastructure is being provisioned, but they still get a fully managed database service in the sense that, you know, they're not provisioning VMs manually, you know, they're using APIs. We are providing an SLA for the uptime, that service, right? Um, that's the thing that we've had in the market for our Big Animal for quite a while.
It's something that we're continuing to evolve and continuing to refine and support our customers in these really sophisticated environments where we would say, well, this is what our networking topology looks like, for example. And we have to go and figure out, okay, how is Big Animal gonna work in that environment? It's an interesting challenge for us at, you know, at purely technical bakery level, right? Um, but at a business level, it really does solve our customer's problems. However, it doesn't necessarily solve all of our customer's problems and solve our customer's just they don't wanna deal with it, right? Customers, I want to get started today. I don't want you to have any visibility into my cloud account. I just want you to host my data, right? This is just something I want to get started right now. I want you to host my data. I don't want to deal with, you know, I don't want to deal with sort of figuring out how to get you running in my cloud account because admittedly, it is a more complicated engagement, right? It's really valuable for a lot of organizations, but it's a bit more complicated engagement.
Look, some customers want to go to production in a fully Big Animal managed context. Big Animal pays AWS for the infrastructure, customer pays Big Animal for the infrastructure, and we're all off and running, right? Um, so to that end, very soon we're going to be launching fully EDB-hosted Big Animal.