mkdev

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://lnkd.in/d2jEr9P7

In the 94th mkdev dispatch Kirill discusses the short rise and the quick fall of AI browsers development.

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:

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://lnkd.in/gCpjDG5E

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://lnkd.in/dCbW9GaP

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://lnkd.in/e9UbrV68

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

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://lnkd.in/etH6ywZ6

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://lnkd.in/d7Jt6vZn

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://lnkd.in/diTW5eaj