mkdev
417 subscribers
861 photos
179 videos
1.12K links
Download Telegram
A Kubernetes security audit should do more than point at problems. We review your cluster hands-on, work with your team to understand the real setup, and deliver practical recommendations you can actually put into the backlog. Check out the page and schedule a call: https://mkdev.me/b/audits/kubernetes-security-audit
Getting traffic into EKS on Fargate can feel confusing until you see how the pieces connect.

This video walks through how a Kubernetes Ingress can automatically create an AWS Application Load Balancer, route traffic to your service, and expose your app to the outside world.

Watch it here: https://www.youtube.com/watch?v=cRODPz9GXb0
In the 90th mkdev dispatch Leo weights in on Anthropic's CEO recent comments about the state of the future white-collar jobs market. Subscribe for our bi-weekly newsletter all about Cloud, DevOps and AI! https://mkdev.me/posts/was-dario-amodei-right-90
A lot of engineers jump straight into containers and cloud platforms without ever building a clear mental model of virtualization. But the basics still matter.

Why can one physical machine run many isolated systems?
Why does KVM still show up everywhere in Linux infrastructure?
And why do tools like libvirt still matter when you want a sane way to manage VMs?

If you understand host, guest, hypervisor, and where KVM fits, a lot of modern infrastructure starts making more sense. This article does a good job covering those fundamentals through the lens of KVM. Still very relevant in 2026, especially for anyone touching Linux hosts, VM performance, or infra automation: https://mkdev.me/posts/virtualization-basics-and-an-introduction-to-kvm
If your teams use ChatGPT, AI analytics, screening tools, or any AI-powered workflow, AI literacy is now part of doing business responsibly. We offer practical training to help teams understand AI, ask better questions, and avoid costly mistakes. Check out the page and book training: https://mkdev.me/b/consulting/ai-literacy
A useful way to think about the EU AI Act’s literacy requirement:

This is not really about making everyone an AI expert. It’s about making sure people in your company know:

– what AI tools they are using
– where those tools help
– where they can fail
– what should never be pasted into them
– when human judgment still matters

That’s the difference between “we gave everyone access to AI” and “we actually built a company that can use AI safely.”

Read more: https://mkdev.me/posts/the-carrot-and-stick-of-the-eu-ai-act-s-literacy-requirements-benefits-compliance-and-risks
Kubernetes resource management is not about throwing apps into a cluster and hoping the scheduler is smart enough to figure it out. If you don’t set requests and limits correctly, you’re not doing capacity planning — you’re planting time bombs.

This article explains what actually matters: QoS, autoscaling, node capacity, and why Kubernetes is not what many people think it is. Read it here: https://mkdev.me/posts/kubernetes-capacity-and-resource-management-it-s-not-what-you-think-it-is
These case studies highlight the work we’ve done for our clients and how our partnerships progressed from the initial contact to implementation. Check them out: https://mkdev.me/b/cases
One of the most useful cloud cost questions in 2026 is still: “Am I paying for compute, or am I paying for idle time?”

That is especially relevant for background jobs. Lambda is billed by execution duration in 1 ms increments. Fargate is billed per second with a 1-minute minimum. So even when container compute looks attractive on paper, the economics can flip fast for short async tasks that do not run continuously. The result: background processing is often less about raw price and more about matching the billing model to the workload pattern.

This mkdev piece explains the tradeoff really well: https://mkdev.me/posts/processing-background-jobs-on-aws-lambda-vs-ecs-vs-ecs-fargate
Before adding more AWS services, make sure the ones you already use are the right ones. mkdev’s In-Depth AWS Audit and Assessment reviews your setup hands-on and delivers clear recommendations your team can actually act on. Check out the page and schedule a call: https://mkdev.me/b/audits/in-depth-aws-audit-and-assessment
GenAI can absolutely speed up development. But speed without guardrails is just a faster way to ship risk.

A good reminder from this mkdev piece: the biggest GenAI security problems are not exotic. They’re familiar engineering failures showing up in new places — leaking sensitive data into copilots, accepting insecure code suggestions, trusting model output too much, and pulling in dependencies no one properly checked.

