I have been waiting for my colleague Stephen to write something about agents as the new new kingmakers for a while now, and he finally posted something about that today –  Agents: The new, New Kingmakers. The post is definitely worth reading in full, not least for the history lesson about how we got here, but here is the core argument of the piece:

There were and are limits, of course, to what the models can do and the mainstream software development market had to grapple for the first time with non-deterministic machines that would not only make mistakes, but lie about them and disobey instructions. But the direction of travel is clear: machines are getting better and better at writing code, and as a result they’re writing a lot more of it. Just as importantly, they’re not only writing the code, they are often choosing the programming language used, the libraries and frameworks leveraged – even the fonts in the user interface. In fact, they will often choose technology that they have been explicitly told not to use.

All of which implies that the power dynamics of the industry, just as they tilted towards developers, are now shifting towards agents.

Stephen continues:

Between the current model abilities and the wild asymmetries between different product categories, there isn’t likely to be a single dominant approach. In some markets, AI-assisted human workflows will be appropriate; in others, it will be headless, agent-only infrastructure.

What’s critical is distinguishing between vendors building for a new agent-centric world, and those merely bolting AI-on because marketing told them to. AI-washing is not indicative of a product that will necessarily be correctly positioned moving forward.

This new dynamic is absolutely fascinating, not least because RedMonk has historically done a solid job of understanding developer choices and helping other people to understand them. Where is the signal now? It’s increasingly in the models and agents and decisions and suggestions they make. That certainly has implications for the work we as company do. But that’s because agent-first decision making has implications for the work all of us do – whether developers or platform engineers, security and compliance folks, marketing or sales people, boardroom execs, journalists, consulting firms. It’s not just the SDLC that changes – it’s the entire decision making and management infrastructure. It’s a lot easier to talk about guardrails than it is to enforce them. Developers have long ignored “corporate standards” – indeed this was a core thesis of Stephen’s book The New Kingmakers, which is about bottom up adoption. We would talk to CIOs and they had no idea what people were actually using to get the corporate work done.

I remember the banking exec saying “MongoDB – it’s popping up everywhere in the organisation, but I don’t even know what license it is. I will tell you one thing – I am not going to run my bank on it”. I laughed to myself – “dude, you already are.” Developer choices are production choices, and today agent choices are production choices. And as Stephen points out in the piece, agents aren’t exactly renowned for doing as they’re told. They’re the new grassroots, and they’re going to create new winners and losers, just as developers made MongoDB a corporate standard without top down buy-in, let alone a mandate. And what happens as the agents make the choices, and humans are having less of an impact feeding the frontier models with carefully hand crafted blog posts, documentation, Stack Overflow responses and so on? So many questions.

But when it comes to answers, there is no doubt that we need to consider agents as peers in IT-decision making. Stephen pointed to a few examples, and they are literally all around us. We recently signed up Fly as a client, for example. Here is Martin Casado of Andreessen Horowitz talking about the company’s latest funding round.

Every wave of infrastructure is defined by who its primary user is, and for the first time that user isn’t necessarily a person. That changes what a computer has to look like,” said Martin Casado, general partner at Andreessen Horowitz. “Fly has spent years building infrastructure for that shift and is giving agents real computers instead of disposable sandboxes. We believed in that path early, and we think Fly is the platform on which this gets built.

So…  Computers for agents.

I was about bring this positioning up with Stephen on Slack, when I noticed a new rhetorical linkedin post by Render CEO Anurag Goel:

We spent years hearing: “Will Render scale?”
OpenAI builds on Render. Base44 scales on Render.
Meanwhile, weekly paid service creation looks like this.
I think we can retire the question.

With a chart like this, that seems reasonable.

The first questions on the post asked: “what happened in January 2026”. To me the answer was obvious – capable autonomous agents happened. The period from November 2025 to February 2026 was when it became really obvious that we’d crossed a Rubicon. We could trust agents far more than ever before. The human in the loop became somewhat anachronistic. Organisations stopped worrying about manual code review, or at least realised that automated and AI supported verification and testing was going to be essential to shipping software in the new era. The acceptance of autonomy began with people playing around with pet projects, was quickly embraced by startups, and then moved into enterprise thinking far more quickly than I, for one, anticipated. I have spent all year talking to organisations that are much further along the autonomy spectrum than expected – including banks, telcos, retailers and government organisations.  2025 may have been the year or agents but 2026 has definitely been the year of autonomous agents. Humans were the bottleneck in the software development lifecycle, but we’ve moving beyond that now. Autonomous agents do an awful lot of work – and that’s what the chart above shows. It certainly doesn’t hurt when you have OpenAI as a customer as Render does.

Stephen in his post talks to the explosion of Sandbox platforms

Consider the emerging Sandbox application category: from players like Cloudflare, the aforementioned Daytona, Docker, E2B, Modal and now Vercel, the entire market is an artifact of and would not exist without agents. Developer tooling built for humans was built on an assumption that they will operate within acceptable boundaries of behavior; developer tooling built for agents assumes the opposite. Sandboxes exist to give the exploding number of agents more autonomy, while not trusting them.

With agents making the choices technical and developer marketing disciplines are going to be fundamentally reworked. We’ll certainly see attempts, many successful, to game the system – GitHub stars for the agent era. SEO for software agents (GEO). The zone will be flooded with vendor slop.

All that said, I remain cautiously optimistic. Trust and authenticity and clarity perhaps have more value than ever – the need to understand and synthesise the choices and thoughts of smart engineers to get better work done. Models need good signal and inputs to have good outputs. Agents are the new new kingmakers, but humans are still very very good at systems thinking, architecture, and creative thinking. I plan to recommit to writing more to help stake my claim, and help others navigate, this new frontier.

disclosure: Cloudflare, Fly, GitHub, MongoDB, and Render are RedMonk clients.

Just riffing off an interesting post by Per Buer of Varnish Software – The agents are coming for the web and the web isn’t ready.

The problem statement is that public infrastructure is being swamped by crawlers and agents. As Buer says:

Konstantin Ryabitsev’s post Creepy crawlies puts numbers on something anyone running a public git host has felt for a while: agents are an increasingly heavy burden on anyone publicly hosting information. So an ever increasing number of people are sending out more and more agents on longer and longer goose-chases and the traffic is increasing at an alarming rate.

“Anyone running a public git host” – yeah, GitHub knows something about that.

Buer’s post is specifically about git.kernel.org, which is indeed being swamped with inbound traffic, and not just inbound traffic but stupid inbound traffic. Agents don’t much care for efficiency. In the post Per shows how Varnish Cache Language (VCL) might help.

But the specific problem is described in Ryabitsev’s post:

