Forem: Kiell Tampubolon

What's New in GKE at Next '26: Kubernetes Just Got Smarter (and Cheaper)

Kiell Tampubolon — Thu, 23 Apr 2026 14:01:43 +0000

This is a submission for the Google Cloud NEXT Writing Challenge

Kubernetes as the OS of the AI Era

At Google Cloud Next '26, Google made one thing pretty clear: Kubernetes is no longer just a container orchestrator. It's quickly becoming the operating system of the AI era.

The numbers speak for themselves. GKE now powers AI workloads for all of Google's top 50 customers on the platform, including the biggest frontier model builders out there. In just a few months, multi-agent AI workflows surged by 327%. On top of that, 66% of organizations now rely on Kubernetes to run their generative AI apps and agents.

This isn't just an incremental update. It's a real shift. And the GKE announcements at Next '26 reflect that change well. Here's a breakdown of what's new and why it actually matters for developers.

1. GKE Agent Sandbox: Secure, Scalable Agent Infrastructure

As AI moves from chatbots to fully autonomous agents running at massive scale, the underlying infrastructure needs to keep up with hundreds, sometimes thousands, of agents collaborating at the same time.

Google's answer to this is the GKE Agent Sandbox, which they're calling the industry's most scalable and low-latency agent infrastructure. It's built on gVisor kernel isolation (the same tech that secures Gemini), so you can safely run untrusted code, tools, and entire agents without giving up performance.

Key numbers:

300 sandboxes per second at sub-second latency
Up to 30% better price-performance on Axion compared to other hyperscale clouds

One real-world example: Lovable, a platform where builders spin up 200,000+ new projects every single day, runs its AI-generated apps in GKE Agent Sandboxes. The reason? Fast startup, fast scaling, and solid secure isolation.

What this means for you: If you're building multi-agent systems or executing untrusted user-generated code, Agent Sandbox takes away the painful choice between security and speed.

2. GKE Hypercluster: One Control Plane for Everything

Let's be honest, managing hundreds of disconnected Kubernetes clusters is a nightmare at scale.

GKE Hypercluster (now in private GA) tackles this head on by letting a single, Kubernetes-conformant GKE control plane manage 1 million chips across 256,000 nodes across multiple Google Cloud regions.

What makes it stand out is the security model. It uses Google's Titanium Intelligence Enclave, a software-hardened "no-admin-access" security engine. Your proprietary model weights and prompts stay cryptographically sealed from platform admins and infrastructure layers. That's a big deal for enterprise teams.

What this means for you: If you're running large-scale AI training across regions, you no longer have to deal with fragmented clusters. Your entire distributed infrastructure becomes one unified capacity reserve.

3. Supercharged Inference Performance: No More Months of Manual Tuning

Getting to state-of-the-art (SOTA) inference used to take months of painful performance tuning. GKE is changing that with two solid updates:

ML-Driven Predictive Latency Boost

The new feature inside GKE Inference Gateway uses real-time capacity-aware routing to cut time-to-first-token (TTFT) latency by up to 70%. No manual tuning needed. It just works.

Automatic KV Cache Storage Tiering

Smart tiering across RAM, Local SSD, and GCS/Lustre helps with long-context memory bottlenecks:

Offloading to RAM: 40%+ TTFT reduction and 50% throughput gain (for 10K prompt length)
Offloading to Local SSD: around 70% throughput improvement (for 50K prompt length)

These features are built on top of llm-d, which just became an official CNCF Sandbox project. GKE also integrates with NVIDIA Dynamo for scaling large Mixture-of-Experts (MoE) models.

What this means for you: You can go from deployment to frontier-grade inference in minutes instead of months. That's a huge deal.

4. Reinforcement Learning Enhancers: Stop Wasting GPU Time

RL is one of the biggest drivers of AI compute demand right now. But the problem is that RL jobs involve a lot of sequential processing, which leaves GPUs and TPUs just sitting idle between steps.

GKE is adding new native RL capabilities (currently in preview) to fix this:

RL Scheduler solves the "straggler effect" and inter-batch tail latency, keeping throughput high with intelligent routing
RL Sandbox gives you kernel-level isolation for tool-calling and reward evaluation at millisecond-scale provisioning
RL Observability and Reliability dashboards give you deep visibility out of the box to troubleshoot and optimize the whole RL loop

What this means for you: If you're doing RL training at scale, this is directly targeting the idle-time problem. Less idle time means lower costs. Simple as that.

5. Intent-Based Autoscaling: No More "Custom Metric Tax"

Scaling AI workloads on anything beyond basic CPU or memory has always been painful. You'd need complex monitoring setups, IAM management, and a dependency on external observability stacks that could fail at the worst moment.

GKE's new Intent-Based Autoscaling brings native custom metrics support to the Horizontal Pod Autoscaler (HPA):

Agentless architecture pulls metrics directly from Pods, no external dependencies needed
5x faster reaction time, dropping from 25 seconds down to just 5 seconds
If your external observability stack goes down, your autoscaling keeps running. No more cascade failures.

What this means for you: This one flies under the radar but it's honestly one of the more impactful updates. Scaling on what actually matters for your workload, not just CPU, is now genuinely easy and reliable.

My Take: One Clear Pattern

Looking at all five of these announcements together, there's a clear theme running through all of them: Google is making GKE the go-to platform for serious AI workloads, not by piling on new features, but by removing the friction that's been slowing developers down.

Agent Sandbox removes the security-vs-performance tradeoff
Hypercluster removes the cluster fragmentation headache
Inference optimizations remove months of manual tuning
RL Enhancers remove GPU idle waste
Intent-based autoscaling removes fragile external metric dependencies

Every single update is about taking something painful away.

For anyone who's been frustrated running AI workloads on Kubernetes, the Next '26 GKE updates feel like Google finally saying: we get it, and here's the fix.

Whether you're building multi-agent pipelines, serving frontier models, or doing RL training at scale, these updates are worth paying attention to, especially if cost and performance matter to you.

What do you think about these GKE updates? Are you already using any of them or planning to? Drop a comment, I'd love to know what you're building!

Building Secure PDF Automation in .NET: The Trade-offs Nobody Talks About

Kiell Tampubolon — Tue, 21 Apr 2026 14:44:40 +0000

Heads up: this article was originally published on Medium. I'm republishing it here for the Dev.to .NET community. Canonical link is set back to the original.

You are building a backend service that generates thousands of PDFs daily. Invoices with payment details. Account statements with transaction histories. Internal reports with employee information. Your stakeholders want it fast, scalable, and automated. Your compliance team wants it secure, auditable, and locked down.

Welcome to where developer convenience meets regulatory reality.

Over the past year, I have worked on several projects involving automated document generation in regulated environments: financial services, healthcare systems, and internal enterprise platforms. IronPDF served as the rendering engine in these .NET systems, not because it solved security by itself, but because it integrated cleanly into architectures designed around secure data handling.

This article walks through the practical trade-offs teams face when building PDF generation systems that handle sensitive data. Real patterns, real decisions.

Disclaimer: This is an engineering discussion based on real-world experience, not legal or compliance advice. Consult qualified counsel for regulatory requirements in your jurisdiction.

The Composite Scenario

Here is the kind of requirement set that keeps showing up:

The business need:

Generate 10,000+ PDFs per day (invoices, statements, reports)
Each document contains PII: names, addresses, account numbers
Sub 2 second generation time per document
Multiple templates and formats
Bulk generation for batch processes

The regulatory reality:

Data protection regulations apply (GDPR, CCPA, or similar)
Financial data must be encrypted at rest and in transit
Access to sensitive documents requires audit trails
Data retention policies must be enforced

The technical constraint:

Limited infrastructure budget
Small development team
Tight delivery timelines
Legacy system integration required

Sound familiar? This is the reality for many teams building document automation today.

Layer 1: Data Access and Retrieval

