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

If you are still treating container hosts like normal servers, this video is for you. We walk through Fedora CoreOS, immutable infrastructure, automated updates, and boot-time config with Ignition. Give it a watch: https://www.youtube.com/watch?v=ddTHK6Oed_Q

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

Get familiar with the core concepts of OpenShift 4 cluster management, from the new installation experience to the essential capabilities that define the platform. Our free course as a series of articles: https://mkdev.me/posts/production-openshift-cluster-in-35-minutes-first-look-at-okd-4-and-the-new-openshift-installer

And in video form: https://www.youtube.com/playlist?list=PLozcbFx8FoPGM-Dk1jVBu58pwUGP9WGIX

“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

Want to make your client database connections to PostgreSQL a bit more secure? In this short video, we share a simple trick you can try in your setup: https://www.youtube.com/watch?v=Y1lsbF9NWW0

In the 92nd mkdev dispatch Kirill explains why AWS ECS Express Mode is a dissapointment. Subscribe to our bi-weekly newsletter where we talk about all things DevOps, Cloud and AI: https://mkdev.me/posts/aws-ecs-express-mode-is-a-dissapointment-92

The natural evolution of server management usually looks like this: first, you SSH into one machine and install everything manually. Then you save the commands into shell scripts. Then you add staging, production, load balancers, databases, monitoring agents, firewalls, SSH hardening and user accounts.

And suddenly your “simple scripts” become a pile of infrastructure folklore.

Configuration management tools solve this by moving from “run these commands” to “this is the state the server should be in.” The tool figures out what needs to change and can safely re-apply the configuration again and again.

That last part matters a lot. Infrastructure is not configured once. It drifts. People patch things manually. Emergency fixes happen. Defaults change. Compliance requirements evolve. In 2026, configuration management is still relevant because drift is still real.

Whether you use Ansible, Puppet, Chef or another tool, the core idea remains the same: make infrastructure configuration repeatable, reviewable and recoverable.

More in the mkdev article: https://mkdev.me/posts/what-is-configuration-management-and-why-you-need-ansible-chef-puppet-and-others

Your customers should never be your monitoring system.

mkdev helps teams move from basic alerts to real observability: telemetry, tracing, debugging, and alerts that notify the right people without creating noise.

Check out the page and schedule a call: https://mkdev.me/b/consulting/observability

AI explainability is not one problem. It is several problems wearing the same name.

A data scientist wants to know why a model behaves a certain way. A business leader wants to know whether the system creates value without unacceptable risk. A user wants to know whether they can rely on the output. An affected person wants to know whether they can challenge a decision. A regulator wants to know whether the company can demonstrate compliance and accountability.

The same explanation will not satisfy all of them.

This is why businesses need to treat explainability as part of AI system design, not as a marketing feature. Before choosing a model or buying a vendor solution, teams should define who needs explanations, what decisions need to be explained, and whether those explanations are meant for debugging, trust, consent, appeal, or liability.

In 2026, “AI explainability” should not be a checkbox. It should be a business requirement with clear stakeholders and clear limits.

https://mkdev.me/posts/explaining-ai-explainability-the-current-reality-for-businesses

Service Mesh can make developers’ lives easier — but it’s not magic dust for every Kubernetes setup. It shines when services talk to each other a lot, and when teams agree what should be handled by infrastructure and what should stay in code.

Read the article: https://mkdev.me/posts/do-developers-need-service-mesh

Love mkdev illustrations? You can now get many of them on t-shirts, mugs, and other items in the mkdev store — including some exclusive designs you won’t find anywhere else.

DevOps and Cloud swag, the mkdev way. Shop the mkdev store now: https://store.mkdev.me/#!/all