The teams getting real value from GenAI in 2026 are not the ones “vibe coding” the hardest. They’re the ones adding review, least privilege, dependency scanning, and security-aware prompting into the workflow. GenAI is useful. Blind trust isn’t.

Read the article: https://mkdev.me/posts/don-t-let-cyber-risk-kill-your-genai-vibe-a-developer-s-guide
In the 91st mkdev dispatch Pablo comments on the recent news about Mythos and Anthropic’s Glasswing project. Also inside: what Claude actually chooses, building fault-tolerant applications with AWS Lambda durable functions and more!

https://mkdev.me/posts/anthropic-s-glasswing-project-91
A useful rule for modern platform teams: choose job execution systems based on ecosystem fit, not just feature lists.

If your delivery workflows already live inside GitLab, GitLab CI will usually make more sense than bolting on something separate. If you need Python-defined workflow orchestration for batch pipelines, Airflow is still a natural fit. If your goal is self-service operational automation across infrastructure, Rundeck is solving a different problem entirely.

Tool comparisons get a lot simpler when you stop asking “Which platform does more?” and start asking “Which platform fits our operating model best?” Great reminder from this mkdev piece: https://mkdev.me/posts/job-execution-systems-what-is-the-difference-between-jenkins-rundeck-airflow-gitlab-ci-and-others
The hard part of Kubernetes is not only the cluster itself, but everything around it: isolation, access control, deployment automation, secrets, monitoring, and building a platform developers actually enjoy using. That’s where mkdev comes in. Check out the page and schedule a call: https://mkdev.me/b/consulting/kubernetes
AI often feels like magic. That is part of what makes it exciting. A model can find patterns we did not notice, generate answers we did not expect, and solve problems that previously looked too complex to automate.

But magic is a very poor foundation for accountability. The moment an AI system affects someone’s rights, money, health, safety, or future opportunities, the black box becomes a problem. People do not just need an answer. They need a way to understand, question, and evaluate that answer.

The article introduces a useful idea: the “Sherlock Explanation”. A good explanation should make the AI decision feel understandable after the fact, not by pretending the system is simple, but by giving the right person the right level of insight into what happened.

That is a much higher bar than adding a generic explanation box to a product. Real explainability has to be faithful, useful, and adapted to the context in which the AI is being used.

https://mkdev.me/posts/explaining-ai-explainability-vision-reality-and-regulation
Need logs or metrics with Kubernetes context? The Downward API exposes pod metadata like labels, namespace or node name to containers via env vars or mounted files. Small feature, very practical use cases. Read the mkdev article: https://mkdev.me/posts/what-is-kubernetes-downward-api-and-why-you-might-need-it
“Can Config Connector replace Terraform?” That’s the tempting question. Google Cloud Config Connector lets you manage Google Cloud resources through Kubernetes: you define cloud infrastructure as custom resources, apply them with kubectl, and let controllers reconcile the real cloud state with the desired state.

For Kubernetes-heavy teams, this is attractive. One control plane, one declarative model, and one familiar workflow for both applications and infrastructure. But the moment you try to use it as the foundation for everything, the practical problems appear.

First: who creates the cluster that runs Config Connector? Something still has to bootstrap the GKE cluster, IAM setup, project configuration, service accounts, and supporting resources. In many setups, that “something” is still Terraform.

Second: cloud resources are not always as flexible as Kubernetes manifests make them feel. Some fields are immutable, and changing them is not always a simple kubectl apply. You may need to delete and recreate resources, or use abandon/acquire workflows.

So Config Connector is not a bad idea. Quite the opposite: it is a powerful operational model for teams already deep into Kubernetes. But it is not a magic replacement for every IaC workflow. The better question is not “Terraform or Config Connector?” It is: where does Kubernetes-style reconciliation make infrastructure simpler, and where does it add another layer of complexity?

Pablo’s thoughts on the matter: https://mkdev.me/posts/is-google-cloud-config-connector-the-solution
Is your Google Cloud setup actually helping your product, or just adding complexity? mkdev’s GCP Audit reviews security, cost, availability, automation and DevOps practices, then turns findings into concrete backlog items. Check out the page and schedule a call: https://mkdev.me/b/audits/google-cloud-platform