In this MonkCast, Rachel Stephens talks with Sehjung Hah, a product marketing engineer at Broadcom, about how VMware Cloud Foundation 9.1 is shifting private cloud operations from click-driven dashboards toward programmable, API-first workflows.
Hah walks through the expanded VCF API surface that lets developers pull network details, vSphere diagnostics, and real-time infrastructure health in a self-service fashion. They also discuss a new fleet management capability that centralizes password rotation, certificate updates, and identity management across massive compute footprints.
This RedMonk video is sponsored by VMware by Broadcom.
Links
Transcript
Rachel Stephens (00:12)
Hello and welcome to the MonkCast. I’m Rachel Stephens, research director with RedMonk, and my guest today is Sehjung Hah. He’s a product marketing engineer with Broadcom, and he focuses on helping teams simplify their IT operations processes. Sehjung thanks so much for coming on.
Sehjung Hah (00:28)
Rachel, thanks for having me.
Rachel Stephens (00:30)
I’m so excited to have you here. I think we’re gonna have a great conversation. And today’s episode is actually a continuation of a series that we’ve been doing with the Broadcom team about the most recent product release, VCF 9.1. So I’ve done a couple of episodes, one with Audrey Bian and we talked about how platform engineers can help bridge VMs and modern Kubernetes workloads together. I did another episode with Jay Thontakudi, where we talked about how Broadcom’s partnership with Canonical can improve developer and operator experience.
And today, Sehjung and I are diving into some day two operations conversations. And specifically, we’re going to talk about removing developer friction, moving away from static dashboards, treating telemetry as code, and other really exciting things. So, Sehjung, I’m so excited. Let’s dive in and start on that friction part. So at RedMonk, we talk a lot about developer experience gap. And when we say that, what we essentially mean is that there’s some friction that arises when developers have to spend their time piecing together systems instead of writing code. And this can apply sometimes when we’re piecing together like disparate tool chains from across a variety of vendors, but it can also happen when we just have siloed infrastructure within our platform. And it sounds to me like some of the 9.1 releases are designed to help address this friction. So can you talk to us about like what does it mean to remove friction in a private cloud environment.
Sehjung Hah (01:49)
Right. so it comes down to a really practical change on the tooling side. In VMware Cloud Foundation 9.1, we’ve aggressively expanded the VCF or VMware Cloud Foundation API surface so developers can directly access the platform data they need, things like network details or vSphere diagnostics or NSX logs and real-time infrastructure help. So historically that dependency has been a massive bottleneck.
A developer might stall at the very beginning of a task simply because the environment context needed is trapped behind like an ops ticket queue. You know, they’re waiting for someone. In VCF 9.1, we largely eliminate that handoff by exposing that operational and health data directly through the APIs. And that way the developer can move on their own timelines instead of waiting for that manual handover.
Rachel Stephens (02:44)
Love that. And self-service is such an important element of making developers effective and having that development velocity in place. And it also makes it easier for platform operators to focus their time and energy on higher value pieces of their work.
And so I would love to dive in more into that operator experience. And can you tell me, are there other improvements in 9.1 that help platform engineers?
Sehjung Hah (03:08)
Yes, Rachel, a major focus for us is the new fleet management capability built right into the VCF portfolio. As part of VCF operations, you know, think of it like managing a massive fleet of rental cars or cargo ships. You don’t want to maintain each one individually, you know, whether it’s the fuel or upgrades are needed for each vehicle. You want to manage the entire group as an entire unified entity and also at scale.
So in VMware Cloud Foundation, your fleet is your massive footprint of compute, storage, and networking. So historically, platform engineers had to manually jump between the isolated environments to, you know, think do things like rotate passwords or update security certificates, manage identity and access, or you know, even configure individual license keys. So fleet management, you know, the concept that we’re using centralizes all of that.
within VCF operations and they can be done with the APIs. So it eliminates the manual grind of working on infrastructure at scale and it gives the platform teams the consistency they need to build and maintain the environments without the heavy administrative attacks.
Rachel Stephens (04:23)
Yeah, that ability to understand things at scale is huge.
And so like you can it’s great to manage holistically, but you also need to be able to kind of have that granular level of insight in order to actually run everything effectively. Like they both have to feed each other. And so I think similarly, if a developer or platform team want to know like the just answering the question, is my application healthy? They need to have some of that actionable observability data that both on the high level and then that gets down into the details. And so like if we’re like historically thinking about VMware, I think people maybe might think of it as a UI and dashboard centric experience. But from my understanding, it seems like you all are trying to shift that into a more API centered approach. Tell me more.
Sehjung Hah (05:07)
Yeah, Rachel. So yeah, the traditional way of managing infrastructure was completely human-centric, which you know inherently means it could be slower at times versus you know using programming. So if an application was acting up, or a developer or a platform engineer had to log into that user interface dashboard and, you know, manually hunt down through different graphs and different screens to figure out what went wrong. So in VCF 9.1 our latest release, it kind of flips that paradigm by treating telemetry as code. So with VCF operations, it provides that observability layer through that API framework. And the big architectural shift in this release is that we’ve entirely integrated log management into VCF operations. And under the open API specifications, developers who care about having open predictable interfaces, you know, that don’t change, for example.
And that’s one of the things this release delivers. So, you know, one of the things that we have now is this new real-time observability capability. So in the past, you know, whenever we had metrics on our dashboards, they’re in the five-minute range. So, you know, if you’re looking at infrastructure on the dashboards, you know, each interval was five minutes. but now what we can do is we can collect performance metrics down to two seconds. So, you know.
Of course, this can be turned on as humans need, you know, as they’re troubleshooting an issue, you’re not gonna leave it on the whole time. But then human eyes, you know, they can’t process a dashboard that graph that updates every two seconds. It’s you know, it’s blinding, right? So that two-second window is intentionally designed for code. Not necessarily the people you know, looking at dashboards. the those APIs are natively Prometheus capable and we have PromQL support.
So a Kubernetes operator or an automated script can ingest that high frequency stream, then detect the micro anomaly instantly, then from there execute a remediation via the PCF SDK, you know, even before a human admin would notice a latency spike, for example. So we’ve yeah, so we’ve applied that you know same programmable logic to logging as well, too. So
Historically, log formats were fragmented across the different infrastructure components. So, you know, each component that we had within VCF, you know, it it would it had a different log format. So every log looked different. So, you know, for a programmer to make a log parsing script, you know, it’s makes it a lot more difficult to write, especially when everything’s a little different. so in VCF 9.1, we’ve standardized the log formats and the fields across entire public cloud so that
The data schema is now completely universal and predictable. So that way engineers can seamlessly, you know, pipe the high fidelity log straight into, you know, other tools like Kafka or a Slack alert or even a third party AI pipeline. So we’re fundamentally shifting observability, you know, from humans staring at dashboards and moving into software where the data is routed and acted upon programmatically.
Rachel Stephens (08:27)
There are so many great things in there to like. I think having human and machine collaboration is definitely the name of the game in 2026 and having more standardized formats so that it’s easier for everyone and people and tools to parse it is also great. And I think the general concept here is like having this more programmatic API-driven approach is just gonna open up a lot more opportunities for automation for both people and for tools and machines and agents, all of these things. I think the flip side of that sometimes is that without proper tools and processes around these automations, we can inadvertently introduce security challenges that come with it. I think one that comes to mind for me is secret sprawl. So when we have everything being like driven by script, automated by API,
Sometimes teams, especially teams that are still developing this muscle, can fall back on to more high-risk approaches like having static account credentials and those inevitably seem to leak. So I I think one of the things that’s great is like we want to enable this and empower people, we also want to make sure we have the guardrails to keep everybody safe while we do this. So how are you kind of thinking about helping organizations make this shift without increasing their blast radius?
Sehjung Hah (09:46)
Yeah, this is what we’re seeing too, Rachel. So, you know, hard coding, long lived like a God mode password between the different components into you know the development pipeline or a script. It’s you know a security nightmare, really. so to solve this, we’ve improved identity management across the entire VCF stack. So historically moving between the different V VMware components meant dealing with you know fragmented or independent identity connections.
Because it’s like many to many. So now with VCF 9.1, we have like a native stack wide support for OIDC and OAuth 2.0 baked right into the architecture. So this means like for developers, they can, you know, stop using static service account passwords entirely. So, you know, in terms of the authentication, you know, first, you know, you you show the person’s ID to know that they’re the right person, but then you also need authentication to know what you know, privileges that person might have or what services that they can do. So this we can do dynamically now rather than with static. And so that way, you know, whether it’s human users or even automated APIs, you can generate the standard-based OAuth tokens that can get exchanged for the short-lived bearer tokens. So you know, in case an automation script leaks or credentials somehow compromise,
You know, yeah, like you said, the blast radius is virtually zero because that token is, you know, very narrowly scoped and also it automatically expires shortly after. So it really reduces that risk with the static scripts with the passwords built in versus like a dynamic automated trust.
Rachel Stephens (11:29)
Love that. And that reminds me of this also came up in my conversation with Jay. But when we start to pull security down natively into the platform architecture rather than having to have people kind of independently make those good, safe choices, it makes everybody safer. So there’s this quote from Avi Douglan that I love, and it’s security at the expense of usability comes at the expense of security. And so making like the right thing to do and the easy thing to do.
The same thing to do is just so important. So love love to see that come together. And I’m just always going to throw out that quote when it comes up because I love it. But all right. It what we’re talking about before, collaboration of humans and machines, like in the year 2026, when we’re talking about usability, we’re talking about security, it also means we are inevitably going to be talking about AI. And so I think the elephant in the server room, so to speak, is that AI is driving a lot of infrastructure-based conversations right now. I think when we’re talking about
Private cloud in particular, we tend to have things like sovereignty conversations and people trying to pull in some of these risk conversations weighed against cost because AI models can become really expensive really quickly if we don’t have kind of guardrails and visibility in place. And so how are you at VMware starting to think about that? How are you helping enable people to bring AI workloads into their platforms with these guardrails and cost visibility pieces in place?
Sehjung Hah (12:55)
Yeah, you’re completely right. So, you know, running those massive AI models or inference workloads in the cloud can get wildly expensive and as well as unpredictable in terms of cost very quickly. So with private cloud, we deliver that data sovereignty as well as cost baseline, but it only works if you actually have that granular, you know, visibility into where you know the compute storage and the actual money you’re spending is going. So to solve that in VCF 9.1 we’ve introduced cost management directly for Kubernetes workloads. Before we’ve only had that for the VM workloads. So now we can also do it for Kubernetes. So through VCF operations, platform engineers can now get a full showback as well as chargeback and real-time pricing. So this is where you’re showing the development group who’s using those resources on the application, you know, how much it costs to run those workloads as well as run the storage in the network.
And then you can get the estimates down to the individual Kubernetes pod level, for example, as they’re running their AI application. So the real news here is for open source and DevOps teams, is you know, Broadcom is also natively adopting adopting what we call FOCOS or Focus. It’s like the FinOps open cost and usage specification. And because we’re outputting the billing data in this universally standardized format, it integrates.
cleanly right into the existing, you know, enterprise FinOps pipelines as well as third party tooling that they might have so that they can compare, you know, the private cloud costs to run that AI versus, let’s say, the public cloud cost. And it’s in the same type of format. So this means that, you know, before a platform team ever commits resources to an AI inference infrastructure, they can accurately model both the performance impact as well as the cost footprint. So it really gives the the engineer a practical planning tool to optimize without getting blindsided by a bill.
Rachel Stephens (14:56)
Yeah. Well RedMonk in general loves an open standard, so that sounds great. And I personally am a finance nerd. I that’s how I started my career. So I I always love a good chargeback story. I I think I might be alone in that. I might be the only one who gets excited about that. but I I think in general though, mapping the costs is
Only part of the battle. I think the real power then comes when we tie it back into the story we were talking about before, when we talk about making things actionable and programmatic. And so we talked about kind of this architectural shift of bringing things into open API specifications. We talked about making things more API accessible. Can we talk about maybe what this looks like more specifically maybe give users and listeners out there an example about what this might look like when we have combined all of these together and helping them understand the health of their platform.
Sehjung Hah (15:52)
Yeah, sure, Rachel. So let’s look at the classic, you know, I used to work in tech support. let’s look at the classic 3 a.m. nightmare. You know, business critical applications suddenly start slowing down. So in the traditional world, you know, alarm rings, you know, a human engineer wakes up, then logs into the heavy infrastructure dashboard, and then spends, you know, some time, it could be an hour, clicking through different graphs, you know, a lot of mouse clicks.
figure out you know which host is kind of choking or is it the network or is it something else or is it storage. So in VCF 9.1, you know, we turn that entire sequence into like a programmable event. So the moment you know our new two second metric detects a storage latency spike, for example, it could be a network issue, it could be you know a compute issue, you know, VCF operation acts on it in real time. So instead of paging a sleeping human, it’s instantly package that performance telemetry into like a structured JSON webhook. And then from there, you know, an automated script can then use the V VCF SDK to isolate the issue and automatically execute remediation to the to migrate the workload to maybe a different healthy host. So the infrastructure effectively fixes itself based on the code policies before a human admin even you know opens their laptop. So we’re
Shifting, you know, monitoring away from a static dashboard in in the previous world and into the active event-driven dynamic operations.
Rachel Stephens (17:27)
And I think that example really drives home just what we’re talking about in terms of a broader and overarching theme of this entire conversation and kind of the theme of this VCF 9.1 release as I understand it, which is bringing more programmatic and automation opportunities into our platforms. Because I think if we’re thinking about kind of combining our existing workloads and adding in this new higher volume of AI workloads.
What we have to have is a system that has the capacity to deal with this increased velocity, increased scale, and have the guardrails to do it safely and cost effectively. And we to do that, we just we can’t be manually clicking around a dashboard. We have to have a system and a platform that is more programmatic and more queryable. At least that’s how I would maybe frame what we’re talking about. Is there anything you’d like to add?
Sehjung Hah (18:19)
no, I think that’s great. So basically, you know, I’ve been working in IT for a while. So I’ve kind of seen it go from, you know, the clickway to when programmabilitly first started, and now it’s, you know, full-on, you know, programmabilitly for efficiency, and now AI’s here too. So a lot has changed for sure.
Rachel Stephens (18:37)
So much is changing, and it’s all moving so fast. So there’s there’s lots to keep up with, and we we appreciate having platforms that can help us and move in that right direction. All right, Sehjung so let’s wrap up here. If we have practitioners or listeners out there who want to check out the things that we’ve been talking about today, be it the open API specs, you mentioned an SDK, maybe diving into the documentation, where should they go get their hands dirty? Where can they start to look at this for themselves?
Sehjung Hah (19:04)
Yes, so online we have several resources, you know. So you can definitely check out VCF operations because that has visibility of the entire private cloud. But then also we have different SDKs and in different languages, you know, Python or Java and some other languages. So depending on how your team is implementing the programming, we have those and those are online.
you can start building those programmable workflows today.
Rachel Stephens (19:30)
We’ll share links in the notes. Everyone, thank you so much for joining us today. And Sehjung, thank you especially to you for your time today. This has been a fun conversation.
Sehjung Hah (19:38)
Thanks. Great to be here.