The first trade-off is speed against security granularity.

Real-time fetch per PDF gives you maximum security and always-current data, but it slows generation and puts load on the database. A cached data pool is faster and more predictable, but data sitting in memory adds compliance complexity.

Most teams end up with a hybrid:

Critical PII like SSNs and account numbers: always fetch fresh, never cache
Semi-sensitive data like names and addresses: short-lived cache, 5 to 15 minutes
Reference data: standard caching

The point is knowing which data warrants which treatment, and documenting those decisions for compliance reviews.

Layer 2: Template and Rendering Logic

Next trade-off: developer convenience against security boundaries.

Tight coupling (data directly in templates) is quick to build and easy to modify, but templates often end up with access to more than they should actually display. Strict separation via ViewModels requires more upfront work and verbose code, but gives you clear data flow and makes audits easier.

In practice, data projection before rendering works well:

// Simplified for clarity, production code needs additional error handling
var invoice = await _invoiceRepository.GetById(id);

// Project to template-specific DTO
var templateData = new InvoiceTemplate {
    InvoiceNumber = invoice.Number,
    CustomerName = invoice.Customer.Name,
    MaskedAccountNumber = MaskAccountNumber(invoice.AccountNumber)
    // Only include what the template actually needs
};

var pdf = _renderer.RenderRazorViewToPdf("InvoiceTemplate.cshtml", templateData);

This gives you clear boundaries between data access and rendering, easier field-level security rules, and better audit trails.

Layer 3: Document Security and Storage

Trade-off here: performance against security depth.

Plain PDFs with minimal security are fast to generate and retrieve, but anything that compromises storage exposes them directly. Maximum security with encryption and access control can be 3 to 5 times slower, plus key management complexity.

A tiered model works better than one-size-fits-all:

Tier 1: Highly sensitive (SSN, financial accounts)
├─ PDF password protection
├─ Encrypted storage
├─ Access logs per view
└─ Automatic expiration (30 to 90 days)

Tier 2: Moderately sensitive (invoices)
├─ Encrypted storage
├─ Authenticated access only
└─ Standard retention

Tier 3: Internal reports (aggregated data)
├─ Standard storage
└─ Basic access control

IronPDF makes password protection straightforward:

// Simplified, production needs proper key management
var pdf = _renderer.RenderHtmlAsPdf(htmlContent);

if (documentTier == SecurityTier.HighlySensitive) {
    pdf.Password = GenerateSecurePassword();
    pdf.SecuritySettings.AllowUserAnnotations = false;
    pdf.SecuritySettings.AllowUserCopyPasteContent = false;
}

await SaveWithEncryption(pdf, storageKey);

Not all documents need the same security level. Classify them and apply proportionate controls.

Layer 4: Access Control and Delivery

Final trade-off at the delivery layer: user convenience against audit completeness.

Permissive delivery (direct links) means minimal logging, which is fast but leaves you with untracked sharing and compliance gaps. Strict delivery (authenticated per-access) gives you a complete audit trail but at the cost of slower UX and more infrastructure.

Signed, time-limited URLs with access logging is usually the right balance:

// Simplified for clarity, production requires proper token validation
public async Task<DocumentAccessToken> GenerateAccessToken(
    string documentId,
    string userId,
    TimeSpan validity)
{
    await _auditLog.LogAccessRequest(documentId, userId);

    var token = new DocumentAccessToken {
        DocumentId = documentId,
        UserId = userId,
        ExpiresAt = DateTime.UtcNow.Add(validity),
        Signature = ComputeHMAC(documentId, userId, validity)
    };

    return token;
}

Users can download within a time window. You get a proper audit trail. Sharing the link randomly does not grant indefinite access.

The Hidden Trade-offs

Beyond the obvious technical decisions, a few subtler trade-offs keep catching teams off guard.

Automation speed vs incident response

Fast generation means fast mistakes. A data retrieval bug can expose thousands of documents before anyone notices.