At the time of writing, linux.git is about 1.48 million commits. Oh, and we have about 922 forks of it on git.kernel.org — but don’t worry, it’s actually extremely efficient on the backend, since it’s mostly the same objects in every fork.

Unless, of course, you’re a scraper, in which case you have, oh, several BILLION valid URLs you can scrape, only to get 922 duplicates of the same 1.48 million commits — which is exactly what the scrapers are doing.

But wait, it’s not just commits itself. You can also ask for patches, plain renders, diffs between arbitrary commits — cgit is happy to let you, which was perfect for the times when the Internet was for humans or crawlers who obeyed robots.txt, and is AWFUL right about now, because we can generate 1.2 METRIC BAJILLION valid URLs just for a single fork of linux.git.

kernel.org has effectively been playing whack a mole with a mole (well maybe not quite 6.02 x 10²³ but you get the idea) of moles, and the details are legit fascinating. Agentic and agent-driven problem solving is always a trip to see in detail. And of course humans are more than capable of building shitty CI systems and crawlers.

Block them

Initially, this was the solution — look through the logs, find out which IPs are obvious scraper bots, and fail2ban them. At first, this was easy, because the bots helpfully told you who they were via their user-agent. Then, they wised up and started pretending that they were random vanilla browsers.

So, we started banning them by IP — after all, it’s easy to figure out that an IP that is trying to grab every possible commit in a 8-year-old abandoned fork of linux is not really some lone Chrome on Windows user who is just furiously clicking every link that comes across their screen.

The bots then started fanning out to entire subnets, but this was still meh, because obviously an IP coming from Google Compute is just pretending to be a Firefox user. Banning the whole ASN was justified, even if this occasionally caught a random legitimate instance trying to automate link checking in commits.

Enter… your TV?

And… that’s when things turned really, really ugly. Suddenly, the crawlers were coming from millions of random residential or mobile IPs, all pretending to be random modern browsers. An IP like that would make 4-5 requests and then never show up in the logs again. There was no point in banning them, because by the time you figured out that they were bots, they were already done with you. You just needlessly ballooned your firewall ruleset by adding IPs that would never be back.

They descended like swarms of locust, hit hard and fast until the system fell over and then moved on to the next target until you recovered. Then, they returned. Rinse. Repeat.

Anyway you should just read the post. The point I wanted to make is that agents and frontier model companies are incredibly noisy neighbours – they don’t care about your robots.txt file. Varnish isn’t alone here – Cloudflare and Fastly are both working the problem. Cloudflare quite vocally – it built a Block all Bots switch, but yesterday announced a more granular approach, allowing “good” and “bad” LLM traffic, with different settings for search, AI training, and AI agents. Cloudflare is calling for “Accountable AI Crawling” – with allowances for responsible behaviour from the likes of Apple, Google and Microsoft. The CDN and next gen Cloud platforms are due a moment in the sun if they can help shape and manage these new traffic patterns.

But, yeah, in the current ethical wasteland of the industry when it comes to data collection and content aggregation for model training, this will continue to be a problem. And it’s worth stressing that while this post began talking about git hosting and caching, agents are going to be generating load in every domain – and not just across content but across transaction systems. Agents are incredibly hungry and they don’t need to sleep. Anything public facing is going to face incredible scaling demands. It’s very early days in the agent era. GitHub agent traffic has far surpassed the company’s expectations, which has led to reliability issues. But it’s going to be alone. Agent traffic increases aren’t going to be a couple of 100 per cent. We’re talking orders of magnitude. And that’s something we’re all going to need to deal with. First came the web, then came e-business, then self-service, and then mobile traffic. Well it’s now the agent era.

The agents are coming for the web and the web isn’t ready.

Cloudflare, GitHub, and Fastly are clients.

“

In August Dynatrace announced plans to acquire Arize, an AI observability company, for $915m. The deal makes strategic sense – AI workloads are increasingly production workloads, and will need to be managed as such. We’re going to see convergence and consolidation in the markets for Observability, AI Observability, and evals tools. Arize has out of the box integrations for more than 30 AI platforms, providing auto-instrumentation for them. 

Acquiring Arize will give Dynatrace a foothold in the market for evals – automated checks to evaluate the quality, accuracy and safety of AI systems. Evals are kind of like unit tests, but for non-deterministic LLM-based systems – this idea is pretty much an industry truism now, but it’s worth reading Hamel Husain’s seminal essay Your AI Product Needs Evals for further context.

Like software engineering, success with AI hinges on how fast you can iterate. You must have processes and tools for:

• Evaluating quality (ex: tests).
• Debugging issues (ex: logging & inspecting data).
• Changing the behavior or the system (prompt eng, fine-tuning, writing code)

The first two points map to observability and evals.

Enterprises are going to need a full lifecycle tool enabling developers and agents to collaborate to build, experiment, monitor and manage applications using, and iterating across, different models. Evals was originally a term used by Frontier model companies – most notably OpenAI, but has now crossed over into more general industry parlance.

We increasingly see companies adopting multimodel strategies – for example using OpenAI models for coding and Anthropic models for verification, or vice-versa. Open weights models are coming into play, too, to reduce costs, or at least to provide a hedge against vendor lock in. Startups are adopting open weights models like MIT-licensed DeepSeek V4-Flash, primarily for cost, independence and control reasons. In a recent Y-Combinator podcast Ollama co-founder and CEO Jeffrey Morgan said that the majority of enterprise token volume, roughly 80 to 90%, will flow through open models. According to a recent New York Times article 40% of the tokens AT&T burns are now “open models”. Rising token costs are encouraging dev shops to adopt tiered model usage strategies – with the most expensive models used for more complex jobs, requiring for example, greater reasoning capabilities. Some of this for development, and some for building outward facing apps.

Adopting the best model for the job is a strategy that requires tools to manage evals, observability and automation. The feedback loops for monitoring systems and applications, and apps and models, will need to converge, which is what Dynatrace is betting on with this acquisition. 

For more signal note that:

• ClickHouse acquired Langfuse January 2026, an open source evals and AI observability platform already built on Clickhouse, making the integration that much easier.   
• Cisco acquired Galileo May 2026, to bring AI agent observability and evaluation tools into its Splunk Observability portfolio.

Evals are critical because models are non-deterministic, and because different models have their own distinct personalities – changing models can change agent behaviour, which could negatively affect customer experience. Questions of safety and overall system reliability are increasingly intertwined. Your back ends need to keep running and your agents need to provide reasonably consistent behaviours in order to support customer trust. AI Engineering and IT Ops teams need to collaborate closely, so these management platforms need to be closely integrated. 

