If Linux networking still feels like a collection of mysterious interfaces and commands, this one is worth revisiting.

Learn how teaming, Linux Bridge, tap interfaces and Traffic Control work together for fault tolerance and bandwidth management.

Read more: https://mkdev.me/posts/how-networks-work-part-two-teaming-for-fault-tolerance-bandwidth-management-with-traffic-control-tap-interfaces-and-linux-bridge

In the 97th mkdev dispatch Kirill explains the role Terraform has in this new age of AI agents. Also inside: AWS fast networking, Aurora DSQL pricing and more!

https://mkdev.me/posts/terraform-in-the-ai-agents-age-97

Imagine Google Cloud tells you you're spending roughly €500 a year on something you don't remember creating.

The obvious next step is to open FinOps Hub. You can inspect recommendations, look for potential savings and check where the spending is coming from.

But then you discover that the cost isn't an application server at all. It's infrastructure created to provide VPC connectivity for Cloud Run.

That's where the interesting part of FinOps starts.

Today, Direct VPC egress is Google's recommended approach for many Cloud Run workloads and avoids the compute cost of running Serverless VPC Access connector instances. It's a small architectural change that can remove an entire category of unnecessary spending.

We walk through this example, along with FinOps Hub, CUDs, cost allocation and billing analysis, in our Google Cloud FinOps article.

https://mkdev.me/posts/gcp-finops-hub-the-key-to-mastering-your-finances-on-google-cloud

CI/CD, infrastructure as code, Kubernetes and observability are powerful building blocks. Platform Engineering is about turning them into a coherent experience that helps teams ship efficiently at scale.

Read about our approach to Platform Engineering and arrange a call to discuss your setup: https://mkdev.me/b/consulting/platform-engineering

The interesting part about modern image models might not be image quality anymore.

It’s iteration.

Generating one impressive image is easy. Generating 50 or 100 versions, remembering what you disliked about previous attempts, making targeted corrections and gradually converging on something useful is a different problem.

That’s why combining Claude Code with image-generation models turned out to be more interesting than simply using another image-generation UI.

Claude can maintain the context of the task and use Nano Banana Pro or GPT Image 2 as tools. It can look at the output, notice that an object is positioned strangely or that the result doesn’t quite satisfy the request, and take another shot.

That turns image generation from a sequence of isolated prompts into something closer to an iterative creative workflow.

We explored the approach in this article and made the skills public:
https://mkdev.me/posts/unlimited-image-generation-with-nano-banana-pro-gpt-image-2-and-claude-code-skills

A useful Cloud Run distinction:

Services → request-driven applications
Jobs → run-to-completion workloads

And when the workload can be divided, Cloud Run Jobs can execute multiple tasks in parallel.

We break down the idea with a practical example here: https://www.youtube.com/watch?v=n8GyTp-kP_M

Want to understand containers beyond Docker? Our free Dockerless course takes you through OCI, open container standards, and the fundamentals that make modern containers work.

Article series: https://mkdev.me/posts/what-s-wrong-with-docker-introduction-to-the-dockerless-course
Video: https://www.youtube.com/playlist?list=PLozcbFx8FoPH30kYPbPuPsvxASWoLo9XB

For a while, microservices felt like the inevitable destination of every serious application.

Then teams discovered the other side of the equation: more services also mean more network calls, more APIs, more deployments, more dependencies, and more opportunities for things to fail in ways that are difficult to reproduce locally.

Google’s Service Weaver experimented with an interesting alternative. Developers could structure a Go application as a set of components without immediately committing every component to a separate service. Deployment topology could be decided later.

Service Weaver didn’t become the future of application development, and the project has since been archived. But the problem it was trying to solve hasn’t disappeared.

The interesting part of Service Weaver in 2026 isn’t the framework itself. It’s the question it leaves behind: should our code architecture really be so tightly coupled to our deployment architecture?

https://mkdev.me/posts/service-weaver-monolithic-or-microservice

Using Google Cloud doesn't automatically mean you're using the right services in the right way.

Our GCP Audit helps uncover unnecessary costs, security gaps, reliability issues and opportunities to simplify your infrastructure.

Take a look at what we cover, and schedule a conversation with our team: https://mkdev.me/b/audits/google-cloud-platform

There are two GenAI security concepts that are easy to mix up: jailbreaks and prompt injection.

A jailbreak generally tries to make an AI system ignore its restrictions and produce something it shouldn’t.

Prompt injection can go further. The goal may be to manipulate an AI system into taking actions or accessing systems and data that the attacker should never be able to reach.

As GenAI gets connected to more tools, APIs, and business systems, that distinction becomes increasingly important. The potential consequences move from “the chatbot said something bad” to data leakage, compromised systems, and operational disruption.

Our guide explains these risks from a product manager’s perspective, alongside another major issue: how employees and users handle sensitive data with GenAI tools.

Read the full article on mkdev: https://mkdev.me/posts/genai-security-risks-for-product-managers-dd73bdc2-4f2e-4227-93b3-375da081d906

