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

A better AI model doesn’t automatically make a better AI product. Kirill Shirinkin looks at why Grok Bot feels unusually easy to use, from its simple Bot concept and built-in computers to multi-account plugins and smoother browser interactions. He also looks at where the product still falls short.

Read the full article to see what Grok Bot gets right about building AI agents people might actually want to use: https://mkdev.me/posts/grok-bot-is-a-better-product-than-openclaw-and-hermes-agent

Unexpected cloud bills rarely come from one dramatic mistake. Often it’s a resource nobody noticed, a test project that kept running, or a small recurring charge that quietly became a large one.

Google Cloud gives you the tools to investigate these costs by project, service and SKU, while budgets and alerts can flag unusual spending before it turns into an unpleasant invoice. But knowing where the money goes is only the first step. The harder part is deciding which costs are justified, which can be reduced, and how to prevent the same waste from coming back.

That’s where a deeper look at your cloud environment can pay off. At mkdev, we help companies analyse their Google Cloud infrastructure, uncover unnecessary spending and identify practical opportunities for optimisation without compromising reliability.

Our article is a good place to start. And if you want to go beyond the billing dashboard, take a look at our Google Cloud Audit & Assessment and talk to us about what could be improved in your setup: https://mkdev.me/posts/understand-your-google-cloud-costs-billing-cost-management-and-budgets

Kubernetes gives you plenty of control. The downside is that you also get plenty of infrastructure to manage.

EKS with Fargate removes one part of that equation: the worker nodes. You can let AWS provision compute for selected Pods instead of maintaining EC2 capacity, scaling node groups, or worrying about idle worker capacity. Fargate profiles let you decide which workloads use this model and which stay elsewhere in the cluster.

It isn’t a replacement for every EKS workload, and restrictions around things like DaemonSets, privileged containers and storage still matter. But for the right applications, it can make the Kubernetes data plane considerably simpler.

We took a practical look at how it works in this mkdev article: https://mkdev.me/posts/serverless-kubernetes-with-aws-eks-and-fargate

Access to the Docker daemon is effectively root-level access, and writable bind mounts can expose the host. This video demonstrates why that matters. It was recorded back in 2020, but the core security lesson still holds in 2026. Watch the video: https://www.youtube.com/watch?v=sT9Q2xZr4nk

Want to get comfortable with Helm without committing to a huge course?

Our free Helm Lightning Course covers charts, releases, templates, values, hooks, dependencies and practical plugins through short, hands-on lessons.

Go through the course for free in article of video form.

Articles: https://mkdev.me/posts/why-do-you-even-need-helm
Video: https://www.youtube.com/playlist?list=PLozcbFx8FoPHqL9Gm1IpboF45gekmgYjO

Splitting a Terraform project into smaller states shouldn't mean recreating existing infrastructure. But the recommended way to migrate resources between states has changed.

While our article demonstrates the older terraform state mv approach, modern Terraform recommends using removed and import blocks instead. This makes migrations more explicit, reviewable, and manageable through the usual plan/apply workflow.

The underlying principles haven't changed, though. Read our article to understand how Terraform state migrations work and what's happening behind the commands: https://mkdev.me/posts/terraform-migrating-components-between-state-files

Not every cloud problem needs another cloud service. Sometimes you need someone to question your architecture, untangle your automation and explain your bill.

That's where we come in. Discover our approach and book a chat: https://mkdev.me/b/consulting/public-cloud

Please don't build an enterprise-wide AI platform before you've figured out what your first AI products actually need.

It's tempting to invest in sophisticated infrastructure, hire a large AI team, and automate everything from day one. But you're making expensive decisions based on problems you haven't encountered yet.

Start with a real business problem. Experiment, get something into production, measure its impact, and learn what it takes to maintain it. Then repeat.

Once you've demonstrated consistent value across multiple AI products, you'll have a much better understanding of what infrastructure and organizational changes are actually worth investing in.

Our AI Strategy Guide explores why the timing of your investments matters just as much as the technology you choose.

Read it here: https://mkdev.me/posts/ai-strategy-guide-how-to-scale-ai-across-your-business

Kubernetes, containers, serverless and cloud platforms may get more attention today, but virtual machines never disappeared underneath them.

KVM is a good example. Almost 10 years after we published this introduction, it remains an actively developed part of the Linux virtualization stack.

If you want to go back to the layer below much of modern infrastructure, revisit our introduction to virtualization and KVM: https://mkdev.me/posts/virtualization-basics-and-an-introduction-to-kvm

In the 100th mkdev dispatch, Pablo takes a look back at all previous dispatches and two years of rapid change in AI, software development, coding agents, infrastructure, and the way tech teams work: https://mkdev.me/posts/what-the-hell-happened-to-it-in-the-last-100-100

Reserved Instances ask you to make quite a few decisions about what your infrastructure will look like in the future.

Compute Savings Plans mostly ask a simpler question: how much AWS compute spend are you confident will still be there?

In return for committing to that hourly spend for one or three years, AWS can automatically apply discounted pricing across eligible EC2, Fargate, and Lambda usage.

That flexibility still makes Compute Savings Plans worth considering in 2026. But the difficult part isn't buying one. It's choosing a commitment that still makes sense after your next round of cost optimization.

We took a closer look at how to approach that decision in this article: https://mkdev.me/posts/aws-compute-savings-plans-are-they-right-for-you

AWS has hundreds of services. You probably don’t need most of them. You may also be paying too much for the ones you do need.

We’ll go through your AWS setup, challenge the choices that deserve challenging, and give you a concrete backlog of improvements.

Let’s inspect the cloud: https://mkdev.me/b/audits/in-depth-aws-audit-and-assessment

Running EKS workloads on Fargate removes a lot of node management, but your applications still need a way to receive traffic.

For HTTP and HTTPS workloads, an Application Load Balancer can be provisioned from a Kubernetes Ingress and route traffic directly to your pods. With Fargate, the important detail is using the ip target type, since there are no worker nodes to register as ALB targets.

The tooling has evolved since this walkthrough was written — today you’d use the AWS Load Balancer Controller — but the underlying networking model is still very relevant.

Our article walks through how the pieces fit together, from Ingress and target groups to an internet-facing ALB: https://mkdev.me/posts/getting-traffic-to-eks-using-alb-ingress-controller-with-amazon-eks-on-fargate

A lot has changed in AWS since 2021, but the core idea still holds: put an Application Load Balancer in front of ECS Fargate tasks and use target groups + health checks to route traffic.

This video shows the original setup — and where the old workflow differs today. Watch it: https://www.youtube.com/watch?v=YH8y-oKIpIY

More secure identity management, no delays to critical projects, and more engineering space for the internal team.

That was the goal of our work with Multiverse Computing. We helped move existing users to a managed identity solution, integrate it into their platform, and prepare the system for future expansion.

See how the project came together in the full case study: https://mkdev.me/b/cases/mvc-case-study

CI/CD has changed a lot, but the problem it solves hasn’t.

We moved from manual deployments to shell scripts, then Jenkins and other CI servers, containers, Kubernetes and now increasingly declarative GitOps workflows. The tools keep evolving, but the goal remains the same: make the path from code to production repeatable, testable and reliable.

Pablo’s “Majestic Pipeline” article looks back at that evolution and at the principles that still matter in 2026.

Read the full story: https://mkdev.me/posts/majestic-pipeline-a-ci-cd-love-story

Your data lake shouldn't be a swamp.

Messy pipelines, scattered data, and AI projects going nowhere? Sounds like your data infrastructure needs some attention.

Let's clean up the mess together: https://mkdev.me/b/consulting/data-engineering