Arize already has a solid customer base, which skews to modern ecommerce and web companies including booking.com, Reddit, Doordash, Priceline, Wayfair, Uber and Duolingo. Dynatrace meanwhile has a solid foothold in the enterprise, built with more than 20 years of direct sales. The company has 4000+ subscription customers, and operates in over 100 countries worldwide. Its more traditional customers will increasingly be looking for the kind of tools Arize provides. The two companies already share a number of joint customers, including Air Canada. The trick will be to infuse Dynatrace with the AI experience and skills from Arize, while bringing to Arize its own breadth of capability and customer base. And of course keeping the Arize people in the fold, and allowing them to keep building.  

According to the press release about the deal:

AI engineering teams evaluate model and agent behavior in one set of tools, while the teams running the applications and infrastructure beneath them work in another. There is often no shared system connecting how an AI application is evaluated to how it behaves in production, so when output quality slips or a customer transaction fails, the cause can sit anywhere from the prompt to the infrastructure, and there is little feedback to developers.

This is the right way to think about the problem. LLM usage is not going to be a separate silo, but is central to how modern software development teams work. As organizations build harnesses, the infrastructure and instructions that shape and manage models into functional agents, they need feedback loops to understand what these agents are actually doing. Traces show what actually happened (observability). Evals turn these traces into repeatable tests: is the harness working as expected? Thus evals are becoming central to harness engineering, and harness engineering is where agentic software delivery is going. 

Making Progress in Progressive Delivery

Before considering Arize further, it’s worth examining the overall state of play with Dynatrace in 2026 and its push forward with Progressive Delivery.

Dynatrace kicked off 2026 by acquiring DevCycle, a feature management platform based on the OpenFeature standard, in January. Dynatrace actually led creation of the OpenFeature standard in 2022, but acquired DevCycle to accelerate its own growth, especially with a product led growth motion (PLG). OpenFeature is now a CNCF project.

Feature flags are a core technology for Progressive Delivery, enabling canary deployments, blue-green releases, and experimentation. Putting functionality behind a flag also allows for fast production changes and rollbacks if something breaks. In the Progressive Delivery book we argued that feature management and Observability tooling were both fundamental pillars to modern software delivery, and should be part of an integrated platform. We’ve been proven right by vendor consolidation as vendors in both categories have made acquisitions.

• Harness acquired Split.io May 2024, expanding the scope of its software delivery platform into feature management and progressive delivery. Split also supports OpenFeature natively.
• LaunchDarkly acquired Highlight April 2025, filling out its story for guarded releases and runtime management, with a modern Observability platform, offering tracing, session replay etc.
• DataDog acquired Eppo May 2025, to broaden out its footprint, moving into experimentation and feature management and a progressive delivery platform play. The deal was partly an evals play.
• OpenAI acquired Statsig September 2025, a Frontier model company acquiring one of the hottest companies in the experimentation and feature management space. Progressive Delivery is evidently going to be relevant to the AI era – with faster dev cycles than ever, and model changes requiring testing with named cohorts and rollbacks.

But back to how Dynatrace’s acquisition story offers a coherent look into Progressive Delivery in the agentic era: in April 2026 it also acquired Bindplane, a telemetry data pipeline company, to improve its story around fast-growing telemetry data volumes. System telemetry can be collected, enriched, processed and routed before it reaches observability platform datastores. Overall, this kind of approach improves cost management and efficiency. I have written about this idea in a post about log data management before. If telemetry data was growing fast before, with AI agents being used in production it’s exploding, so managing telemetry costs, and having flexibility across multiple data sources, will be more important than ever.

Arize, AI Native

Arize was built for monitoring and managing AI workflows – tracing behaviour, evaluating that behaviour, and learning whether changes will have the desired effect or not. The company’s AI engineering agent Alyx is squarely targeted at agentic ops for agentic development. Arize has been around for six years – it is properly AI native. This is a major cultural and technical infusion for Dynatrace, providing it can keep the talent in place.

Supporting its PLG motion Arize has a source available (not open source according to an OSI definition) project called Phoenix for instrumentation and evals. Phoenix provides tracing allowing you to see what happened during a run of your AI application – model calls, tool use, and custom logic. It accepts traces using OpenTelemetry with auto-instrumentation for popular frameworks (such as LlamaIndex, LangChain, DSPy, Vercel AI SDK), providers (OpenAI, Bedrock, Anthropic), and languages (Python, TypeScript, Java).

While Phoenix is based on Open Telemetry, the project is not open source, instead licensed under the Elastic License 2.0. There is a solid open source and open standards throughline here: OpenFeature for DevCycle, OpenTelemetry for Bindplane, and OpenTelemetry again for Phoenix. It will be interesting to see whether Dynatrace fully open sources Phoenix. Of course being RedMonk we encourage using OSI-compliant licenses. We’re pretty consistent on that. 

Arize also created OpenInference, an open source set of extensions for OpenTelemetry designed specifically for tracing LLM and agent context. This Apache 2.0 licensed tool has been adopted by third parties including envoy, Microsoft, and Tetrate. It’s also been adopted by frameworks including Crew AI, IBM Bee AI, and Langchain. Open source always makes third party adoption easier.

Dynatrace was already pushing ahead with some interesting agentic tooling. It recently launched Bluebox, an observability platform built to provide context to agents rather than humans – topology, traces and so on to support autonomous troubleshooting and debugging.

But the Arize acquisition will accelerate a push into agent-first workflows.

The Observability market was already undergoing consolidation as vendors pursued platform strategies to consolidate adjacent markets (metrics, logs, traces, feature management, progressive delivery) and now AI observability is part of that mix. The reality of multi model usage, and the desire of companies to drive down token costs, are going to make it critical to have integrated observability and evals platforms with full visibility into agent and developer workflows. Observability and evals will also be central to harness engineering. 

Dynatrace and LaunchDarkly are clients.This is not a sponsored piece of research. 

This is a video I recorded with Simon about the show this year.  Xcelerate London 2026 is on June 10th this year – get your tickets here.

disclosure statement- Fastly sponsored the video.

I am old enough to remember when people questioned whether Google Cloud even had a future within Alphabet. Well now we have a pretty clear answer – yes. I originally began this post as a quick roundup of news from Google Next 2026, but given Google’s results dropped the following week, let’s look at them first.

In the first quarter, Google Cloud revenue jumped 63%, year over year, to $20 billion, in the parlance of the day – absolutely crushing it. To the moon, etc. Growth rates like that on an already hyperscale business is quite something. Google Cloud now accounts for 18% of Alphabet’s total revenue. Which is to say, it’s a keeper.

Sundar Pichai, Google CEO said:

“Google Cloud is differentiated because we are the only provider to offer first-party solutions across the entire enterprise. Our growth in revenue, operating margin and backlog highlights this differentiation.”

