Bart Farrell: first things first, who are you? What's your role? And where do you work?
Paul Parkinson: My name is Paul Parkinson. I've been at Oracle for 25 years. And the first 20 years were core development. And then the last five or six or so, developer advocacy. Reaching out to developers because I've been doing it for 40 some years.
Bart Farrell: You've been busy. That's good. You've been productive. We're gonna be looking at Kubernetes in highly regulated environments. In regulated systems, where should responsibility sit between Kubernetes recovery mechanisms and application database level transactional guarantees?
Paul Parkinson: Many things go into that, even when you say regulated environments, I think of data sovereignty and things like that as far as making sure you have a database with sharding across different regions. But with so many things, the more you can reduce the surface level and actually have that regulation at the database. It's not spread. When I say surface level, people think of security, but for regulation and everything else, if it can be more contained at the database, then there's less concern. You see any of the big companies, finance comes to mind, for mission-critical systems. That's the way they'll set up their architecture from the Amex and PayPal of the world that we work with. It sounds like a very general concept, but it applies to the sharding of the data, the security, the HA, keeping it localized as much as possible to the database.
Bart Farrell: How should teams design around retries and failover when repeating an operation can be more dangerous than losing the plot?
Paul Parkinson: This is a fantastic question that you came up with, but it's so spot on because, especially with agents and the agency that these agents have, my background for these 30-some years is in transaction processing. This is exactly the retries you mentioned. Transactionality in the communication layer, as well as the database. Again, everything's in the database. For retries, imagine the agents that we have now, no one's under any illusion that these are AI microservices. These are microservices, these agents. AI lends so much more to them. That's unique. But with microservices. The evolution there was, okay, we have all these circuit breaker and retry patterns, and you put a service mesh in front of it. But we really saw that, as has been the case since the 70s, that messaging has these mechanisms where you don't need to do that, where the system can queue requests, the work is done transactionally, things like that. What we're seeing is the exact same thing with agents. And if agents have control over the retries. That's trouble. That comes back. In other words, this communication layer, having transactions with the messaging so that the messaging and the data, which is something that's unique to the Oracle database, this was actually in DB2 a while back, but Oracle is like the only database that does that. Anyway, some mechanism where you're not relying on the agent to do these retries. Because as we give more and more power to AI, just as you say, you can't transfer things twice. And if it's coming up with it, it's going to find a way. This retry logic is very important. Having something in place like that and all of these agentic systems now are moving to messaging as well because of that reason. That's one of the main reasons for these retries. Great question. We see it every day, especially in finance and these critical systems.
Bart Farrell: And Paul, what separates a stateful Kubernetes workload that is merely highly available from one you would actually trust in a banking environment?
Paul Parkinson: High availability is important for reliability. Security is at the top of everyone's list in AI now. There are a number of different features or a number of different aspects, but I would say security is so far on top of all of them that even if the system is HA, if it's not secure, then it doesn't matter. Once again, if you have that security, reduce the surface area and have it contained at the database level. And you have things where it's extremely fine-grained and you're really locking down these agents. At all levels, this is a full stack concern because the data is the most important aspect in the database and very fine-grained access like cell-level access is required. It can't be open because the agents will find a way if you're allowing table access. That's not going to do it. If you're allowing row access, that's still not enough. It has to be cell-level. When these agents come in, they only have access to this very small amount. And the connection to the database should have no privileges. That should be flowed in from an identity provider. And those roles come in, and then you have cell-level protection there. It's a full stack concern. Even when agents talk to other agents, you need this identity flowing. And then on the front end, you can't just be generating or writing text: transfer the money. You need this governance all the way up to the UI. The UI has an actual form for transferring, et cetera.
Bart Farrell: We're talking about the use of agents in Kubernetes. What are things that you would be comfortable handing over to an agent? What are things you would say absolutely not?
Paul Parkinson: Yes, exactly. It is from the bottom up. The bank transfer straight line. No one is using agents for bank transfers. It's interesting because of different languages as well. A lot of these apps are written in Java. A lot of the agents are written in Python. That is always the weird area with that. Certain languages. Well, it's AI. You just vibe code it, but Java is still used for these bank transfers. Python is used for the agents like chatbots and things like that and coordination. I just mentioned that to give a full picture. But you can still see, slowly moving up away from the database, or I should say the other way around slowly to the database. Keeping those systems that are doing bank transfers should not be changed for a while. Using things like MCP servers, a lot of the financial customers we have, those MCP servers, we have something called an MCP toolkit, for example, that is exact SQL statements of what is used today. But then you're saying the agent can say what's the most appropriate one. You're not having, for example, an MCP saying, come up with a bank transfer statement for me, that's not a pretty clean line there, because it's stepping into that zone where you're giving it the agency to say what's the most appropriate based on what this user is trying to do. But you have it locked as far as what it's doing. The user's identity is passed into the database. Even if you pick the wrong SQL, it's not going to execute something that's dangerous in the database. I think it'll be iterative and incremental like anything else. They'll start to slowly move closer to the database. But again, I keep coming back to that full stack concern because that's not to suggest that, let your generating at the top of the stack for the UI is a safe thing, because that's just important as far as locking in values that are allowed and things like that. It's just that incremental. Let's go slow, people. The human in the loop and everything else at the key points. Exactly.
Bart Farrell: Very well said. Perfect. Paul, thanks so much for sharing your time and experience with us today. I look forward to speaking to you again soon. Take care.
Paul Parkinson: Absolutely. Pleasure. Thank you.
