Trying to reduce your Google Cloud Run costs?

Start with the less obvious places: VPC connectors, direct egress, and whether CPU really needs to be always allocated.

We explain both tips with a real billing example here: https://mkdev.me/posts/2-simple-tips-to-reduce-your-google-cloud-run-costs

This free course is all about understanding ArgoCD from the ground up. We will look at what ArgoCD does, why it matters, and how it organizes projects, applications, and deployments through its main features.

Articles: https://mkdev.me/posts/what-is-argo-cd-and-why-would-you-need-gitops
Video: https://www.youtube.com/playlist?list=PLozcbFx8FoPHUHoKfuSrkMO0ulZD-CHHu

At small scale, microservices feel manageable.

At larger scale, every service needs to find other services, communicate securely, expose useful telemetry, support traffic shifting, and follow consistent authorization rules. Doing this separately in every application quickly becomes a mess.

That is where service mesh comes in. It gives platform teams a common layer for service-to-service communication, usually through a control plane and a data plane made of proxies.

Google Cloud’s Anthos Service Mesh, now Cloud Service Mesh, is one way to bring this model into GKE. It can simplify parts of the operational story, especially if you want managed mesh capabilities. But it also introduces important tradeoffs around sidecars, Envoy, Istio APIs, GKE Dataplane V2, eBPF, and Cilium.

The article is a good reminder that “managed” does not mean “you do not need to understand it”.

In 2026, service mesh is still powerful. It is also still something you should adopt deliberately.

https://mkdev.me/posts/is-google-cloud-anthos-service-mesh-a-mess

Infrastructure problems rarely announce themselves early. mkdev audits look into your cloud, Kubernetes and security setup, identify what needs improvement, and turn it into a practical action plan for your team. Check out the page and schedule a call: https://mkdev.me/b/audits

ClickOps is annoying when you have one project. It becomes dangerous when you have many.

That applies to OpenAI as much as it applies to AWS, Kubernetes or any other infrastructure platform. Once you have multiple teams, multiple projects, service accounts, API keys, limits and access rules, manual configuration becomes a source of inconsistency.

The Open Source Terraform Provider for OpenAI was built around that problem. It brings OpenAI administration into Terraform, so teams can manage resources in code instead of relying on screenshots, tribal knowledge and “who created this key?” conversations.

There is also a more experimental side: using OpenAI platform APIs inside Terraform workflows, including model responses and image generation, and even combining them with cloud providers like AWS.

It is a fun example, but the larger point is serious: GenAI platforms need the same engineering discipline as the rest of your infrastructure.

https://mkdev.me/posts/announcing-the-open-source-terraform-provider-for-openai

Public IP, private IP, Cloud Run, Cloud SQL, Serverless VPC Connector… Google Cloud networking can get confusing fast. This video breaks down one practical setup step by step. Watch it now.

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

From DevOps and Cloud to AI: get the latest thoughts by Pablo and Kirill on all the news topics + a collection of personally curated interesting links, every other week in your Inbox! Subscribe to mkdev dispatch here: https://mkdev.me/categories/newsletter

Cloud cost optimization usually starts with quick wins: delete unused resources, rightsize oversized instances, clean up old snapshots, shut down non-production environments outside working hours, and add budget alerts.

But the bigger savings usually come later, when teams start treating cost as an architectural constraint.

That means choosing the right purchase model for steady workloads, using spot capacity where interruptions are acceptable, moving rarely accessed data to cheaper storage tiers, avoiding unnecessary cross-region traffic, and designing systems that scale with demand instead of running at peak capacity all the time.

The goal is not to spend as little as possible. The goal is to stop paying for waste while keeping reliability and performance where they need to be.

https://mkdev.me/posts/the-ultimate-guide-to-cloud-cost-optimization

Cloud projects don’t fail because AWS or GCP lack options. They fail because there are too many options, too many shortcuts and not enough clarity. mkdev helps teams design practical cloud solutions that fit their business. Check out the page and schedule a call: https://mkdev.me/b/consulting/public-cloud

A vector database can help your AI system understand “what the user means.” But your business probably also needs to know “which records are allowed,” “from which period,” “under which category,” and “according to which rules.”

That is why choosing a database for AI should not be a trend-driven decision. Vector databases, relational databases, NoSQL systems, and data warehouses all have their place. The difficult part is understanding where semantic search ends and structured retrieval begins.

The more serious the AI product, the more important this distinction becomes.

Before building another RAG prototype, it is worth asking whether the problem is actually semantic, structured, or a combination of both.