AWS and Azure also had excellent quarters, but Google’s growth, even though from a lower base, was still a clear marker of substantial progress. I often say the best packager in any tech wave wins and wins big, and Google is looking increasingly well positioned. Packaging and integration go together hand in hand – you want an offering that makes things easy for the customer, reducing cognitive and organisational overheads. But packaging and economies of scale are also closely entwined – Google is well placed here because it owns technology up and down the stack.

Google also really pushed its position as a “full stack” AI infrastructure provider- it has technology leadership that spans from custom silicon to productivity apps, and unlike Microsoft and AWS it has its own capable frontier model in the shape of Gemini.

It is agents and harnesses however that are really going to drive model growth.

The agent platform

At Cloud Next Google announced tools for agent management and orchestration, and demonstrated continuing strength and depth in data infrastructure. It also apparently reintroduced Knowledge Management as an enterprise concern for the AI era.

The agent story is on point because, frankly, agents are finally capable enough to do some real work (on their own). Developers noticed a step change in coding agents around the turn of the year, arguably as big a leap forward for AI capabilities as the launch of ChatGPT in November 2022.

You just have to use the tools to see the clear difference in capability, or listen to AI-savvy developers across the industry. We’re in a fundamentally different environment now – the code being generated now is of a much higher quality, and with agents, an entirely new degree of autonomy.

Devs also began to better understand the value of brute force, and single task iterative loops (see the “Ralph Wiggum” pattern, invented and popularised by Geoff Huntley) in getting agents to do what they wanted. Harnesses are also becoming more effective, for example in providing consistent developer experiences as models evolve. If agents are getting this good at building and deploying software, other business processes are also going to be affected. The infrastructure we rely on just wasn’t built with agents and models in mind though – scale, security and management challenges are all massively increasing.

Google introduced Gemini Enterprise Agent Platform, building on and replacing its Vertex AI platform, with new features in its Agent Development Kit, scale and memory improvements for its Agent Runtime, but most importantly from a manageability perspective – Agent Identity, Agent Registry, and Agent Gateway. The central idea of Agent Identity is that you can assign every AI agent a unique cryptographic identity. Google also announced Agent Simulation, Agent Evaluation, and Agent Observability. Evals are as important to LLM apps as unit tests are to current software development. Observability is of course more important than ever, given we need to understand outputs and behaviours in production.

Google’s Dev Rel team did a solid job explaining how all of these tools play together in a demo during the developer keynote on day two – with a scenario of planning a marathon in Las Vegas. Each step in the development process was outlined and explained during the keynote.

For example a demo featuring Agent Studio – a collaborative workspace for building new agents. Key to the demo flow as whole was making it clear that different tools will be used by different personae, including “low code” developers using natural language, people living in markdown for specs, specs that cover business rules, not just software guardrails. Prebuilt agents include code modernisation, financial analysis, and deep research.

We’re going to see a lot more marketing around agent capability from platform providers as agents become more capable and widely deployed – indeed it’s pretty much the 2026 summer keynote.

The agent permission, security and identity play

With agents you have a bunch of autonomous systems using non-deterministic models to try and achieve outcomes. These agents are capable of taking action – sometimes very bad actions, such as deleting production databases. They absolutely need guardrails, and a markdown file just isn’t going to cut it. That’s where tools like Agent Identity come in. Permissions will need to be tightly managed. Role based access control (RBAC) will be essential for this agent buildout. But things are made even more challenging because most agents are ephemeral. RBAC systems were built for employees, and perhaps contractors, not agents you spin up and dispose of in minutes. New scale challenges everywhere you look.

Simon Willison coined the phrase the lethal trifecta:

• Access to your private data—one of the most common purposes of tools in the first place!
• Exposure to untrusted content—any mechanism by which text (or images) controlled by a malicious attacker could become available to your LLM
• The ability to externally communicate in a way that could be used to steal your data (I often call this “exfiltration” but I’m not confident that term is widely understood.)

“If your agent combines these three features, an attacker can easily trick it into accessing your private data and sending it to that attacker.”

Threats are growing all the time, partly because the tools are so powerful. Take OpenClaw, for example, designed as an AI personal assistant, arguably the fastest growing open source project in software history. OpenClaw reached 250,000 GitHub stars in about 60 days, surpassing React, which took over a decade to reach the same milestone. OpenClaw drove a spike in Mac mini sales as developers clamoured to use the software with a modicum of safety. The project went from launch to explosive growth to acquisition by OpenAI in about three months. Peter Steinberger, the lead developer, is now at the forefront of the movement to create agents that can do a range of tasks on behalf of the individual. For now it’s a developer play, but in the longer term it will be for enterprise users as well. It is a capable autonomous agent, built for messaging and integration to third party systems. But deploying it on your corporate network without a huge amount of supporting security infrastructure would be extremely foolish. It’s definitely not ready for the enterprise at this point. It’s simply too powerful as a lethal trifecta accelerant.

Agent sprawl drives the need for orchestration platforms

Orchestration platforms are increasingly a necessity because software developers are using teams of autonomous agents, sometimes working in parallel, but requiring asynchronous communication for handoffs and state management (memory) in the service of tasks and workflows.

This pattern reminds me of the evolution of containers and microservices. The container revolution began with devs running Docker locally on their laptop. As complexity compounded we needed an orchestration layer to manage all of these containers in production, which is how Kubernetes came into being. We’re now at a similar point with agents.

Agents as the primary driver of scale

Agents also drive much higher scale requirements. Look around the industry and you can see existing players and startups crushing it, or being crushed by, agent generated workloads. GitHub’s reliability issues are being exacerbated by agent-based software growth. There’s just so much software being built. Just look at Jarred Sumner of OpenAI, who just rewrote the entire Bun Javascript runtime in Rust, replacing the Zig implementation. One million lines of Rust code, all AI-generated. Regenerated is probably a better word than rewritten. Open Source projects are like Doctor Who now. Across the industry there are thousands of Sumners, also building huge code bases and new applications at an entirely new speed.

Token Economics and the Full AI Stack

Being an end to end stack player matters because it means you’re in control of costs of goods sold. You’re not reliant on third parties to serve customers, which is a clear economic advantage.

Control of cost is so important because the future of AI is going to be defined by token economics – that is, who can offer the greatest range of capabilities at the lowest cost. Anthropic and OpenAI are both going to raise prices in order to meet their sky high valuations. In recent months it’s become clear that the cheap token era is ending, even as some developers crow about “tokenmaxxing” as a badge of honour or productivity.

OpenAI and Anthropic need third parties to provide chips – NVIDIA. They also need cloud providers to provide compute, network and storage – business for the hyperscalers, as well as Coreweave and to some extent racle. Meanwhile AWS, Azure and GitHub are reliant on OpenAI and Anthropic (and their eye-watering balance sheets) to provide frontier models and associated services to their customers.

