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

A surprising number of AWS accounts still run without the basic cost-management features fully enabled.

No hourly cost visibility. No resource-level data. No meaningful budgets. No anomaly alerts. No regular review of rightsizing recommendations.

Then the bill arrives, and everyone starts investigating backwards.

The better approach is simple: set up the cost observability layer before you need it. Enable Cost Explorer. Add granular data where it makes sense. Use Cost Optimization Hub and Compute Optimizer for recommendations. Configure AWS Budgets. Turn on Cost Anomaly Detection.

These steps will not replace a proper AWS audit, but they create the minimum visibility needed to make good decisions. Cloud bills should not be a monthly surprise. They should be a monitored system.

Details in the article: https://mkdev.me/posts/getting-started-with-aws-cost-optimization-6-steps-to-get-the-cloud-bill-under-control

Running Kubernetes on-prem, in the cloud, or both? mkdev’s Kubernetes Audit & Assessment looks at operations, security, service mesh, observability, capacity and how your apps can actually benefit from Kubernetes. Check out the page and schedule a call: https://mkdev.me/b/audits/kubernetes-audit-assessment

AI image generation becomes much more interesting when you stop thinking about it as a standalone feature. The model is only one part of the system. The rest is context management, iteration, file handling, parameters, quality checks, and the ability to repeat the process without losing your mind.

That’s what this article is about. Kirill took Nano Banana Pro, later added GPT Image 2, and wrapped both into Claude Code Skills. This allowed Claude Code to generate images through a small Python script, inspect the outputs, notice problems, and continue improving the result.

For product teams, this is where the practical value starts. You can brainstorm app icons, create mascot variations, generate high-resolution visuals, localize screenshots, and explore many directions without manually restarting the process every time.

The broader lesson is simple: AI tools become dramatically more useful when they are connected to real workflows. The future is not just “better prompts”. It is small, composable tools that let AI agents actually do the work around the model.

Read the full post here: https://mkdev.me/posts/unlimited-image-generation-with-nano-banana-pro-gpt-image-2-and-claude-code-skills

Want to pass the Certified Kubernetes Administrator exam?

Don’t try to memorize Kubernetes. Learn how it works, practice real tasks, master kubectl, reuse YAML when possible, and make sure your basic Linux skills are solid.

This video explains 6 simple but important tips that can save you time during the exam.

Watch the full video and prepare smarter:

https://www.youtube.com/watch?v=Hk07gXekQ1c

A lot has changed in cloud security. The basics have not.

AI workloads, Kubernetes platforms, multi-cloud setups, serverless services, and managed databases all add complexity. But the same core questions still decide whether your environment is reasonably secure:

Who has access? What data is sensitive? What is encrypted? What is logged? Who owns each security responsibility? How often are settings reviewed? What happens during an incident?

That is exactly what a good cloud security checklist should force you to answer.

We put together 7 essential steps for reducing cloud security risk, from data classification and IAM to monitoring, automated audits, and tested response plans.

If your cloud setup has grown faster than your security process, this is a good place to start.

https://mkdev.me/posts/cloud-security-checklist-7-essential-steps

Good infrastructure code should be like good application code: clear, tested, versioned and automatically deployed.

That’s the mindset behind mkdev’s Infrastructure as Code & GitOps consulting.

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

Prompt engineering is not security engineering.

This is one of the hardest lessons for product managers building with GenAI. A system prompt may look like a clean set of rules, but it is not the same as traditional application logic. It does not guarantee behavior. It is more like a very strongly worded suggestion to the model.

That matters when your AI feature is exposed to users. A customer-facing assistant might be told not to reveal sensitive data, not to generate illegal content, not to override company policies, and not to take dangerous actions. But malicious users can still try to bypass those instructions through jailbreaks or prompt injection attacks.

The business impact is not theoretical. A badly controlled AI system can create reputational damage, legal exposure, data leakage, or operational incidents. For PMs, that means AI features need proper boundaries beyond “we wrote a careful prompt.”

Good GenAI product management means asking: What can the model access? What actions can it trigger? What happens if the user tries to manipulate it? What checks exist outside the model itself?

We covered the practical risks product managers should understand in this article.

Read it here: https://mkdev.me/posts/genai-security-risks-for-product-managers-dd73bdc2-4f2e-4227-93b3-375da081d906