mkdev
426 subscribers
862 photos
179 videos
1.2K links
Download Telegram
Using Google Cloud doesn't automatically mean you're using the right services in the right way.

Our GCP Audit helps uncover unnecessary costs, security gaps, reliability issues and opportunities to simplify your infrastructure.

Take a look at what we cover, and schedule a conversation with our team: https://mkdev.me/b/audits/google-cloud-platform
There are two GenAI security concepts that are easy to mix up: jailbreaks and prompt injection.

A jailbreak generally tries to make an AI system ignore its restrictions and produce something it shouldn’t.

Prompt injection can go further. The goal may be to manipulate an AI system into taking actions or accessing systems and data that the attacker should never be able to reach.

As GenAI gets connected to more tools, APIs, and business systems, that distinction becomes increasingly important. The potential consequences move from “the chatbot said something bad” to data leakage, compromised systems, and operational disruption.

Our guide explains these risks from a product manager’s perspective, alongside another major issue: how employees and users handle sensitive data with GenAI tools.

Read the full article on mkdev: https://mkdev.me/posts/genai-security-risks-for-product-managers-dd73bdc2-4f2e-4227-93b3-375da081d906
Kirill Shirinkin has spent decades across software development, infrastructure and DevOps. For nearly a decade, his own development setup barely changed.

Then AI arrived.

Now he shares what he’s learned from rebuilding his workflow around AI: how he works with coding agents, manages context, makes architecture decisions, organizes parallel work, automates reviews and deployments, and decides what should still remain firmly in the engineer’s hands. He also looks at the less glamorous side of working at AI speed: avoiding bad technical decisions, keeping projects under control, and staying sane when the amount of work you could do suddenly feels almost limitless.

https://mkdev.me/posts/the-agentic-engineering-myth-1-year-of-coding-with-ai
🔥2👍1
In the 98th mkdev dispatch, Pablo talks about how AI is creating a new digital divide where access to powerful tools depends not on infrastructure or skills, but on geography, provider restrictions, and permission to participate in the AI economy. Also inside: scaling Terraform across many Teams and more!

https://mkdev.me/posts/the-ai-divide-is-no-longer-about-access-to-the-internet-98
👍1
AWS gives you plenty of ways to analyze cloud spend, but the analysis is only as useful as the metadata behind it.

For smaller AWS setups, you don’t necessarily need an elaborate tagging framework. A simple baseline of environment, workload, and name can already make it much easier to understand which application or environment is responsible for a particular part of the bill.

Terraform’s default_tags can help apply that baseline consistently across supported resources. The other important step is easy to miss: tags need to be activated as Cost Allocation Tags before you can properly use them for cost analysis.

A relatively small amount of tagging discipline can make Cost Explorer considerably more useful.

Our article walks through a simple approach to getting started with AWS cost allocation tags: https://mkdev.me/posts/control-aws-costs-with-these-3-cost-allocation-tags
👍2
We’ve been using Infrastructure as Code for over a decade. The tools have changed, but the principle hasn’t: infrastructure should be understandable, version controlled, tested and automated.

Learn how we work and start a conversation: https://mkdev.me/b/consulting/iac
🎉1
“Building an AI product? You need a vector database.”

Not necessarily.

Vector search is very good at questions where meaning matters: finding documents, descriptions or passages that are semantically similar to what a user asks. But businesses rarely ask purely semantic questions.

They ask things like: find relevant customer feedback from a particular product, during a particular period, from a particular market. Or identify similar insurance claims, but only for a specific vehicle type and coverage year.

Those questions mix fuzzy semantic meaning with very precise structured filters. And that is where the idea that one vector database will solve your entire retrieval problem starts to fall apart.

In 2026, with relational databases offering increasingly capable vector functionality and dedicated vector systems continuing to mature, choosing the right architecture is less about following the AI stack of the moment and more about understanding what your queries actually require.

We explore the problem in more detail here:
https://mkdev.me/posts/which-database-when-for-ai-are-vector-databases-all-you-need
Kirill Shirinkin handed GPT-6 Astra a long-postponed migration of mkdev.me from Ruby on Rails to Hugo and let it run with surprisingly little supervision. The result worked — but the path there was full of overengineering, impressive autonomy, missed details, and a few good lessons about what today’s most capable coding agents are actually like to work with: https://mkdev.me/posts/how-gpt-6-astra-killed-my-ruby-on-rails-app
When Babbel needed more engineering capacity without permanently expanding its infrastructure team, mkdev stepped in to tackle technical debt and cloud improvements alongside Babbel’s own engineers.

Among other things, we helped prepare the foundations for an AWS multi-account setup and refactored service-to-service communication, offloading 30% of traffic from a heavily used API Gateway.

Read the full case study to see how the collaboration worked and what changed under the hood: https://mkdev.me/b/cases/babbel-case-study
Moving to the cloud isn’t automatically modernization.

You can take the same inefficient architecture, move it from your own data center to AWS, Azure or GCP, and end up with the same problems plus a bigger bill.