Owning a capable first party model is a crucial competitive advantage. At Next 2026 Google Cloud CEO Thomas Kurian announced that Google Gemini would be powering the next generation of Apple’s Siri service – see my post about it here. Gemini is now powering both Siri and AI services on Android phones worldwide — an almost incredible cloud win, given it covers most new phones being sold in the two key mobile ecosystems. Neither AWS nor Microsoft Azure could have won this deal given their reliance on third-party models.

What about the lower level stuff? Google has its TPU microprocessor architecture, which means that it’s not reliant on NVIDIA. AWS and Microsoft are investing in their own architectures optimised for model training. AWS will likely get there with Trainium, given the engineering process of its chip business – Graviton for general compute has been, and will continue to be, a huge differentiator for AWS as it seeks to lower the cost of compute for customers.

Google labelled its hardware advantage the AI Hypercomputer but we’ll largely stick to the agent story for the purposes of this post. It’s enough to say that AI is very specific in terms of compute patterns, and that’s why being in control of technology up and down the stack matters. And we haven’t even talked about the fact that Google Cloud also has a huge installed base of customers using its productivity tools. There is so much upside potential for integrations there.

But let’s cut to the chase. Enterprises are not going to take seriously the proposition that they should spend thousands of dollars per week per developer or agent. That’s not going to fly in Illinois, let alone Nairobi, Paris or Jakarta. I am old enough to remember enterprises balking at paying an extra $30 per calendar month per user for GitHub Copilot. So thousands of dollars per developer just seems unlikely at this point. Model choice is going to become more important, in this environment.

Data, Context and the new Knowledge Management

Data was the first business that Google Cloud landed in the enterprise, with companies making deep and strategic bets on Big Query, seeing Google as their “data cloud”. This beachhead is now increasingly realising gains in the AI space.

Google is world class at managing, and managed databases – Spanner is a globally distributed database offering near absolute transaction guarantees. It’s unique. It’s also increasingly appropriate for AI workloads, with multimodel capabilities including Spanner Graph, vector search and built-in full-text search. Google also offers Postgres in a couple of flavours, and Valkey for caching. You can have CloudSQL for MySQL if you’re looking for it, and for those so inclined of course you can get managed Oracle databases.

So what did Google announce at Next in the data space, to build on these strengths?

The key announcements were about what Google is calling the Agentic Data Cloud – key components of which are Knowledge Catalog, the cross-cloud Datalake, and the Agent Data Kit (meeting devs where they are, ensuring that Claude Code, Codex etc can do a solid job of accessing Google data services).

The Knowledge Catalog is essentially an AI-maintained index of all your enterprise data, structured so agents can actually use it. This is a modern, AI-inflected take on the classic Knowledge Management projects of the early web era.  We’re talking about Ontology with a capital O again.

Yasmeen Ahmad, managing director of Agentic Data Cloud at Google Cloud, is one of the best communicators in the industry. She introduced the data infrastructure section of the keynote, bringing the announcements to life with… Frozen Yoghurt. Yep – not a holiday booking, or revamping a camping company e-commerce site, but Froyo.

When you’re a food retailer you want to make sure you can meet people’s dietary needs – gluten and dairy free are both growth markets. Allergy information however might all be in a bunch of PDFs – it’s classic unstructured data, or what Ahmad calls dark data.

So what if the system identifies potential allergens? That’s new knowledge you can take advantage of for product management. So AI has enriched the knowledge catalog. But then you want to correlate that with a bunch of customer information about allergies. That might be in your system of record. But what if that database was hosted in AWS?

With Google’s Cross Cloud Datalake you can access data directly in third party clouds, using the Apache Iceberg standard. Finally you want to query the data before making a new product decision, so you use your favourite agent, and it’s ready to provide the correct answers based on your enterprise data via the Agent Data Kit. Great demo.

So the idea is that first you build a Knowledge Catalog. You don’t even build it. AI does.

I talked to Andi Gutmans, who runs Google’s data infrastructure and storage businesses. He said that humans are not going to be able to scale to the amount of data and events we’re talking about. Ontology is going to have to be machine learning based. Given the failure of Ontology efforts in corporations over the last few decades, partly because it’s just a hassle to annotate enterprise data with technologies like RDF, it would be hard to argue with him. Ontology, he argued, is actually an agent problem, so he has put together an “AI forward team to work on enrichment”.

The product design goal is essentially smart storage – a file lands, it’s instantly tagged, enriched and made agent ready. Every file or interaction should help the model learn about your business semantics. That’s where valuable context comes in. Google cited Virgin Media O2 as an early customer of the Knowledge Catalog, which it’s using across 20k different assets.

Of course you need a really good search engine on top of that ontology. Apparently Google has some proprietary search technology that is quite good.

We keep coming back to this question of human scale vs the scale that agents are going to drive. What does it look like to run an infrastructure business when a swarm of agents at a customer are going to spin up a hundred thousand databases in an hour and tear them all down again?

This is key to how Gutmans is architecting Google’s data products – agents take action, they don’t just make enquiries. Gutmans said Google Cloud is therefore now working towards an expectation of customers managing zettabytes rather than exabytes. Agents driving unprecedented data scale, just as they drive the need for compute, and transactions.

Rebuilding in flight

One thing I can’t stop thinking about that Andi told me:

“Now – I need to rebuild a lot of stuff we built a year ago.”

That’s the point. Everything – literally everything, is now about rebuilding in flight. You need to update your priors every day with AI, agent, and LLM progress, and that often means restarting projects because they simply don’t meet the new requirements. For an enterprise software business this is super hard. There are new product management disciplines required when the targets are moving so fast. This is going to find out a lot of companies, which are going to struggle with this rate of change and how to manage it. The days of ship it and then run it for the next decade are behind us. And if you don’t have an incredibly solid foundational platform, making these changes is all the more risky.

Related to this is the need to meet customers where they are. If enterprises thought shadow IT was hard, just wait til they start getting their heads around the new rates of tool adoption.

In a conversation at Next Peder Ulander, VP of marketing said:

“Years ago you could say here is an enterprise tool, and here is what you use at home.
It used to be – find a tool you like to work with, and maybe bring it into work two years later. Now it’s now the next year, it’s the next day.”

That’s the reality, and it’s a reality that agents are only accelerating. The tools are more capable than ever, the opportunities to improve business processes using autonomous agents is increasingly clear. People aren’t going to wait for traditional enterprise sales cycles to start using the tools. Vendors are going to need to respond with strong product led growth plays from the bottom up, supported with the usual large deal size top down procurement. The market is moving incredibly quickly, and Google Cloud is very well positioned for the agent era.