Build for recoverability from day one. Document versioning, batch rollback, sampling validation in production, embedded tracking metadata in PDFs:

// Crucial for identifying affected documents during incidents
pdf.MetaData.Subject = $"Batch-{batchId}";
pdf.MetaData.Keywords = $"DataVersion:{dataVersion},Generated:{timestamp}";

Simplicity vs long-term risk management

"Just save PDFs to blob storage" seems simple until three years later when compliance asks: where is the data lineage, and how do you enforce deletion requests?

Design metadata schema for future compliance needs from the start. Generation timestamp, data sources, requesting user, security classification, scheduled deletion date, related entity IDs for deletion cascades.

Security theater vs real risk

Adding controls that look good on paper does not prevent logic bugs that expose PII.

Focus security effort where risks actually live:

Automated tests for PII leakage in templates
Code review on data access patterns
Monitoring for anomalous generation volumes
Developer security training

Make secure coding the path of least resistance, not an obstacle course.

A Decision Framework

When you are stuck on a trade-off call, a simple framework helps.

Step 1: Classify document risk

Risk = (Data Sensitivity) x (Access Scope) x (Retention Period)

High risk (>7): Financial accounts, medical PHI, SSN
Medium risk (4 to 7): Customer invoices, internal reports
Low risk (<4): Public reports, marketing materials

Step 2: Map trade-offs to risk

High risk: accept slower generation, implement per-document access control
Low risk: optimize for speed, use simple authentication

Step 3: Document the decision

Decision: Cache customer names for batch generation
Risk: Medium
Rationale: Names alone aren't highly sensitive. A 15-minute cache
           significantly improves batch performance.
Mitigations: Cache encryption, automatic invalidation.
Review: Q3 2026

This kind of decision log pays off during compliance reviews and team onboarding.

Lessons From the Trenches

Perfect security is the enemy of good security. Teams that try to implement every best practice end up with systems so complex nobody understands them, which leads to developer workarounds that bypass security entirely. Proportionate security based on actual risk, then iterate.

Compliance debt compounds faster than technical debt. That quick hack to meet a deadline does not just slow down development. It creates regulatory risk, potential fines, and legal liability. Treat security decisions as first-class architectural concerns from day one.

Observability is security. You cannot secure what you cannot see. Monitor document generation volume anomalies, failed access attempts, unusual document sizes, generation time spikes, and access pattern anomalies.

Clear mental models enable secure development. Developers make secure decisions when they understand what data is sensitive, where security boundaries exist, and how to implement controls correctly. Invest in training and documentation, not just tools and processes.

Implementation Checklist

Based on real project learnings:

Foundation (Week 1 to 2)

[ ] Document classification and security requirements mapped
[ ] Data access patterns and template strategy documented
[ ] Storage encryption approach selected

Core implementation (Week 3 to 6)

[ ] PDF rendering with proper error handling
[ ] Data projection layer (no direct entity access)
[ ] Document metadata schema and basic access control
[ ] Generation monitoring and logging

Security and production (Week 7 to 10)

[ ] Password protection and time-limited access tokens
[ ] Audit logging and deletion workflows
[ ] Security testing and performance validation
[ ] Incident response procedures and monitoring dashboards

Closing

Building document automation for sensitive data is fundamentally about making smart trade-offs. There is no perfect solution. Only solutions that fit your specific context, risk profile, and constraints.

Teams that succeed:

Acknowledge trade-offs explicitly rather than pretending they do not exist
Make decisions proportionate to actual risk
Document reasoning for future teams and compliance reviews
Build for evolution, knowing requirements will change
Focus on developer experience, because secure systems need developer buy-in

PDF libraries like IronPDF provide the building blocks. The architecture, the trade-offs, and the decisions are on us.

The goal is not perfection. It is building systems that are good enough to trust, simple enough to maintain, and flexible enough to evolve as regulations, threats, and business needs change.

If you are building secure document automation systems, I would love to hear what trade-offs you have encountered. Especially decisions that worked differently in your context.

Originally published on Medium.