Logs, metrics and traces are only part of observability.

The real goal is understanding what happened, tracing problems across systems and making sure the right people get the right alerts — without alert fatigue.

Take a look at mkdev’s approach and arrange a call with us: https://mkdev.me/b/consulting/observability

AI explainability is easy to underestimate when AI is used for small, everyday tasks. If a model recommends the wrong article, produces a weak summary, or gives a slightly strange answer, the consequences are usually limited. We may be annoyed, but we can move on.

The problem begins when AI becomes part of decisions that people cannot simply ignore. A loan application, an insurance claim, a medical recommendation, a hiring process, a court case, or an autonomous system failure all create a very different expectation. In those situations, people need more than an output. They need a way to understand what influenced it, whether it was fair, and whether it can be challenged.

That is why AI explainability should not be treated as decoration around a model. A nice paragraph next to a prediction may improve the interface, but it does not automatically create accountability. The explanation has to match the decision, the risk, and the person who needs to use it.

As regulation catches up with AI adoption, companies will have to think about explainability much earlier in the product lifecycle. Not after deployment, not only when lawyers ask for it, and not as a checkbox. It has to be part of how AI systems are designed, tested, documented, and governed.

https://mkdev.me/posts/explaining-ai-explainability-vision-reality-and-regulation

Back in 2023, we tested AWS App Runner as a simpler way to deploy containers without managing all the usual infrastructure around ECS.

In 2026, App Runner is closed to new customers and AWS recommends ECS Express Mode instead. Watch the video to see where the idea worked — and where it didn’t: https://www.youtube.com/watch?v=E6E6HtrLs98

If you’re one of our Spanish-speaking subscribers and want to dive into containers, we have a free video course for you!

It covers Docker, docker-compose, Docker Swarm, Podman, Buildah, Firecracker and more — all in Spanish and completely free: https://www.youtube.com/playlist?list=PLNXwhzx0-DmRlCz9lKPLRWdv5visGlNNT

Cloud lock-in isn’t only about proprietary APIs and managed services.

Economics can create lock-in too.

Historically, one of the clearest examples was data egress: getting data into a cloud was often cheap or free, while getting large amounts of it back out could become expensive.

In 2026, the picture is changing. AWS, Google Cloud and Azure all offer programs that waive eligible egress charges when customers completely migrate away. In the EU, the Data Act has already started changing the rules around cloud switching, with switching charges due to be fully prohibited from January 2027.

But there is an important distinction: making it cheaper to leave a cloud does not mean data transfer itself has become free.

Applications still generate network costs between zones, regions, services and the public internet. Those costs can influence architecture just as much as compute or storage pricing.

The cloud is becoming easier to leave. Understanding the cost of moving data while you are still there remains just as important.

https://mkdev.me/posts/the-biggest-cloud-scam

Misconfigured RBAC, weak network policies or poorly managed secrets can leave a Kubernetes cluster exposed.

Our In-Depth Kubernetes Security Audit helps uncover these risks and gives your team a practical path to address them. Explore the audit and talk to us about your setup: https://mkdev.me/b/audits/kubernetes-security-audit

There are really two different problems hiding behind the term “AI explainability.”

The first is understanding how a model behaves in general. Global explainability methods can tell us which features tend to matter across a population and are particularly useful for developers who want to understand or debug a model.

The second is explaining one particular decision. Why was this loan application rejected? Why did this model produce this prediction? Local explainability methods such as LIME and SHAP try to answer those questions by building simpler approximations around individual cases.

The distinction matters because a population-level explanation doesn't necessarily tell you why something happened to one person. And a local approximation, however useful, isn't the same thing as opening up the original black box.

Explainability therefore isn't one technology solving one problem. It's a collection of approaches with different strengths, limitations, audiences and purposes.

We explored these questions in our article on AI explainability, and the distinction remains an important one for businesses working with increasingly complex AI systems: https://mkdev.me/posts/explaining-ai-explainability-the-current-reality-for-businesses

If Linux networking still feels like a collection of mysterious interfaces and commands, this one is worth revisiting.

Learn how teaming, Linux Bridge, tap interfaces and Traffic Control work together for fault tolerance and bandwidth management.

Read more: https://mkdev.me/posts/how-networks-work-part-two-teaming-for-fault-tolerance-bandwidth-management-with-traffic-control-tap-interfaces-and-linux-bridge

In the 97th mkdev dispatch Kirill explains the role Terraform has in this new age of AI agents. Also inside: AWS fast networking, Aurora DSQL pricing and more!

https://mkdev.me/posts/terraform-in-the-ai-agents-age-97

Imagine Google Cloud tells you you're spending roughly €500 a year on something you don't remember creating.

The obvious next step is to open FinOps Hub. You can inspect recommendations, look for potential savings and check where the spending is coming from.

But then you discover that the cost isn't an application server at all. It's infrastructure created to provide VPC connectivity for Cloud Run.

That's where the interesting part of FinOps starts.

Today, Direct VPC egress is Google's recommended approach for many Cloud Run workloads and avoids the compute cost of running Serverless VPC Access connector instances. It's a small architectural change that can remove an entire category of unnecessary spending.

We walk through this example, along with FinOps Hub, CUDs, cost allocation and billing analysis, in our Google Cloud FinOps article.

https://mkdev.me/posts/gcp-finops-hub-the-key-to-mastering-your-finances-on-google-cloud

CI/CD, infrastructure as code, Kubernetes and observability are powerful building blocks. Platform Engineering is about turning them into a coherent experience that helps teams ship efficiently at scale.

Read about our approach to Platform Engineering and arrange a call to discuss your setup: https://mkdev.me/b/consulting/platform-engineering