During his Google Cloud Next 26 keynote CEO Thomas Kurian said:

“We’re collaborating with Apple as their preferred cloud provider to develop the next generation of Apple Foundation Models based on Gemini technology. These models will now power future Apple Intelligence features including a more personalized Siri coming later this year.”

This is a big deal. This news didn’t come from Apple, which is notoriously tight lipped about such things. There wasn’t a press release about it. But assuming it’s true, and there absolutely no reason to doubt Kurian, then its worth considering what it means.

Pretty much every phone on the planet is going to be powered by Google Gemini AI going forward – certainly Android services will be, and this now bring iPhones into the mix. This is an almost absurdly great position for Google to be in, as AI moves out to the edge.

Every phone on the planet. That’s potentially billions of devices.

As we know, model preferences are far from sticky. They change day to day. Who knows what Apple will be using in 2027 or 2028? Model choices change quickly, but rolling these changes out at Apple ecosystem scale would be no mean feat. A ton of things would break. And Apple actually building its own frontier model based on Gemini – that does feel kind of sticky. Over the longer term Apple will very likely build and lead with its own model. But it certainly took a while for Apple to make Maps competitive, for example, after its initial use of Google Maps. Google Search is still the default on Apple devices (to be fair Google pays for this privilege, but I believe the point stands.) This is a landmark win for Google Cloud.

There are all sorts of questions – not least architectural. Will Siri be running AI with local models, maybe something like Google Gemma, or is it about Siri’s back end running on Google Cloud with Gemma. Is this actually a client side win, or a cloud win. Given Apple’s strict approaches around privacy one assumes there will be a local component. Plenty to unpick though.

Nobody chooses a model for life. But for this era of AI service buildout Gemini powering Siri is very notable. It’s a huge cloud win whichever way you look at it, and frankly neither AWS or Microsoft Azure could have done so, if it was based on owning a competitive frontier model. Unlike Google they lead with third party models.

I will be watching Google I/O closely next week to put this into further context.

disclosure: Google Cloud is a client, and paid for my T&E to the event.

This year’s theme was “Prepping Craft” – in a world where safety and normality are slipping away, how do we make our code, our communities, and our lives truly resilient? I loved the topic when I first heard it, and it’s only become more urgent by the day. – Alex Chan

In a moment when institutional trust is declining, political environments are hostile, and the open source ecosystem is under genuine strain, a conference that centers human connection, psychological safety and community resilience isn’t a nice-to-have. It’s a model for what the industry needs more of. – Alyx McQueen

Monkigras is my favourite conference of the year, sorry to all the other conference friends I have, and it is not even truly my industry. Every year the conference has a theme and this year’s is about being prepared. – Dave Letorey

“Listening to inspiring speakers from around the world helped me understand how to navigate challenges—both as an individual and within a community. I also had the opportunity to gain different perspectives from experienced professionals in tech and individuals working in tech-related fields. Hearing their journeys and insights really broadened my thinking and inspired me to keep growing.” – Rahwa Haile

So I guess we did OK, then. Monki Gras 2026 was a couple of weeks ago. The feedback from delegates was lovely. The theme this year was “Prepping Craft” — examining what it means to be prepared for whatever comes next, technically and culturally. What it means to be prepared: for the impact of AI on the industry, for geopolitical uncertainty, for the challenge of product rollouts, for (distributed) systems failure. We explored strategies, tools, and philosophies that make people, communities, products, and platforms safer and more resilient. All of the quotes above and below are from blog posts about the conference. They’re all well worth a read! 

I would like to thank all my amazing speakers:

Laura Tacho kicked off with a clear eyed view on data versus hype, considering what is going on in the AI and generative coding space. Anna Hevesi asked how we win in the age of robots. Ashley Rolfmore made the case that trust has to come before truth when building explainable AI systems. Sue Smith raised the question of whether our fingers still remember how to code as we become increasingly reliant on AI tooling. Liz Fong-Jones brought something deeply personal and important about rights generally and trans rights specifically— what do you do when you may need to change up your citizenship? After lunch, Hazel Weakly got intentional — about her life and how she crafts herself. Daniel Roe took us into the world of the npmx project, but also atproto, federation, and resilience in open source. Holly Cummins and Sanne Grinovero tackled the open source bus number problem – what happens if something happens to your key project maintainers? Finally Adrian Cockcroft made the case that resilience requires conscious observability, which in many respects was a talk for what you need to do to prepare for a long and successful career. 

Day two pushed the prepper theme further. Danilo Campos prepared us for unimaginable change – and a world of abundance in energy and cognition (have you ever considered just how magical it is that you can simply flush a toilet?). Chad Metcalf shared his own story as a the owner of an old gold mine near Yosemite in California. Adam Zimman offered a trans guide for CIS parents. Heidi Waterhouse and Kim Harrison looked at resilience in communities, highlighting work in Minneapolis and Oaxaca. Matt LeMay closed things out by reframing how we plan for uncertainty itself. We closed things out with a book signing with the Progressive Delivery crew.

Another important word – a huge and epic thank you to our sponsors – you can’t run an event like this without the help of amazing sponsors. We live in capitalism, and we need to appreciate that.

• Bishop & Dinner: AWS (the cheese mountain, oysters, and amazing Indian food)
• Abbot: Heroku by Salesforce
• Dean & Diversity and Inclusion: Oracle
• Ops: Chronosphere
• Lunch: PostHog (Turkish on day one, Vietnamese on day two). 
• Buy a Round: Dynatrace, The CNCF, Betty Junod
• Amazing Coffee: MongoDB, GitLab (amazing coffee from Scenery coffee roasters, served by the excellent people at Handles).

Many thanks to Dan McGeady, my production manager, Handsome Rob on beer and beverage operations, and their respective teams. Jessica West for being my spar. To Elena Barker, our D&I manager (amazing job!) And of course our incredible designer Gail Myerscough – her take on punch cards really pulled the whole event together. She is open for commissions, does brilliant design work, is flexible and works really quickly.

So let’s close out for now with some more commentary from delegates, because really it’s their conference after all.

I’d barely set foot into the venue when James introduced me to Elena Barker from Code Your Future to enlist me as a mentor for the folk coming along under the auspices of the diversity & inclusion programme. It was a real pleasure to meet some of the participants and talk about how we’re all on a learning journey. Working with early career folk has been one of the highlights of Atsign over the past five years, so this was a chance to chat with some similarly talented and enthusiastic people. – Chris Swan. 

I think many would agree – these were two days full of pure joy. No clichés, no repetitive speeches – just unique, thoughtful and often deeply personal talks. At times, it was emotional for both speakers and the audience, and that’s exactly what made it so special. In a world that often feels uncertain, this space reminds you it’s okay to feel, reflect and connect. – Elena Barker.