https://mkdev.me/posts/which-database-when-for-ai-are-vector-databases-all-you-need

Custom customer domains are a common SaaS feature, but SSL automation can become painful fast. This article shows how to handle it with Cloudflare, AWS ALB and a setup that can scale beyond a few domains. Read the full guide: https://mkdev.me/posts/how-to-setup-dynamic-customer-domains-with-ssl-cloudflare-and-aws-alb

Need practical cloud and AI knowledge?

mkdev webinars cover Google Cloud Run & Databases, AWS Load Balancer Controller 101, and Scaling AI Across Your Business.

Check them out and register here: https://mkdev.me/webinars

AWS Fargate is still one of the most practical ways to run containers on AWS when you want production infrastructure without managing EC2 instances, node groups, patching, or cluster capacity.

You still need to understand the pieces around it: ECR for the image, ECS task definitions for CPU, memory, ports and IAM roles, an Application Load Balancer for routing traffic, Route 53 or Cloud Map for service discovery, and CloudWatch for logs. Fargate removes server management, but it does not remove architecture.

This mkdev article walks through the full path using a simple Spring Boot application, from local build to a running ECS service behind a load balancer.

Useful if you want to understand what “serverless containers” actually means in AWS.

Read the article here: https://mkdev.me/posts/aws-fargate-101-run-production-applications-without-servers

Security audits should not end with a PDF nobody uses.

mkdev’s Kubernetes Security Audit combines interviews, hands-on cluster analysis and concrete recommendations, including backlog-ready user stories your team can actually act on.

Check out the page and schedule a call: https://mkdev.me/b/audits/kubernetes-security-audit

A lot of AI demos look impressive because they solve the easy part: getting a plausible answer from a small example.

The harder part comes later. How do you load the data reliably? How do you test the retrieval pipeline? How do you version the data? How do you handle access control, governance, and domain-specific terminology? How do you know that the system is still working next month, not just in today’s demo?

That is where the database choice starts to matter. A dedicated vector database may be excellent for fast experimentation, especially for pure semantic search. But if your company already has mature relational data, existing governance processes, and a team comfortable with SQL, jumping straight into a new vector database may create more complexity than value.

For many AI use cases, the best first step is not “add another database”. It is “look at what your current database can already do”.

That is less exciting than demo-ware, but much closer to production reality.

Read the article: https://mkdev.me/posts/which-database-when-for-ai-vector-and-relational-databases-in-practice

In this practical video, we deploy an HTTP-triggered Google Cloud Function using GitHub Actions instead of the UI or gcloud.

Push to main, run the pipeline, deploy the function, test it with curl.

Watch the video to see the full workflow: https://www.youtube.com/watch?v=B2VhvYZDXvM

In the 94th mkdev dispatch Kirill discusses the short rise and the quick fall of AI browsers development: https://mkdev.me/posts/ai-browsers-are-dead-94

There is no universal winner between Terraform and Pulumi.

For many companies, Terraform is still the safer default. It is familiar, widely adopted, easy to hire for, and well suited for teams that want infrastructure described in a predictable declarative format.

Pulumi shines in a different situation: when your infrastructure logic becomes too awkward to express cleanly in HCL. If you need complex conditionals, loops, reusable abstractions or developer-style testing, using a real programming language can be a big advantage.

But that advantage only matters if the team maintaining the infrastructure is comfortable with that language. Otherwise, you may just move the complexity from HCL into Python or TypeScript.

That is the real decision: not “which tool is better?”, but “which tool matches the way this team actually works?”

We covered the trade-offs in this article: https://mkdev.me/posts/should-you-use-terraform-or-pulumi

No two data science projects are the same.

mkdev works with your team to understand the problem, shape the right approach, and build a solution that fits your business. Check out the page and schedule a call: https://mkdev.me/b/consulting/data-science

AI output can be dangerously convincing because it often looks like the product of understanding.

A well-written answer feels intelligent. A clean summary feels reliable. A generated image feels intentional. A code snippet feels like it came from someone who knows the system. But the Generative AI Paradox shows why this impression can be misleading: models may create strong outputs without having the kind of understanding we usually associate with creation.

This distinction matters more in 2026 than it did two years ago. AI is now closer to daily business processes, internal knowledge bases, customer support, software delivery, and decision-making workflows. The cost of a wrong answer is no longer just a funny screenshot. It can become a broken process, a compliance issue, or a bad business decision.

So the real AI maturity question is not “are we using the latest model?” It is “do we know where the model fails, and have we built the system accordingly?”

https://mkdev.me/posts/is-ai-really-intelligent-the-generative-ai-paradox