Latest / The MonkCast / From Dashboards to APIs: Day Two Operations in VCF 9.1 with Sehjung Hah
Transcript
- speaker-0: Hello and welcome to the Monk Past. I'm Rachel Stevens, research director with Red Monk, and my guest today is Seijong Ha. He's a product marketing engineer with Broadcom and he focuses on helping teams simplify their IT operations processes. Sejong, thanks so much for coming on. speaker-1: Hi Rachel, thanks for having me. speaker-0: ⁓ 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 Beyond, 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 Seejang and I are diving into some day two operations conversations. And specifically we're gonna talk about removing developer friction, moving away from static dashboards, treating telemetry as code, and other really exciting things. So Seejung, ⁓ I'm so excited. Let's dive in and start on that friction part. So at Red Monk, 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 the 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. speaker-1: Right. ⁓ so it comes down to a really practical change on the tooling side. In VMware Cloud Foundation nine dot one, we've aggressively expanded the VCS 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 nine dot one, 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. speaker-0: 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 I would love to dive in more into that operator experience. And can you tell me, are there other improvements in nine dot one that help platform engineers? speaker-1: 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 enti 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 tax. speaker-0: 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 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. speaker-1: 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 a 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 DCF nine dot one, our latest release, it kind of Flip stack 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 prom QL 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 DCF nine dot one, we've standardized the log formats and the fields across entire product 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 you know, even a third party AI pipeline. So we're fundamentally shifting absorbability, you know, from humans staring at dashboards and moving into software where the data is routed and acted upon programmatically. speaker-0: 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 ⁓ twenty twenty six 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 ⁓ 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 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? speaker-1: Yeah. ⁓ this is what we're seeing too, Rachel. So you know, hard coding, long live 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. ⁓ is just like many to many. So now with VCF nine dot one, we have like a native stack wide support for OIDC and OAuth two dot ⁓ 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 ratus 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. speaker-0: Love that. And 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 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, ⁓ the 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? speaker-1: 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 the actual money you're spending is going. So to solve that in DCF nine dot one. 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 know 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 outpitting the building data in this universally standardized format, ⁓ it integrates cleanly right into the existing, you know, enterprise FinOffs pipelines as well as third party tooling that they might have so that they can compare, you know, the private cloud cost to run that AI versus, let's say, the public cloud cost. And, you know, 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 actually 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. speaker-0: Yeah. Well re Red Monk 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 for mm, 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. speaker-1: 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 AM 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 nine dot one, 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, the you know compute issue, your 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 B DCF SDK to isolate the issue and automatically execute remediation to the to migrate the workload to maybe a different healthy host. You know? 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 i in the previous world and into the active event driven dynamic operation. speaker-0: 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? speaker-1: ⁓ 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 programmable first started and now it's, you know, full on, you know, programmably for efficiency and now AI's here too. So a lot has changed for sure. speaker-0: So much is Rich, 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 move in that right direction. All right, Sejong. 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? speaker-1: 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. speaker-0: Perfect, we'll share links in the notes. Everyone, thank you so much for joining us today. And Seijang, thank you especially to you for your time today. This has been a fun conversation. speaker-1: It's great to be here.