Kirill Shirinkin has spent decades across software development, infrastructure and DevOps. For nearly a decade, his own development setup barely changed.

Then AI arrived.

Now he shares what he’s learned from rebuilding his workflow around AI: how he works with coding agents, manages context, makes architecture decisions, organizes parallel work, automates reviews and deployments, and decides what should still remain firmly in the engineer’s hands. He also looks at the less glamorous side of working at AI speed: avoiding bad technical decisions, keeping projects under control, and staying sane when the amount of work you could do suddenly feels almost limitless.

https://mkdev.me/posts/the-agentic-engineering-myth-1-year-of-coding-with-ai

In the 98th mkdev dispatch, Pablo talks about how AI is creating a new digital divide where access to powerful tools depends not on infrastructure or skills, but on geography, provider restrictions, and permission to participate in the AI economy. Also inside: scaling Terraform across many Teams and more!

https://mkdev.me/posts/the-ai-divide-is-no-longer-about-access-to-the-internet-98

AWS gives you plenty of ways to analyze cloud spend, but the analysis is only as useful as the metadata behind it.

For smaller AWS setups, you don’t necessarily need an elaborate tagging framework. A simple baseline of environment, workload, and name can already make it much easier to understand which application or environment is responsible for a particular part of the bill.

Terraform’s default_tags can help apply that baseline consistently across supported resources. The other important step is easy to miss: tags need to be activated as Cost Allocation Tags before you can properly use them for cost analysis.

A relatively small amount of tagging discipline can make Cost Explorer considerably more useful.

Our article walks through a simple approach to getting started with AWS cost allocation tags: https://mkdev.me/posts/control-aws-costs-with-these-3-cost-allocation-tags

We’ve been using Infrastructure as Code for over a decade. The tools have changed, but the principle hasn’t: infrastructure should be understandable, version controlled, tested and automated.

Learn how we work and start a conversation: https://mkdev.me/b/consulting/iac

“Building an AI product? You need a vector database.”

Not necessarily.

Vector search is very good at questions where meaning matters: finding documents, descriptions or passages that are semantically similar to what a user asks. But businesses rarely ask purely semantic questions.

They ask things like: find relevant customer feedback from a particular product, during a particular period, from a particular market. Or identify similar insurance claims, but only for a specific vehicle type and coverage year.

Those questions mix fuzzy semantic meaning with very precise structured filters. And that is where the idea that one vector database will solve your entire retrieval problem starts to fall apart.

In 2026, with relational databases offering increasingly capable vector functionality and dedicated vector systems continuing to mature, choosing the right architecture is less about following the AI stack of the moment and more about understanding what your queries actually require.

We explore the problem in more detail here:
https://mkdev.me/posts/which-database-when-for-ai-are-vector-databases-all-you-need

Kirill Shirinkin handed GPT-6 Astra a long-postponed migration of mkdev.me from Ruby on Rails to Hugo and let it run with surprisingly little supervision. The result worked — but the path there was full of overengineering, impressive autonomy, missed details, and a few good lessons about what today’s most capable coding agents are actually like to work with: https://mkdev.me/posts/how-gpt-6-astra-killed-my-ruby-on-rails-app

When Babbel needed more engineering capacity without permanently expanding its infrastructure team, mkdev stepped in to tackle technical debt and cloud improvements alongside Babbel’s own engineers.

Among other things, we helped prepare the foundations for an AWS multi-account setup and refactored service-to-service communication, offloading 30% of traffic from a heavily used API Gateway.

Read the full case study to see how the collaboration worked and what changed under the hood: https://mkdev.me/b/cases/babbel-case-study

Moving to the cloud isn’t automatically modernization.

You can take the same inefficient architecture, move it from your own data center to AWS, Azure or GCP, and end up with the same problems plus a bigger bill.

The real advantages of cloud come from using it deliberately: elasticity where demand changes, managed services where they remove operational work, and infrastructure that can be provisioned when you actually need it.

Sometimes the right answer is cloud. Sometimes it’s on-premises. Increasingly, it’s a mixture of both.

More thoughts on when a cloud provider actually makes sense: https://mkdev.me/posts/should-i-use-a-cloud-provider

Running Kubernetes on-prem or in the cloud? Our audit covers your clusters, RBAC, networking, resource usage, observability and cloud native delivery processes. Check out the Kubernetes Audit & Assessment page and schedule a call: https://mkdev.me/b/audits/kubernetes-audit-assessment

Before adding another database to your AI stack, look at the one you already have.

If your application needs semantic search over free text, vector search can be a natural fit. If it needs exact dates, filters, joins or business rules, relational queries still do that job extremely well. And increasingly, you don’t necessarily have to choose between the two.

PostgreSQL + pgvector is one example of bringing semantic and structured search into the same system.

Our article looks at the trade-offs in practice, including where each approach works well — and where it starts to break down.

Read more: https://mkdev.me/posts/which-database-when-for-ai-vector-and-relational-databases-in-practice