Do AI Agents Need "New" Containers? | ✉️ #95
Hey! 👋
It seems like every cloud provider - and Kubernetes SIG - are trying to come up with new execution layer for AI Agents to operate in. AWS released Lambda MicroVMs, Kubernetes is working on Agent Sandbox, whole new agent-first cloud providers are popping out. It is true, that modern AI Agents need some place to run in. I would rather prefer to use Claude Code only via their cloud instances, instead of relying on my local machine. And complex multi-step AI workflow to require additional platform capabilities.
But are we just re-branding something the industry was doing anyway, but now under an AI agenda? Ever since Kubernetes appeared, the industry worked towards standard, extensible way to run containerised, properly isolated workloads - with each workload (or container) having it’s own boundaries, whether networking or compute-related. Every CI/CD system, that is, every job execution system, solves the problem of “creating compute environments for one particular job at a time” in one way or another, be it Gitlab CI Runners, GitHub Actions Runners, Jenkins dynamic build nodes, or even tools like Airflow, that are focused on solving an entirely different problem, but are, essentially, all structured in the same way.
Of course, AI Agents need to be put in containers, from where they can only access what they should access - but should we really frame this as an entirely new problem? Isolated compute environments for AI are just isolated compute environments, with a new powerful flavor of software running inside them. The rest seems to be more of a marketing game, to sell the “containers with extra AI-specific capabilities” as an entirely new dimension of infrastructure.
This goes separate, of course, from AI agents using the cloud themselves, one example being Temporary CloudFlare Accounts for AI. In those cases, we do need to re-think how we operate our cloud workloads, or rather, how do we expose our clouds to AI Agents in a safe and productive way.
And as for putting AI Agents inside the boxes, we’ve prepared something nice for you: a ready-to-use Terraform module to completely shift your GitHub Actions to be running inside Lambda MicroVMs. Get the module here, and read the full article about this project here.
What We've Shared
- Using Lambda MicroVMs as GitHub Actions Runners: Explore how AWS Lambda MicroVMs can run ephemeral GitHub Actions self-hosted runners with per-second billing, strong job isolation, VPC access and no idle costs—and deploy the complete serverless CI/CD setup with Terraform.
What We've Discovered
How I Dropped Our Production Database and Now Pay 10% More for AWS: A great example of the dangers of trusting Claude Code a bit too much in an environment that did't have many best practices implemented in the first place. Good, that it turned out fine and AWS had some backups on their end! When you delete everything in your account, it doesn't mean AWS actually deleted everything.
Track Amazon Bedrock Costs by Caller Identity with IAM Principal-Based Cost Allocation: One of the downsides of Bedrock is no built-in tracking of who is causing the costs.
spinel Creator of Ruby language released a tool that can compile Ruby programs into standalone executables. This could be a game changer for Ruby world, as the compiled executable is times faster and can be distributed similarly to how you'd distribute software written in Go, for example. But does it really work for real apps and tools?
Drunk Post: Things I’ve Learned as a Senior Engineer. This was originally posted on HN back in 2021, and now re-posted by someone else with original author being god knows where. Crazy how despite a whole 4 years of AI frenzy, almost everything written there is still so so true and valid today.
The 96th mkdev dispatch will arrive on Friday, July 31st. See you next time!