The real advantages of cloud come from using it deliberately: elasticity where demand changes, managed services where they remove operational work, and infrastructure that can be provisioned when you actually need it.

Sometimes the right answer is cloud. Sometimes it’s on-premises. Increasingly, it’s a mixture of both.

More thoughts on when a cloud provider actually makes sense: https://mkdev.me/posts/should-i-use-a-cloud-provider
Before adding another database to your AI stack, look at the one you already have.

If your application needs semantic search over free text, vector search can be a natural fit. If it needs exact dates, filters, joins or business rules, relational queries still do that job extremely well. And increasingly, you don’t necessarily have to choose between the two.

PostgreSQL + pgvector is one example of bringing semantic and structured search into the same system.

Our article looks at the trade-offs in practice, including where each approach works well — and where it starts to break down.

Read more: https://mkdev.me/posts/which-database-when-for-ai-vector-and-relational-databases-in-practice
A better AI model doesn’t automatically make a better AI product. Kirill Shirinkin looks at why Grok Bot feels unusually easy to use, from its simple Bot concept and built-in computers to multi-account plugins and smoother browser interactions. He also looks at where the product still falls short.

Read the full article to see what Grok Bot gets right about building AI agents people might actually want to use: https://mkdev.me/posts/grok-bot-is-a-better-product-than-openclaw-and-hermes-agent
Unexpected cloud bills rarely come from one dramatic mistake. Often it’s a resource nobody noticed, a test project that kept running, or a small recurring charge that quietly became a large one.

Google Cloud gives you the tools to investigate these costs by project, service and SKU, while budgets and alerts can flag unusual spending before it turns into an unpleasant invoice. But knowing where the money goes is only the first step. The harder part is deciding which costs are justified, which can be reduced, and how to prevent the same waste from coming back.

That’s where a deeper look at your cloud environment can pay off. At mkdev, we help companies analyse their Google Cloud infrastructure, uncover unnecessary spending and identify practical opportunities for optimisation without compromising reliability.

Our article is a good place to start. And if you want to go beyond the billing dashboard, take a look at our Google Cloud Audit & Assessment and talk to us about what could be improved in your setup: https://mkdev.me/posts/understand-your-google-cloud-costs-billing-cost-management-and-budgets
Kubernetes gives you plenty of control. The downside is that you also get plenty of infrastructure to manage.

EKS with Fargate removes one part of that equation: the worker nodes. You can let AWS provision compute for selected Pods instead of maintaining EC2 capacity, scaling node groups, or worrying about idle worker capacity. Fargate profiles let you decide which workloads use this model and which stay elsewhere in the cluster.

It isn’t a replacement for every EKS workload, and restrictions around things like DaemonSets, privileged containers and storage still matter. But for the right applications, it can make the Kubernetes data plane considerably simpler.

We took a practical look at how it works in this mkdev article: https://mkdev.me/posts/serverless-kubernetes-with-aws-eks-and-fargate
Access to the Docker daemon is effectively root-level access, and writable bind mounts can expose the host. This video demonstrates why that matters. It was recorded back in 2020, but the core security lesson still holds in 2026. Watch the video: https://www.youtube.com/watch?v=sT9Q2xZr4nk
Want to get comfortable with Helm without committing to a huge course?

Our free Helm Lightning Course covers charts, releases, templates, values, hooks, dependencies and practical plugins through short, hands-on lessons.

Go through the course for free in article of video form.

Articles: https://mkdev.me/posts/why-do-you-even-need-helm
Video: https://www.youtube.com/playlist?list=PLozcbFx8FoPHqL9Gm1IpboF45gekmgYjO
Splitting a Terraform project into smaller states shouldn't mean recreating existing infrastructure. But the recommended way to migrate resources between states has changed.

While our article demonstrates the older terraform state mv approach, modern Terraform recommends using removed and import blocks instead. This makes migrations more explicit, reviewable, and manageable through the usual plan/apply workflow.

The underlying principles haven't changed, though. Read our article to understand how Terraform state migrations work and what's happening behind the commands: https://mkdev.me/posts/terraform-migrating-components-between-state-files
Not every cloud problem needs another cloud service. Sometimes you need someone to question your architecture, untangle your automation and explain your bill.

That's where we come in. Discover our approach and book a chat: https://mkdev.me/b/consulting/public-cloud
Please don't build an enterprise-wide AI platform before you've figured out what your first AI products actually need.

It's tempting to invest in sophisticated infrastructure, hire a large AI team, and automate everything from day one. But you're making expensive decisions based on problems you haven't encountered yet.

Start with a real business problem. Experiment, get something into production, measure its impact, and learn what it takes to maintain it. Then repeat.

Once you've demonstrated consistent value across multiple AI products, you'll have a much better understanding of what infrastructure and organizational changes are actually worth investing in.

Our AI Strategy Guide explores why the timing of your investments matters just as much as the technology you choose.

Read it here: https://mkdev.me/posts/ai-strategy-guide-how-to-scale-ai-across-your-business