George Goh, Executive Director at OCBC, explains how Singapore's second-largest bank migrated thousands of microservices and monolithic applications across multi-region in just six hours with zero data loss. Learn how OCBC built a resilient, future-ready architecture that balances strict regulatory requirements with high-performance developer experience with Confluent’s data streaming platform.
Migrating an entire bank's infrastructure without losing a single transaction sounds impossible. Yet, OCBC successfully modernized their event-driven architecture across Singapore, Malaysia, and Hong Kong with zero data loss.
In this episode, George Goh (Executive Director at OCBC) joins Joseph Morais and Sami Amed (Staff Solutions Engineer at Confluent) to pull back the curtain on a massive data streaming migration, how the team executed a flawless migration of thousands of producers and consumers in a single weekend.
George discusses how OCBC built a resilient, multi-region data streaming platform that maintains performance even during data center failures, all while meeting strict regulatory requirements in one of the world's top financial hubs.
You'll Learn:
From capacity planning for disaster recovery to developer experience improvements, this conversation reveals the architectural decisions, operational discipline, and partnership that made zero data loss possible at enterprise scale.
About the Guest:
George Goh leads the Cloud Middleware Engineering and Services team at OCBC Group, which provides OpenShift, Apache Kafka®, and Redis across all locations where the bank operates. Previously serving senior services and consulting roles at Red Hat and VMware, he now relishes the added challenge of defining technologies within the bank and building talented teams to run them.
Guest Highlights:
"We moved thousands of microservices over from the old platform to the new platform over the course of maybe 12 hours over a weekend. We got Singapore, Malaysia, Hong Kong, everybody on board and moved at the same time with zero data loss."
"It was done in six hours, but it took six months to plan."
"I was focused on a three letter word, BIM—benchmarks, integration and migration. I was saying that three times a day, three days a week until everybody knew what I was talking about."
Chapters:
[01:41] Why Singapore Is a Global Finance Hub
[03:47] Data Streaming Goodness
[05:09] Building a Resilient Multi-Site Architecture
[06:59] The Reality of Migration Planning
[09:49] Capacity Benchmarks & Day Two Operations
[12:33] The Shift from Buy to Build
[19:20] Scaling Adoption Across the Organization
[21:50] Beyond the Stream
[25:43] The Impact: Thousands Migrated Overnight
[28:00] Best Practices & High Availability
[30:58] Future Vision: Less Overhead, More Innovation
[33:37] Quick Bytes
[35:24] Joseph’s Top 3 Takeaways
Dive Deeper into Data Streaming:
Links & Resources:
Our Sponsor:
Your data shouldn’t be a problem to manage. It should be your superpower. The Confluent data streaming platform transforms organizations with trustworthy, real-time data that seamlessly spans your entire environment and powers innovation across every use case. Create smarter, deploy faster, and maximize efficiency with a true data streaming platform from the pioneers in data streaming. Learn more at confluent.io.
[00:00:00] George: We moved thousands of microservices over from the old platform to the new platform. We've got Singapore, Malaysia, Hong Kong, everybody on board, and moved at the same time with zero data loss. And not just microservices — it was batch jobs and monolithic applications as well, all on the same night.
It was done in six hours, but it took six months to plan.
[00:00:27] Joseph: That's George Goh of OCBC, Singapore's [00:00:30] second-largest financial services group. And joining him is Sami Ahmed, a staff solutions engineer here at Confluent. In this episode, they share how OCBC modernized its architecture to decouple microservices, integrate legacy systems, and meet strict zero data loss requirements.
With Confluent as a key partner, the bank built a future-ready platform grounded in one mantra: monitor, monitor, monitor. I'm Joseph Morais, your host and technical champion at Confluent. Let's get started. [00:01:00]
Thank you for coming on the show, George, and you too, Sami. Let's jump right into it. Tell me about OCBC, the Oversea-Chinese Banking Corporation, and what you and your team specifically do at OCBC.
[00:01:19] George: Well, thanks for having me on the show, Joseph. My name's George, and I'm an executive director at OCBC Group.
I lead a team of engineers who provide always-on services for [00:01:30] OpenShift, Kafka, and Redis to the bank.
[00:01:34] Joseph: So you just happen to be our first ever guest from Singapore, so I welcome you from literally the other side of the world. Can you tell us about the importance of financial services in Singapore and your part of the world?
[00:01:47] George: So it's an honor to be the first, and I certainly hope I won't be the last. Maybe a bit of background, right? Singapore is a relatively young nation, founded 60 years [00:02:00] ago. We evolved from an economy that was largely shipping and manufacturing in our early days, and, in the last 20 years or so, to include tech and finance.
Today we're recognized as one of the top financial hubs in the world, and roughly 5% of the country's workforce is in the banking and financial services sector. That contributes about, say, 12% to our [00:02:30] GDP.
[00:02:31] Joseph: That is a really staggering number, right? If you think about it, just 60 years of this current incarnation, and then to do that pivot and to be such a large part of the financial community in such a short time — very impressive.
You should pat yourself on the back. I would do it for you if I could, but my arms are not that long. Now, can you describe to me a typical OCBC customer?
[00:02:55] George: Well, there is probably [00:03:00] no such thing as a really typical OCBC customer. It's the longest established Singapore bank. It's formed in 1932 from the merger of three local banks.
So if you take a step back, the OCBC Group offers coverage across ASEAN, which is an association of Southeast Asian countries, and Greater China. It's got over 400 branches and representative offices in 19 countries and regions across the world. We [00:03:30] offer a suite of services from banking, wealth, and insurance.
So it's hard to pinpoint a typical customer. Yeah.
[00:03:38] Joseph: Right. So it sounds like almost anybody in Asia that has some type of financial need could be one of your customers.
[00:03:44] George: Yeah. Yeah. That's right.
[00:03:46] Joseph: Perfect.
We set the stage, so let's dive deeper into the heart of your [00:04:00] data streaming journey in our first segment. So tell me, what have you currently built or building with data streaming?
[00:04:07] George: We've got to start with what the bank is trying to build.
[00:04:11] Joseph: Okay.
[00:04:12] George: So we adopted the microservice architecture way back in 2017, 2018.
And of course, with the adoption of that architecture, it meant that applications were built to reduce coupling in the [00:04:30] implementation. So with reduced coupling, there had to be an event hub in the middle, right, for both microservices and non-microservices to integrate at scale. So an example of this is where our analytics platform, it subscribes to topics in other applications to understand customer behavior and detect fraud as well. [00:05:00]
[00:05:00] Joseph: So that's a classic data streaming use case, right? The decoupling or the loose coupling of microservices or applications. But I know you are at the scale of a bank. So tell me a bit more about your cluster availability. What happens if there's a disaster? Have you built an architecture that is resilient to that?
[00:05:20] George: The bank as a whole has two live sites in country, in Singapore. And we do have a third planned. [00:05:30] But the target design for all our components, including our streaming hub, our event hub, is, like you said, to ensure access, to ensure continuity of operations. Our target is no reduction to performance, even if disaster strikes.
So with that, we've got to have a few design thinking there, right? So with the help of Confluent, with many conversations with Sami — [00:06:00] thanks, Sami — we had to get around some of the constraints, right? Two sites today versus things like three sites that are required for a true ZooKeeper quorum, right?
That's one instance. So I could rattle off many, many design constraints and how we overcome them, but generally speaking, our overarching goal was, like I said earlier, to make [00:06:30] sure that we were always available, running at the performance where our customers would not notice that something had gone wrong, even if it did.
[00:06:40] Joseph: Right. I think it's important to figure out those requirements and then work backwards from there. And Sami, thank you for joining in the conversation. So maybe you can kind of peel back a little bit of that. So there's clearly a multi-region type of setup. It sounds like two hot data centers and then a third data center for observability.
Do I have that correct?
[00:06:58] Sami: Yeah. So [00:07:00] I guess I'll give a little bit of background, because George was just kind enough to call out the collaboration, which has been great. I guess it was back in May 2024 or so that we embarked on this. So George and I have been working on this for close to two years now, and setting up this streaming data infrastructure with him has been fantastic.
Being part of his extended team has been extremely enjoyable and eye-opening as somebody coming from another financial hub in the [00:07:30] US. I'm a relatively newcomer to APAC and all these unique regulatory requirements they have. So the risk guidelines and things that George has to actually function within, I think, make what he stood up all the more impressive, because there is a lot of regulations out here.
So yeah, when it came to establishing the Confluent cluster, I think the first thing we did was actually try to map out all the application landscape. So I remember coming into the office with George. We sat down with the application [00:08:00] teams, and naively, I remember saying, "Okay, show me all your producers and consumers, and we'll just move everything over. It'll be very seamless to do so, right?" And it's a large bank, like George was just saying. They serve all these different customers, all these different geos. It's impossible to do that, right? There's some monolithic stuff.
There's some newer, modern apps. So it just didn't make sense to take that approach. So what we ended up doing is [00:08:30] really just looking at how their applications work today, looking at things like Ranger policies, and looking to migrate those identities to Confluent as gracefully as possible.
That's what we were looking at on the application side. And then as far as the cluster side of the house goes, the main technical motivation was resiliency in case of a data center failure. So as George was saying, we have basically two sites to work with in one geo and then one site in another country. [00:09:00] And so what we did is stretched a Confluent cluster across the two data centers in one geo.
So if one of those data centers fails in that geo, we're okay — apps can continue reading and writing in that scenario. And then the DR was spun up in that completely separate geography as a failover destination in case prod was completely down. So that's what we ended up standing up, and
there's definitely future plans that I hope we get to discuss today as well. [00:09:30] But yeah, that's quickly on the current state and a bit about the migration there.
[00:09:34] Joseph: That's great. And I love that your partnership started around the same time you moved to that part of the country. Confluent wasn't new for you, but that part of the country was new, and you got to partner with George. I can't imagine a better scenario for you, Sami. So I'm curious, with this lofty goal of having this availability and the service level not dropping, even in the event of a data center failure, how are [00:10:00] you handling cluster capacity?
How does OCBC's environment ensure that the resourcing is appropriate to even satisfy all of those customers in a loss of a data center?
[00:10:10] George: We had the benefit of hindsight. So we knew the types of volumes and patterns that we were getting at that point of time. Then it was a matter of finding that capacity —
[00:10:24] Joseph: Mm-hmm.
[00:10:24] George: — and addressing the types of failure scenarios that we were gonna talk about. [00:10:30] So once we've identified the capacity, the failure scenarios, then it was a matter of benchmarking. Benchmarking not just how fast things would go, how many clients would run, but also at the same time benchmarking how fast we could recover from failures in event that something unexpected happens.
So we had a lot of time dedicated to designing these [00:11:00] failure scenarios, to designing these benchmarks, to make sure that things were really ready and ready to go on day one when we flipped the switch.
[00:11:11] Joseph: Hmm. That's very interesting. Yeah, your capacity management has to go beyond just how is things working in an ideal scenario?
It's do we have the capacity to fail over, and do we have the capacity to quickly fail back? So it's a very interesting challenge. I'm glad that we were able to help you solve it.
[00:11:28] George: I just want to add to that, sorry.
[00:11:29] Joseph: Oh yeah, [00:11:30] please. By all means.
[00:11:30] George: That's day zero. Day one, day two, we've got to get the monitoring in place to ensure that what's great today continues to be adequate or even great for tomorrow.
So having that monitoring to make sure that we're always under that threshold. And if we are touching or go beyond that threshold, to quickly respond and to provision additional capacity [00:12:00] to make sure that we're always ready for the unexpected.
[00:12:04] Joseph: No, I really appreciate that. I have an operations background.
A lot of people are very good at architecting for today, right? But they don't necessarily have the guardrails or the monitoring in place to ensure that they're okay into the future, which is what you guys did here, and I'm very impressed by that, 'cause it's very important to have that day-two thought process in mind, because otherwise you're like, "Hey, we got it done.
I'm gonna go home. I'm not gonna think about this anymore." [00:12:30] And that's how we burn ourselves in a couple years. I think we've all been there. So walk me through how you thought about addressing the need to modernize various applications and integrating multiple data centers. So what I'm really asking you is, was there a specific shift or something that happened in the organization that said now is the time to modernize?
[00:12:49] George: So that's going back to the 2017 days, where the bank was to move to a modern architecture.
[00:12:58] Joseph: Okay.
[00:12:58] George: It was [00:13:00] really a move from buy to build. We didn't want to rely on vendors to build our software for us. We wanted to build it ourselves, have that control in our hands. And that meant looking at everything from the ground up and building things in a way that we could build and run it ourselves.
[00:13:27] Joseph: Now, going back to 2017, [00:13:30] and I know you had another system running eventually, and we'll talk about that in just a moment. Do you remember what led to specifically, "Hey, we're gonna modernize. We know we have to do that, and we want to do it ourselves"? But what caused you to choose data streaming as the correct architecture for modernization?
[00:13:47] George: That was part of the entire software and application architecture, right? When we moved from a monolithic application design to a microservices-based [00:14:00] architecture, then naturally something has to be the glue in the middle. And the data streaming, Kafka platform naturally came into play, along with some other pieces of modern infrastructure like container platforms, like caching and so on.
[00:14:19] Joseph: Got you. So you were just looking at how are people doing this the right way in 2017? Microservices, decoupling — that was all the trend. It led you to data streaming. That makes perfect sense.
[00:14:29] Sami: Yeah. I wanted to [00:14:30] just give maybe, like, another layer of insight on that one too. So George's team, right, they own... He runs a lot of different services at the team in the middleware kind of stack area. And the team is very well-versed in Kafka, and they were using Kafka before Confluent. But I think something that came up in the whiteboarding sessions and architecture sessions we were having before they went to production is details around things that are [00:15:00] specific to Confluent's ability to do things like observer replicas.
So I remember we spent a long time on, like, okay, we have this new regulatory guidance to create this stretched architecture, this stretched cluster, but what about things like latency? Like, how long will it take for the replicas to get the data? All that kind of stuff. These observers that Confluent provided to OCBC was really helpful because they stay out of that in-sync replica set.
They don't impact the latency of replication across their [00:15:30] sites. So those details, I think, actually — and maybe, George, I don't want to put words in your mouth — but I think those kinds of technical advantages are what helped them make that move over to Confluent and inevitably deploy that stretched cluster.
[00:15:44] George: Yeah. Sami, you remember so many things I forgot. So of course, with 2DC topology, we've got challenges, right? ZooKeeper needs three for quorum. So we went [00:16:00] with a hierarchical quorum for ZooKeeper. Again, not the most ideal. I mean, going through community, going through forums, that's not the most ideal way, but —
[00:16:16] Joseph: Right.
[00:16:17] George: Being pragmatic and knowing what we have today and designing for that today, that's what we've got to do, right?
Instead of waiting for tomorrow. A third DC is not gonna spring up tomorrow. So we [00:16:30] design for it today with the knowledge that we have and the control we have, not only over Kafka, but also around the ecosystem, the virtualization layer below. We would control situations where we see problems.
For example, in the case of if we had to bring up a data center, there could be a case of split-brain scenarios for hierarchical [00:17:00] ZooKeeper in a 2DC case. So knowing what we know and having the control that we have, we made some custom hooks in the virtualization layer to make sure that that split-brain scenario would never happen.
[00:17:20] Joseph: Right.
[00:17:20] George: As much as it could help it, right?
[00:17:22] Joseph: Mm-hmm.
[00:17:22] George: And the other thing that comes to mind is the Confluent platform gave us the [00:17:30] ability to define everything as code —
[00:17:33] Joseph: Ah,
[00:17:33] George: yes — through Ansible playbooks. So far in this conversation, we talked about one cluster, but we've got many, many clusters today. We've got clusters in Hong Kong as well.
So being able to define our design, our architecture in one place, and have it cookie-cutter in [00:18:00] multiple places, and having it in version control, is a very powerful tool to have, especially when you've got teams as small as mine.
[00:18:08] Joseph: Mm. Absolutely.
[00:18:08] George: Right?
[00:18:09] Joseph: Mm-hmm. Yeah. So I was gonna ask, ultimately, what led you to choose Confluent over the system that you were running, but it sounds like I think I got it, right?
So you had this requirement to have this basically bulletproof cluster. There were portions of Confluent platform that made that better with the way we do [00:18:30] observability. And then also, because you were already all in on Kubernetes, you wanted to — in a similar way you would manage your pods and your microservices on Kubernetes — you wanted to manage your clusters the same way, and we have something here called Confluent for Kubernetes that makes it brick simple to do that.
And all of those reasons are ultimately why you partnered with Confluent to build out your most modern architecture. Do I have that right?
[00:18:55] George: Yeah. And modern architecture is not the end goal, [00:19:00] right? The end goal is to make sure that my team has the best tools at their disposal, that they don't spend more time than necessary doing the work that they need to do, and that they could recover as fast as they possibly can.
[00:19:20] Sami: And sometimes I feel like it was the creation of things that aren't so tech-focused.
Like, something that has been really enjoyable to develop with George is [00:19:30] a standardized questionnaire that we now provide to teams. So when the word about Confluent being a technology that can be used at the bank got out, there's so many different pockets now of teams that want to use it, right?
And they just kinda, like, overwhelmed, I feel like at first — reaching out to George and his team, sending a bunch of emails like, "Oh, I want to use this, I want to do that." And so we came up with just, like, a flat file, like a CSV, to send them to say, "Hey, these are the things [00:20:00] that we need to know before you just start producing data.
So how much data are you gonna write? How much data you want to store?" Like, typical questions for standing up the cluster, and now it's become more of a flywheel of, "Okay, you guys sound like you at least know what you're gonna be sending us, so we can help get that cluster set up."
[00:20:18] Joseph: That's awesome.
You know, I've talked to probably two dozen people, different groups, as part of this show, both in person and remotely like we're doing today. And a common theme that I keep [00:20:30] hearing is just working with Confluent — and it's very exciting for me to say this because I work for the company, Sami works for the company, and I want to make sure I'm representing something that actually makes a difference for our customers.
And it's not just the technology, right? The technology's great, and I'll die on a hill to say that. But it's the actual partnership. It's the soft things. It's how do we help other business units adopt a system? 'Cause it's so surprising to me how a company could spend money and you built this great thing and only 10% of the company's using it when it would [00:21:00] make everyone's lives easier.
But to hear this story of how Confluent and Sami, you helped kind of build this practice around adoption of data streaming — it's very impressive, I gotta say. Next, we're gonna dive deep into how Confluent solved OCBC's data challenges, but first, a quick word from our sponsor.
[00:21:21] Announcer: Your data shouldn't be a problem to manage. It should be your superpower. The Confluent data streaming platform transforms [00:21:30] organizations with trustworthy real-time data that seamlessly spans your entire environment and powers innovation across every use case. Create smarter, deploy faster, and maximize efficiency with the true data streaming platform from the pioneers in data streaming.
[00:21:57] Joseph: Sami mentioned your team [00:22:00] manages all these integration systems. Now, I imagine that's got to create a lot of concern when something goes wrong, because you have systems upstream, you have Confluent in the middle, you have systems downstream. So I'm curious, how do teams tackle issues when something goes wrong?
And how do you eliminate data streaming as a source of concern?
[00:22:17] George: Wow, that's actually a big question. It covers everything. Like Sami said, the onboarding exercise, where we make sure that we've got the right [00:22:30] type of workload, we've got the right sizing. We know that we won't burst the system when they come on board.
That's usually the first step, to prevent problems from happening in the first place. Then we've got monitoring in place, where we've got infrastructure monitoring. We've got it from Kafka all the way down to the VMs that are running the actual thing. Then that's on my team to continuously monitor, [00:23:00] design, redesign, refine how this monitoring and alerting works.
And then there's the application layer, which is another team. They monitor things like timeouts, slowness in response times from producers, consumers, and we work together, right? It's a 24/7 operation. We've got people on shift. We train them both internally and with the help [00:23:30] of Confluent to ensure that they've got access to not just the technologies, but the ways of how to think about solving a problem.
And I think that's just as important, if not more, than knowing the technology. How to categorize problems that developers have and streamline it down to actually solving the problem.
[00:23:55] Sami: A specific scenario comes to mind too. I was actually [00:24:00] on site. George, remember we were supposed to have a quarterly business review one day?
[00:24:05] George: We were, yeah.
[00:24:06] Sami: Yes, right as the meeting started, George's phone is just a Christmas tree, right? And he's like, "I gotta go." So he got out of the room, and eventually some of his team is sitting there next to me, and we're like, "Okay, this sounds kind of serious. Maybe we should go check out what's happening."
And George and the team use Control Center from Confluent — basically, like, our [00:24:30] monitoring UI — and they were able to quickly get in there and see, okay, is the data at least getting to the topic, right? Like, whatever is happening with this upstream — there was an upstream legacy technology that will not be named, but there's a different technology, right, that was upstream.
And there was a question about is it a Confluent problem, or is it this other technology's problem? And I think that Control Center UI really came in handy then, because they could [00:25:00] quickly just log in, see is data pulling up in the topic or not, what's our consumer lag — like, basic metrics like that.
And I remember seeing one of George's team members on the phone, on this video conference with people in Malaysia and different geos and everything involved. And he was able to say, "Hey, guys, let's level set on something. I see data on the topic."
[00:25:20] Joseph: Right.
[00:25:21] Sami: So that's an indication, right? Like, that we can at least do a little bit of sniffing around and diagnose the problem a bit quicker that way.
[00:25:29] Joseph: Right. [00:25:30] And you also know you're not losing data, right? And I think that's always the biggest concern. But that's fantastic, Sami. You can't get much more real-time than, "Hey, can I help you with this?" So, great representation of the brand, Sami. I appreciate that. Now, I'm curious, now that everything's in place — you have this bulletproof cluster, you have other clusters, your team's been trained, you got all this buzz around OCBC with more people, more teams adopting data streaming —
what was the final impact of [00:26:00] modernizing those various applications and integrating the multiple data centers? What was the impact, and what are you proud of?
[00:26:07] George: Well, I'm proud that we moved thousands of microservices over from the old platform to the new platform —
[00:26:13] Joseph: Wow.
[00:26:14] George: — over the course of maybe about 12 hours over a weekend. We got Singapore, Malaysia, Hong Kong, everybody on board and moved at the same time with zero data loss.
[00:26:28] Joseph: Wow. Mm-hmm. Over [00:26:30] thousands of microservices. That's very impressive.
[00:26:33] George: And not just microservices. It was batch jobs and monolithic applications as well.
[00:26:38] Joseph: Oh, wow.
[00:26:39] George: All in the same night.
[00:26:39] Joseph: Right. Tens of thousands — thousands, maybe tens of thousands — of producers and consumers. Would that be a safe assumption?
[00:26:45] George: Mm-hmm.
[00:26:46] Joseph: And no data loss.
[00:26:47] George: Zero data loss.
[00:26:49] Joseph: You can't do better. It...
[00:26:50] George: Yeah. It was done in six hours, but it took six months to plan.
[00:26:54] Sami: Yeah.
Extremely surgical. I mean, I can remember the decent amount of time we just spent [00:27:00] looking at the current services and, like, creating Kafka users in the bank's AD and making sure those identities could work against Confluent as they did with the prior provider. It was extremely surgical. I was amazed when, yeah, George was like, "It's done.
I need five days of PTO. Everyone's working." Like, it was incredible.
[00:27:19] Joseph: Well, I know that pressure. I've been through it myself. Major launches of video-on-demand services that I can't name because, you know, I signed [00:27:30] NDAs. But the pressure that you feel when you hit that first button or that first thing starts to migrate, and then things start to look good, and you have that first bad sign that things don't go well, and then you're, like, an hour in, and it's like, things are going too well.
I understand that. You have a lot to be proud of. So George, I want you to think back —
[00:27:47] George: I'm proud of my team, actually.
[00:27:48] Joseph: Okay. "I'm proud of my team." And thank you for giving that credit. Your team did a fantastic job. I realize you didn't do that by yourself. It's not just you and Sami
vibecoding back there. [00:28:00] So I'd like you to think back to 2017, right? Like, think about George before implementing data streaming. I'm curious if you could share some advice for leaders like yourself, but that are maybe just trying to dip their toes in with their organizations to data streaming today, like you were doing back in 2017.
What would your advice for them be?
[00:28:22] George: Well, technically I wasn't in OCBC in 2017. I joined in 2020. The journey began before I was there, but [00:28:30] really, I think the principles remain. I think Sami knows this, but throughout the engagement, I told everybody on the team, "I'm focused on a three-letter word, BIM: benchmarks, integration, and migration."
All right. So I was saying that three times a day, three days a week, until everybody knew what I was [00:29:00] talking about. And I think keeping things simple and to the point, where we could describe everything in three letters, but having the ability to expand those three letters into multiple activities and teams, helped to make us have a common language and execute that.
So if you were talking about from 2017 to today, I think having that [00:29:30] clarity of what we wanted to do was paramount.
[00:29:34] Joseph: Yeah, that makes a lot of sense. I mean, you're taking something that is highly complex, has a lot of moving parts, and you try to just kind of squeeze it into a nutshell and just make it simple that anyone can kinda wrap their head around it, and then it becomes like a rally cry of everything's BIM.
But like you said, each of those letters has a lot of weight under it, but I think it helped people to visualize.
[00:29:54] Sami: I think that framework was so helpful for things beyond just the core Kafka pieces [00:30:00] too. So we discussed the stretching of this cluster across the sites that George and team deployed, but we also realized that if we wanted to be in line with these principles of the bank, we actually had to make everything else HA and fault-tolerant.
So when it came to the brokers — I mean, the connect nodes, the schema registry nodes, everything surrounding that core broker layer — we set it up to be HA too. So in case [00:30:30] any one of those things goes out, even their Control Center goes out, they can make sure that, okay, we're in line with the principles of the bank.
We can still have no continuity-of-business issues, and yeah, it was really helpful.
[00:30:44] Joseph: So you basically applied BIM to the DSP, and that's way too many initialisms for one sentence. So, speaking of the visual, or envisioning, right? George, what is your future [00:31:00] vision for data streaming at OCBC?
[00:31:03] George: My future vision is to reduce operator overhead and operator overload.
[00:31:12] Joseph: Mm.
[00:31:13] George: I'm the service provider, I'm the operator, so that's my concern in my team. How can I help my team be more productive without giving them additional work to do, right? Additional unnecessary work. [00:31:30] So we have a lot of current processes which I think we could streamline by moving into a container-based platform.
Today we're running VMs. Tomorrow we could be running containers. That reduces the work of updating the OS, right? It's fine when you've got 10 machines, but we've got 100, or over 100, 200. [00:32:00] So that adds to the time. I'm also always looking at how do we improve the developer experience.
Some numbers here, right? Almost 60% of the tickets we get from our developers is about configuration issues, right? We publish a golden standard for our configurations, but sometimes things get wrong, and it takes too much time to figure it out. So how do we [00:32:30] build a framework in a way that it's close to impossible to get configs wrong?
[00:32:36] Sami: Yeah. We were just on a phone call about that — remember, George? After hours, there was a consumer configuration issue, and we looked at the logs and it turned out to be just authentication. So yeah, there definitely is... It's always the... Yeah, like, the first touches can be hard for a lot of developers that aren't so familiar with, yeah, do I use keytabs?
How do I get access? All that kind of stuff.
[00:32:59] George: Exactly.
[00:32:59] Joseph: You [00:33:00] know, if your team hasn't bought you a Best Boss Ever coffee mug, they really should. 'Cause honestly, I asked you a broad question, like, what is the future vision at your company? And you could have said anything, right?
You could have been like, "Hey, AI agents," right? I think that's the popular answer. But you chose to say, "Hey, I wanna make things easier for my team. I wanna make their job better and easier. I wanna improve developer experience." That is a fantastic answer, George. I really appreciate it.
[00:33:28] George: Thank you. [00:33:30]
[00:33:37] Joseph: Before we let you go, we're gonna do a lightning round. Bite-sized questions, that's bite-sized answers. That is B-Y-T-E. Like hot takes, but schema-backed and serialized. Are you ready, George?
[00:33:47] George: Yep.
[00:33:48] Joseph: What is something you hate about IT?
[00:33:54] George: Long hours.
[00:33:56] Joseph: I think we can all relate to that. What's your AI hot [00:34:00] take?
[00:34:00] George: It's gonna change everything, and it's not gonna be what we expect.
[00:34:04] Joseph: I like that. That's a good one. What's a non-tech activity or hobby that's impacted how you think about data?
[00:34:11] George: Long distance driving and how to get from one place to another.
[00:34:14] Joseph: Oh, you're always thinking about the streams. I like that. Where are you getting outside inspiration from, George? Is it from a book or perhaps a thought leader in the industry?
[00:34:23] George: I guess from my friends in industry and listening to podcasts like yours.
[00:34:27] Joseph: Oh, thank you. I did not pay him to say that. [00:34:30]
Any final thoughts or anything to plug, George?
[00:34:33] George: I think it's important to not just look at technology, but also the processes and the people around how we manage it. Because every company's different, and we need to design those around the technology instead of the other way around.
[00:34:51] Joseph: That's great.
You've been very consistent. Like, for you, it's all about the experiences, whether it's your team, your team's customers, like your developers, or the customers of [00:35:00] OCBC. I appreciate all of your guidance and your candidness, and honestly, just the warmth that you've expressed. So thank you so much for joining me today.
And for the audience, stick around, because after this, I'm giving you my top three takeaways in two minutes.
That was just an incredible conversation with George and Sami. Here are my top three [00:35:30] takeaways. Well, first, George talked about how monitoring was necessary — setting up the right monitoring and having the right visibility into their data streaming platform to ensure that the system will not just work now, when they were thinking about capacity planning, but also work well into the future.
And I think that's important for anyone who's building out any type of architecture. It's great now, but what happens when you crush it and you grow 10x? Do you have everything in place to ensure that it will work? Now, monitoring was [00:36:00] the key basis of my next takeaway. So George mentioned that, when troubleshooting, because his team runs integration, they gotta have all the monitoring in place, again, to ensure that their data streaming platform — the decoupling platform — is not the source of any issue they have, right?
In addition to monitoring, they rigorously train their team on how to solve these issues with help from Confluent, which I love. And I can't forget that nice little anecdote that Sami told about during a QBR, where George's phone [00:36:30] started blowing up with alerts, and Sami, even though they were very early on in the relationship, said, "Hey, can we help?"
And they jumped right into the product in Control Center, and they were able to ensure that data was flowing into their data streaming platform, which — I'm sure everyone was very excited to know that they're not losing data. And the last takeaway was something I think George really put that was very eloquent, in that he kept talking about BIM was the focus: benchmarks, integration, and migration.
He took this [00:37:00] very audacious migration, right, of thousands of consumers and producers — took six months of planning. They were able to do it all in six hours with no data loss, but they were able to do that 'cause they built a mantra — BIM, BIM, BIM — something that is very simple and compact, benchmarks, integration, and migration, but represented a much larger scale effort.
I think having those mental mantras can really help anyone kinda get on board with the idea and also maybe help them [00:37:30] have the mental rigor to carry on when the pressure really starts to set in. That's it for this episode of Life Is But a Stream. Thanks again to George and Sami for joining us, and thanks to you for tuning in.
As always, we're brought to you by Confluent. The Confluent data streaming platform is the data advantage every organization needs to innovate today and win tomorrow. Your unified platform to stream, connect, process, and govern your data starts at confluent.io. [00:38:00] If you'd like to connect, find me on LinkedIn.
Don't forget to leave a like or a comment on the YouTube video if you're watching. Tell a friend or coworker about us and subscribe to the show so you never miss an episode. We'll see you next time.