The talks themselves covered everything from AI hype versus real data to resilience engineering and the future of software careers. Some sessions were technically deep, while others were unexpectedly personal. I loved the mix of technical depth and humanity. Sessions from speakers like Liz Fong-Jones and Hazel Weakly weren’t just about systems and resilience they were about people, responsibility, and the realities behind the work we ship every day – Hawwah Okunmoyimbo

What’s better than a conference that combines TED talks with beer? Two conferences! Monktoberfest in the autumn and Monki Gras six months later in the spring. This year’s Monki Gras was my first. Open source wouldn’t exist without its community, and Monki Gras brings together some of the brightest minds in that domain. – Tarus Balog

I was writing this post today when the news dropped that Cursor has just raised a new round.  

> We’re pleased to announce a new round of financing: our Series D of $2.3B at a $29.3B post-money valuation. We’re excited to deepen our work with existing investors, including Accel, Thrive, Andreessen Horowitz, and DST, and welcome new partners Coatue, NVIDIA, and Google. 

Now I am old enough to remember when a company that approached a VC to say they were raising money for a dev tools startup would have been laughed at. Obviously that was a different time, but raising $2.3bn on a VS Code fork/Claude Sonnet wrapper is quite impressive all the same, no matter how great the developer experience is. Cursor is excellent software to be fair.

So what does The Eclipse Foundation have to do with this? It’s not the first name you think of when considering organisations supporting the current wave of innovation in AI tooling? I mean wasn’t Eclipse that open source Java IDE from the 1990s and 2000s? Yes it absolutely was, but the Foundation has continued to support the standardisation of open technologies, and find new niches (like automotive) to fill. [It’s also worth mentioning, though not the subject of this post, the excellent work the foundation is doing in corralling other open source foundations around security, for example helping them to come to terms with the implications of the European Cyber Resiliency Act. Further side note – if you build software you absolutely have to start paying attention to the CRA.]  

Open VSX, an Eclipse Foundation project, is an open source registry of extensions for VS Code compatible editors such as Cursor and Windsurf and vibe coding tools including Bolt.

Microsoft’s position is pretty clear – you can’t use the VS Code Marketplace to enable or support products outside the Visual Studio family. So while, for example, VSCodium is a community-driven, MIT-licensed distro of VS Code, which third parties can build on, they can’t take advantage of the official marketplace. VSCodium uses Open VSX registry as its default extension marketplace, as do most other VS Code forks. 

Microsoft has been fairly benign about forks of VS Code until quite recently, but with the huge success of the Cursor fork of VS Code it has begun to bare its teeth. Dion Almaer wrote about the forking issue, and Microsoft’s approach to it here.

> I want healthy competition. I want VSCode to open up more extension points so anyone can build great experiences without having to fork. I want changes to the marketplace rules so it can be more open. I want companies to be able to work together via open source so we can all gain from the rising tide (a la Chromium++).

> We are going through such an explosion in the world of development thanks to AI and the surfaces where we get to use it.

> What will be next? Will the companies with chess pieces on the board make moves that can help all? As developers what is our role to play? We can be clear on what we want to see… and we can adopt the tools that tie to our values.

Open VSX will be part of any pushback to Microsoft efforts to regain control of the situation. Amazon Web Services adopted Open VSX as the default registry for its Kiro AI IDE, which is another big win for the project. AWS recently announced it’s investing to support the Eclipse Foundation accordingly. So yes, Open VSX is in an interesting place.

As I wrote recently – Editors are up for Grabs– and the Eclipse Foundation is supporting this innovation and choice.

For those of you that are IT history enjoyers one significant irony of all of this is the original Eclipse IDE was written by Erich Gamma. He also just happens to be the original lead on the VS Code project, which began as Project Monaco, a web-based IDE in 2011. He’s still the key figurehead behind it. So an organisation founded to support a project that he wrote 25 years ago is now becoming a counterweight to what he later built at Microsoft – VS Code, one of the most successful and well-loved code editors of all time. What a towering influence Gamma has been on the world of developer tools. He really is the GOAT.

Disclosure: AWS, The Eclipse Foundation and Microsoft are all clients. 

It’s been a long time coming but the book has finally shipped. I am super proud to have worked with my co-authors Adam Zimman, Heidi Waterhouse, and Kimberly Harrison to deliver something that I think is going to be really useful to people. I can’t think of a better publisher than IT Revolution. I mean if you’re in the same stable as Accelerate and The Phoenix Project, you know you’re doing something right.

We wanted a strong analytical framework and great case studies and that’s exactly what we’ve got. We also wanted to cast a fresh eye on engineering and product management disciplines, putting the user first but really thinking about the business of software delivery and how to improve it. In the book for example we think about the third loop. It’s not enough just to have dev and ops. You also need the user in the frame. So much of the foundational work in defining modern software delivery was established before we had the world’s computing resources at our fingertips in the cloud. Before we had infrastructure as code as a guiding principle. Before we could really model and accurately codify every single element in our IT estate. Before we had accepted the primacy, even, of engineering and software developers in delivering new digital products. Before we could do real user monitoring. Before we could easily do dark launches using purpose built platforms. Before observability had brought all of the signals together that we would need to build, operate and iterate more effectively. We therefore established a framework based on the world as it is now, and the new requirements and capabilities, based on 4 key tenets – Abundance, Automation, Alignment and Autonomy. The past is a different country and the new country is progressive delivery.

Good business books need great case studies. And to that end we did really well. To have engineers from Amazon Web Services, GitHub, Sumo Logic, and Nike share knowledge and experience with us about the way they had built systems that put the user first, that would enable them to roll new services out to specific cohorts in controlled ways before broader rollouts, reliably, safely and quickly. Yeah that was super exciting and we’re so glad that we were able to include them in the book.

At its core, Progressive Delivery exists to serve a fundamental purpose that can be distilled into a simple yet powerful statement: delivering what users need when they need it at the least cost and risk to everyone involved.

This is perhaps the manifesto of Progressive Delivery—not a description of its methods but a declaration of its ultimate goal. It captures the essence of what we’re trying to achieve when we implement these practices. By keeping this goal at the forefront of our thinking, we create a clear criterion against which all of our technical decisions, organizational structures, and delivery practices can be measured.

When we center our work on this purpose, we naturally align our teams, our technologies, and our processes toward creating value rather than just producing output. It transforms software delivery from the mechanical process of shipping features to a thoughtful practice of providing solutions that genuinely help people accomplish their goals.”

– Progressive Delivery: Build the Right Thing for the Right People at the Right Time.

