Database access is critical when developing applications. But traditional approaches to providing access typically take too long for today’s fast-paced development environments. And in most cases, the constant stream for access credentials is burdensome and time-consuming, straining ITOps and database admin staff. Developers often take matters into their own hands, sharing credentials with colleagues. That is a security and management nightmare.
What’s needed is a way to simplify and standardize how teams provision, monitor, and connect to cloud-hosted partner database services. RTInsights recently sat down with Red Hat’s Michelle DiPalma, Principal Architect, Cloud Services, to talk about the challenges of database access in modern development situations, how these issues impact different groups (e.g., developers, ITOps, and DB administrators), and how Red Hat OpenShift Database Access (RHODA) can help. Here is a summary of our conversation.
RTInsights: Developers need database access for Kubernetes workloads throughout an application’s lifecycle. Why is this such a problem in organizations today?
DiPalma: Many, if not all, organizations are accessing databases already from within Kubernetes. But at the enterprise scale, there’s still a lot of toil involved. Specifically, from a developer’s point of view, toil would be, “what team do I contact for credentials? How are these credentials going to be passed to me? And is this going to be different for every different type of database? ” That’s the developer’s point of view. It would be ideal to offer developers an in-cluster solution that’s not about logging tickets with IT.
RTInsights: These issues go beyond the developers. Why should ITOps and DB administrators care about offering a simpler way to address this developer problem?
DiPalma: There is also toil, toil, toil on the ITOPS and DB admin side. They are responsible for this information. It is a primary responsibility of their job.
If you’re an IT administrator figuring out, “Is this request reasonable?” Who’s it coming from? What other information do I need to know? Are there other approvals I need to get?” There’s a whole process involved in a large enterprise around databases, specifically “Am I allowed to give this information out? What if this information changes?” Removing that back and forth or making that process streamlined would be ideal for ITOps and database administrators.
The ITOps people and database administrators are the ones that require visibility and governance. Even more so than the developers. I would even say developers care less about that part because they just want access to be easy.
But on the administrative side, you are responsible for the information, securing the surrounding access, and having visibility about where that information is going and who’s using it. You need the ability to revoke access. Those kinds of things are of the utmost importance to you.
Having a process or a way to make the toil easier will always reduce error and risk. I’m not cutting and pasting credentials anywhere. I’m not sending them to you in Slack. There is a process, and it is well defined. I put the information in there once. The developer comes and accesses it, and the human error is gone.
RTInsights: What do each group (app developers, ITOps, and DB Admins) need in a solution?
DiPalma: Starting with the developers, they want it to be easy. They need speed. They want it to be a no-brainer. A developer wants to be able to say, I’m starting a new application, and I’m developing it with my team. I know what databases I need to access. They want it to be consistent. If you’re changing vendors or have a different instance, you don’t want to go through a different path to get that information. You want it to be the same. All of that leads back to it being ease of use and speed. That’s the developer’s point of view.
Again, from the ITOps and DB admin view, you’re talking about visibility. Knowing who’s got what, where. These groups need governance. They need to control the groups that get access. They also need consistency as well on their side.
RTInsights: What is Red Hat OpenShift Database Access (RHODA)?
DiPalma: Red Hat OpenShift Database Access is a cloud service that simplifies how teams connect their apps to cloud-hosted partner databases. Across all clusters and clouds.
When I’m talking to people trying to explain what RHODA is, I use an analogy. It’s like an address book on your phone for database access. RHODA contains the information about accessing what you want, but it’s not the database itself. Just like on your phone, your address or contacts app isn’t how you call people. It isn’t how you email people. It isn’t how you text people. But your address book or contact app has all that information there. You can SMS them or Facebook Messenger them. When you use your contact app properly, all fields are filled in, and you just select it. Then it pops up the app, and off you go. So, in a way, RHODA is like your contact app inside your cluster for database access.
RTInsights: Does this mean Red Hat is becoming a database company?
DiPalma: Heavens no. This is about access, not about running the instance. We rely on our partners for the database service offerings and just want to make access easier.
RTInsights: What databases does Red Hat OpenShift Database Access support?
DiPalma: Currently, we support access to Amazon Relational Database Service (Amazon RDS), MongoDB Atlas, CockroachDB, and Crunchy Bridge.
Red Hat OpenShift Dedicated or Red Hat OpenShift Service on AWS users can access RHODA from the Red Hat hybrid cloud console using this link: red.ht/dbaccess.
Salvatore Salamone is a physicist by training who has been writing about science and information technology for more than 30 years. During that time, he has been a senior or executive editor at many industry-leading publications including High Technology, Network World, Byte Magazine, Data Communications, LAN Times, InternetWeek, Bio-IT World, and Lightwave, The Journal of Fiber Optics. He also is the author of three business technology books.
