mkdev

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

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

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

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

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

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

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

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

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

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