So Progressive Delivery is partly about developer and team autonomy, supporting alignment with the business. But it’s also very much about user needs. One of the great advantages of abundance is that we can run multiple versions of applications and services, and in some cases let the user decide when they’re ready to migrate to a new service. We need to put the user’s needs first. Now of course, great design and great product management are about bringing the user on a journey, and helping them find and enjoy new ways of working and playing. But jerking them around is not the way to do it.

So yeah, I’m pretty excited about the book. If you’re building digital products and services it will give you some important food for thought, and perhaps make you rethink some of your assumptions. Copies are available at Amazon and even book stores, which feels pretty wild. When you read it please review it too – that would be super helpful in getting the word out!

If you’d like to discuss Progressive Delivery, or have me or one of my co authors present these ideas at your conference or event please let me know.

It’s been nearly two years since Broadcom acquired VMware, and a turbulent two years at that. There has been plenty of disruption. Customers and partners have both been fairly vocal about business model changes. But as renewal deals have been signed things have calmed down for now. I recently talked to Prashanth Shenoy, vice president of product marketing in the VMware Cloud Foundation (VCF) Division of Broadcom about what’s going on with the integration, and what we can expect in future. 

 A few things really stood out in this interview:

1. Clarity.  The way Shenoy communicates what’s going on is really admirable. It’s well worth watching the video and/or reading the entire transcript because of that. His thoughts are well structured and very clear.
2. Continuity. Prashant repeatedly makes clear that in fact a lot of the changes that have been made since the acquisition were already in play with VMware. The difference is that Broadcom tore off the band-aid. Broadcom made a dramatic shift, but the direction of travel was already in place. It’s not like Broadcom came in and threw away everything that VMware was doing. It just moved more aggressively and with more clarity.
3. Chutzpah. Considering all the sound and fury about the acquisition, it was interesting to have Shenoy straight out argue that VCF lowered prices. As a VMware customer, industry commentator, partner, or competitor you will be surprised to hear that. But Prashant went there and made the claim that the biggest difference is the transition to subscription-based pricing and that in some cases there were reductions over what you would have paid for the equivalent VMware offerings. Bold moves and bold claims. 

Shenoy challenged me about the industry at large and the transition to subscription-based pricing – frankly he’s absolutely right that we live in a subscription rather than a perpetual license economy. These transitions are indeed painful. Adobe for example got in there fairly early – customers still complain about the transition to a subscription-based model, but Adobe’s growth since the decision shows it was merited.

Here’s his take on on “price cuts”.

In fact, when we had our subscription product for VCF, it was $700 per core per year. And we cut it down for $350 per core per year, the list price, right? Which is a 50% reduction. So, the contrary to popular belief that we raised the price, we actually decreased the price. But there was a shift from perpetual to subscription. 

One big theme of the conversation, and indeed the raison d’etre for VCF is portfolio simplification – he said that before the acquisition VMware had 9,000 SKUs for its cloud infrastructure product. It is absolutely inarguable that the VMware portfolio had become complicated, unwieldy, and messy. It needed to be simplified. There had been so many acquisitions, so many overlaps born of strategic shifts, that it was hard to fully grasp the portfolio. Tanzu for example started as a container platform, before it became a grab bag of technologies.

So, we went ahead and simplified the product based on what the customer wanted. give me a platform that truly helps me give a strong alternative to public cloud, like a true private cloud platform, right? And that was VCF. So, that’s where we focused our energy and intention. Portfolio simplification.

 A lot of our customers now understand the value that the platform provides. In fact, we’ve seen some major improvements in the total cost of ownership once they go through the Capex hurdle. And we have seen a lot of our customers move their workloads, including the modern workloads, containerized workloads, onto VCF to run their business. So, it’s been a pretty exciting transformation, but with its bumps. We could have done a lot better in terms of communicating why we did this and bringing the customer along. But we were so fast in making the changes that it caused some disruption in the market.”

Certainly true. Change management is hard.

One area where VMware is in excellent shape is in data, infrastructure, and operational sovereignty. The market has moved its way decisively. Global geopolitics has pushed sovereignty right to the top of enterprise IT concerns in 2025, certainly in Europe and also to some extent Asia Pac. If private cloud seemed like a luxury that only truly made sense for regulated industries, now it seems more like a luxury not to be hedging with private cloud bets. And that’s of course where VMware has been investing and building. We also spoke a fair bit about personae. Shenoy said VCF caters to three key personae – the cloud admin, the platform engineer, and the developer who doesn’t even want to think about underlying services. 

What do these apps look like? Enterprises want to drive value with new AI-based applications, but they’re really concerned about compliance, privacy, and security. 

How can we help customers move at the pace of AI, pace of software, pace of what the developer needs? Those are the kind of customers that we are truly helping to work with to provide them a platform, the private cloud platform, on which they can run their business for both their containerized application as well as the VM application.

When it comes to AI, one question I had was about GPUs. Don’t we live in a cloud-based GPU world now? What can Broadcom offer customers there? Well – apparently some enterprises are indeed buying their own GPUs, and Shenoy argues that virtualisation capabilities are more important than ever.

So Broadcom has a platform called Private AI Foundation that it built jointly with NVIDIA – which is designed to allow enterprises the most efficiency for the GPU hardware they buy, with 25 years of innovation behind it – dynamic resource scheduling, v-motion etc. Inference and training require high performance, and high speed data connectivity.

One of the key, again, misconceptions in the industry has been like, hey, you can run all these AI workloads on bare metal. If you look at all of the hyperscalers, they don’t necessarily run it on bare metal. They have a Linux kernel that they run on top of. It’s the same thing with us, too. We run it on top of ESX, which is our hypervisor. And all of the capabilities of virtualization that we built in also comes along with that. So, when we have run performance benchmarks with MLPerf, we’ve seen pretty much VCF and vSphere retaining 99% of the performance of a bare metal with all of the other virtualization capabilities that I just talked about.

For more about the simplification around VCF and Tanzu I again suggest you watch the video or read the transcript. How Broadcom decided what was infrastructure and what were application services as containers and VMs collided, given the application and PaaS services in its portfolio. VCF now includes Kubernetes runtime services, but not the higher level services.

Before signing off I have to mention customer feelings, which are still running hot. We’ll see over the next few years how things settle down, especially as renewals come up again. The competition, notably IBM, is very focused on competing more head to head with VMware. Hyperscalers too sense opportunity, sovereignty issues notwithstanding. 

But Broadcom is absolutely crushing it from a revenue and share price perspective. Remaining employees are certainly happy with their options. And the portfolio and messaging are a lot more straightforward. VCF is a marker. It was a good conversation. 

disclosure: VMware is a customer and sponsored the video. IBM is also a customer.