DevOps.Pink

The Terminal Was Never the Point: Managing Parallel AI Coding Agents

Tatiana Mikhaleva (devops.pink) — Thu, 30 Jul 2026 00:00:00 GMT

For years, visual Git clients were treated as the tool you reached for if you could not handle the command line. Then the code started writing itself, and the argument quietly settled.

You give an AI agent a task (refactor the auth handlers, update the tests) and it goes off to work. While it runs, you start a second on something unrelated, then a third. Three agents are now editing your codebase in parallel, each in its own working directory, all at once. And your terminal, the tool you have trusted for years, can show you exactly one of them at a time.

That small, ordinary moment is the end of a very old argument.

For as long as software has had a culture, it has had a hierarchy of tools, and everyone who writes code knows its shape. Real engineers live in the terminal. They pipe, they script, they rebase from memory, and they treat the command line as the only honest interface to a machine. Everything else is paint over the real thing. A visual Git client, in that worldview, was never quite a serious tool. It was for people who preferred a picture to the raw command, and the clients that leaned into visualization wore a permanent backhanded compliment: makes Git approachable, lowers the cognitive load, no terminal required. Said one way, praise. Said the way it usually was, a pat on the head.

The command line partisans were not wrong about the terminal. They were wrong about where the work was going.

The assumption underneath the hierarchy

Give the command line its due, fully and once: for linear work, nothing has ever beaten it. You type one command, it does one thing, you see the result. No hidden state, no interpretation layer, nothing between your intent and the machine. For an engineer working a task by hand, one branch and one commit and one merge at a time, that directness is the whole point. Against it, a diagram of your repository really was optional. If you change one thing at a time, you can hold the state in your head.

But that judgment rests on a single assumption, invisible because it was always true: the work is sequential. One human, doing one thing at a time.

That assumption just stopped being true.

What parallel agents broke

The question in a lot of engineering teams has changed. It is no longer "should I use an AI coding agent." It is "how do I run more than one without losing track of what they are all doing."

Let me be precise about the case I mean, because it is not the only one. Plenty of agent work is moving into ephemeral cloud environments and coming back as pull requests, and in that world the review dashboard, not the desktop, is where you watch. But that is not where most people are right now. Right now, millions of engineers run agents locally against real working directories on their own machines: Claude Code, Codex CLI, Copilot CLI, Gemini CLI. For them the visibility problem is not a forecast. It is Tuesday.

Return to those three agents. The terminal shows you one. And yes, before anyone says it: you can tile five terminals with tmux, or zellij, or a split pane, and watch every log stream at once. But look at what that actually gives you. Five waterfalls of output. A log tells you what an agent is saying. It does not tell you where that agent is in your codebase, what it has committed, or how its work relates to the other two. A multiplexer scales the output; it does not scale your grasp of the state. You are still reconstructing the real picture in your head, from scrolling text: who changed what, and whether it collides.

This is not a failure of the terminal. It is doing exactly what it was built to do, representing linear work with total fidelity. The work simply stopped being linear. Agents produce parallel, overlapping, simultaneous output, and no linear interface represents parallel work well, no matter how skilled the driver or how many panes they have open.

The interface built for parallel work

Think about what an air traffic controller needs. Not one radio channel checked in sequence, one aircraft at a time; that collapses the instant there are five planes up. A controller needs one surface showing every aircraft at once: where each is, where it is heading, which needs attention now. The value is in seeing all of them together, in relation to each other.

That is exactly what a linear interface cannot give you and a visual one always could. It is also exactly what got waved off as a crutch for years, because until now nobody needed to watch five things at once. One human working by hand never had five parallel streams to monitor. The moment the machines did the writing, and did it in parallel, the thing that looked like a convenience became a control tower.

The tools built around visualization, it turns out, did not need to reinvent themselves for this moment. Their premise was already the one the moment demanded: you should be able to see the state of your work, every branch and every commit and how they relate, on a single surface, instead of rebuilding it in your head from a scroll of output. That premise sat for years, filed under "nice for people who find git log intimidating." It turned out to be the right architecture for a future that had not arrived yet.

Managing parallel agents in practice

GitKraken is the clearest example to reach for, partly because it made the most stubborn bet on visualization and partly because it has now extended that bet, feature by feature, straight into agent work. Read its recent additions not as a feature list but as a map of the specific ways parallel machine work goes wrong.

The first problem is not knowing what is happening at all. Start an agent session and GitKraken spins up an isolated working directory (a Git worktree), runs your setup, and launches the agent, all from one action instead of the old manual dance of creating the worktree, installing dependencies, and starting the agent by hand. Each session becomes a card on one surface, with live status: running, waiting on you, or done. The blind window-switching was the disease; a single board showing every agent's state is the cure.

Worth being exact about that isolation, because it is easy to overclaim. A worktree gives each agent its own working directory but shares the repository's history. Main stays untouched until something is committed. It is not a sealed sandbox, and it is not meant to be one. It is the right level of isolation for managing parallel Git work, and nothing more is promised.

The second problem is knowing where the work is, not just that it exists. The commit graph now includes every active worktree, so each agent's branch sits in the graph beside all the others: what it has committed, and how those commits relate to everything else in the tree. That is the difference between a status light reading "running" and a map showing the actual position. The limit is worth stating plainly. Seeing three agents converge on the same auth module does not prevent the collision they are heading toward; no tool could stop that on its own. What it buys you is what logs never will: you watch the collision forming while there is still time to step in, instead of meeting it at merge time as a thousand-line pileup.

The third problem is what to do with the output once an agent is done. A finished agent tends to dump one sprawling diff across a dozen files, and committing that as a single blob called "update auth" destroys the readability of your history. Commit Composer restructures that machine output into clean, logical commits before it reaches a teammate. You are giving human shape to machine work, which is most of what the human is for now.

And when a branch does collide with main, Auto-resolve with AI proposes a context-aware resolution and explains its reasoning, so you accept it, adjust it, or take over. It clears the rote line-by-line analysis; you keep the final call. It will not untangle a semantic conflict, where one agent's logic breaks another's in ways no merge tool resolves, but it removes the mechanical noise so your attention is free for the part that actually needs a human.

None of that is a new idea. It is the same premise, the state of the work visible on one surface, meeting a moment when the work turned parallel and fast and hard to hold in your head.

(Commit Composer and Auto-resolve with AI are part of GitKraken AI, which requires a paid GitKraken plan; both are currently in preview.)

The argument was never about taste

Underneath the posturing about who counts as a real engineer, the whole fight was about one thing: which shape of work your tools are built to serve. When the work was one human doing one thing at a time, the linear interface was ideal and the visual layer optional. Now that it is many machines doing many things at once, a linear interface cannot represent it, and the surface that shows everything at once stops being a convenience and becomes the only way to stay in control.

The terminal keeps the ground it always ruled: pointed, deterministic, one-shot commands. It will be on every serious machine for the rest of our careers. It did not lose; it has a boundary, and the boundary is where linear work ends.

The crutch argument was never really about tools but about work: the belief that serious work is sequential and solitary and lives at a prompt. That belief held for as long as the work did. It stopped holding the day the machines started writing in parallel. Betting on a full view of everything at once looked like overkill for years. It turned out to describe exactly how we work now.

The terminal was never the point. Seeing the work was. It just took the machines writing the code for everyone to notice.

<div style={{ textAlign: "center", paddingBottom: "3rem", marginTop: "5rem" }}> <p style={{ fontSize: "0.95rem", letterSpacing: "0.25em", textTransform: "uppercase", color: "#ffffff", margin: "0 0 8px 0", fontWeight: "900" }}> Tatiana Mikhaleva </p> <p style={{ fontSize: "0.75rem", letterSpacing: "0.2em", textTransform: "uppercase", color: "#D4537E", margin: "0 0 1rem 0" }}> Docker Captain · IBM Champion · AWS Community Builder </p> <p style={{ fontSize: "0.8rem", color: "#9B2D5A", margin: "0 0 2.5rem 0", fontStyle: "italic" }}> DevOps.Pink — Signal over noise in cloud-native & AI. </p> <div style={{ display: "flex", justifyContent: "center", gap: "1rem", flexWrap: "wrap" }}> <a href="https://www.youtube.com/channel/UCACxfwW1C8KQY1c6nU98VVw?sub_confirmation=1" target="_blank" rel="noopener noreferrer" style={{ padding: "0.6rem 1.5rem", border: "1px solid #9B2D5A", color: "#D4537E", textDecoration: "none", fontWeight: "bold", textTransform: "uppercase", letterSpacing: "0.15em", fontSize: "0.8rem", borderRadius: "2px", transition: "all 0.3s ease" }}>YouTube</a> <a href="https://devops.pink/discord" target="_blank" rel="noopener noreferrer" style={{ padding: "0.6rem 1.5rem", border: "1px solid #9B2D5A", color: "#D4537E", textDecoration: "none", fontWeight: "bold", textTransform: "uppercase", letterSpacing: "0.15em", fontSize: "0.8rem", borderRadius: "2px", transition: "all 0.3s ease" }}>Discord</a> <a href="https://www.linkedin.com/in/devopspink/" target="_blank" rel="noopener noreferrer" style={{ padding: "0.6rem 1.5rem", border: "1px solid #9B2D5A", color: "#D4537E", textDecoration: "none", fontWeight: "bold", textTransform: "uppercase", letterSpacing: "0.15em", fontSize: "0.8rem", borderRadius: "2px", transition: "all 0.3s ease" }}>LinkedIn</a> </div> </div>

The Runbook You Didn't Write Is Already Running in Production

Tatiana Mikhaleva (devops.pink) — Sat, 25 Jul 2026 00:00:00 GMT

Your vendors now ship opinions about how their products should be operated. The opinions are executable, and almost nobody is reading them.

Somewhere in your stack, a procedure now runs against production that nobody on your team wrote, reviewed, or can see. It came from a vendor, packaged as a skill for an AI agent, and it encodes their view of how their product should be operated: which signals to check, what counts as broken, what to do about it. It arrived with an install command. It did not arrive with a pull request.

You can watch this happening in the open. Open Anthropic's plugin directory and scroll. Not the community catalog. The official one, the list Anthropic curates itself. More than 250 entries at the time of writing.

AWS is there, with roughly a dozen plugins, most of them authored by Amazon Web Services directly. Azure is there. GitLab, covering repositories, merge requests and CI/CD pipelines. HashiCorp's Terraform. Oracle. Vercel, managing deployments, builds, logs and domains. Netlify, covering functions, edge functions, blobs, database and image CDN. Render ships skills, an agent, slash commands and a validation hook for render.yaml. Railway covers project setup, deploys, networking, monitoring — and troubleshooting. PagerDuty scores your pre-commit diffs against historical incident data. SonarQube enforces itself inside the agent coding loop.

Pulumi is not in that catalog, and the absence turns out to be more interesting than the presence would have been. Pulumi ships its skills anyway: through its own plugin marketplace, and through a cross-platform CLI that follows the open Agent Skills specification, reaching Claude Code, Cursor, Copilot, VS Code, Codex and Gemini CLI. We will come back to Pulumi, because Pulumi is where the shape of this gets clearest.

Let me be precise about what is new here, because "AI does ops now" is not a new headline, and until recently it mostly meant autocomplete for YAML: a faster way to write the config a human still reviewed. That is not this.

This piece is an analysis of what a dozen vendors shipped in the space of a few months, and of what none of them addressed. Every technical claim below comes from a vendor's own documentation, their own published writing, or the public record. The argument does not need me to be right about anything. It needs them to have been quiet about the same six questions. They were.

What changed, in plain terms

Here is how it used to work.

A company bought a tool: a database, a cloud service, a CI system. The engineers read the vendor's documentation. Then they wrote their own runbook, the procedure for what to check, in what order, when that tool misbehaved. That runbook lived in the repository. A colleague reviewed it. It was version-controlled, argued over, and owned by the team.

Here is how it works now.

The vendors (AWS, GitLab, Vercel, Pulumi and the rest) ship ready-made plugins and "skills" for AI agents like Claude or Copilot. You describe the problem in a chat. The agent reads it, decides how to diagnose it, and applies the fix to the running system, following logic the vendor wrote, not you.

The runbook used to be something you wrote. Now it arrives from the vendor, pre-written, and it executes. That is the whole shift, and everything below follows from it.

Access is not the same as a procedure

This distinction matters more than anything else in the piece, so let me borrow the clearest statement of it I have found. It comes, tellingly, from a vendor's own blog rather than from a critic.

A post on Pulumi's blog draws the line: MCP servers give Claude access to things; skills teach Claude how to think about things. Different jobs.

An MCP server is a door. It says: here are my endpoints, here is what you may call. Your team still decides what to do with them.

A skill is a procedure. It says: here is how you diagnose me, in this order, checking these signals, escalating at this threshold.

The same Pulumi post is explicit about why they ship them: generic AI assistance produces code that looks reasonable but breaks the conventions the community learned the hard way, so the skills teach Claude those conventions.

Read that twice, with an operator's ear. The vendor is not shipping you tools. They are shipping you their opinion, in a form that runs. They said so themselves, in their own marketing, as a feature. And they are right that it is a feature.

What this replaces

Think about what the old runbook actually was.

You worked out what mattered in your environment, which is never quite what mattered in theirs. You wrote it down. It went through code review. When it was wrong in the middle of the night, you fixed it, and the fix was yours.

That runbook was an artifact of your team's understanding. It was, in a real sense, the thing your platform team was.

Now consider a vendor-shipped skill called something like /troubleshoot.

It encodes a definition of what troubleshooting that product means. Which signals to check. In which order. What counts as normal. What counts as a problem worth escalating. Someone decided all of that.

Not you.

And vendors deciding is not the new part. Vendors have always had opinions, and they published them as docs, where a senior engineer read the advice and discarded the two-thirds that did not apply to their environment. That adaptation step has been removed from the loop. The opinion is no longer a document you read. It is a procedure that runs.

The honest case for it

I am not going to write the skeptic's column. The skeptic's column is easy and mostly wrong, and if I skip this section the rest of the piece is worthless.

The vendor's runbook is better than yours. At least on day one. They know their own failure modes. They know which metric actually predicts trouble and which three are decorative. Your first runbook is a guess assembled from their docs and a Stack Overflow thread. Theirs is the accumulated support load of every customer who ever paged them.

Onboarding collapses. The gap between "we bought this" and "we can operate this in the middle of the night" has historically been measured in weeks of a senior engineer's time.

It travels. The failure mode this fixes is the one the ecosystem calls tribal knowledge. One engineer works out the smart diagnostic sequence, and it lives in their head and a Slack thread of partial screenshots. New hires inherit an empty config directory. A packaged skill set is that knowledge, versioned and installable.

It is simply a better interface. Natural language is not magic; remembering which of forty subcommands and which flag combination was never a good use of human memory.

All of that is real. Which is exactly why the next part matters.

Where it breaks

Six places. None has a clean answer yet, and I have not seen a vendor address any of them in a launch post.

1. The agent fixes production, and GitOps deletes the fix

Start with the one that is mechanical rather than philosophical, because it is the one that bites first.

If your platform runs on GitOps (and for a large share of teams now, it does), the repository is the source of truth. Not the cluster. The cluster is a projection of the repository, reconciled continuously.

Now put an agent in that picture. At night, a vendor's /troubleshoot skill works out what is wrong and edits live state to fix it: the replica count, the image tag, the config of a resource Git declares. Not a restart the deployment would undo on its own; a change to something the repository has an opinion about.

Self-heal is not on by default; changes made to the live cluster do not trigger a sync unless you opt in. But with selfHeal: true, drift between Git and the cluster is simply corrected. The controller does not know or care that a model made the change with good intentions. It sees exactly what it sees when a panicking engineer runs kubectl against prod: live state that disagrees with declared state.

So the agent fixes production, and the platform reverts the fix, because the fix was never in Git. How quickly depends on your configuration. That it happens does not. This is a failure mode you assemble rather than a default: it needs selfHeal: true, an agent with write access, and the freedom to act unsupervised. Three switches you turn on yourself. The point is that nothing in the tooling pushes back when you line them up, and plenty of teams will.

There is a sharper edge too, straight from Argo CD's own documentation: rollback cannot be performed against an application with automated sync enabled. The escape hatch is not sealed (you disable auto-sync, roll back, re-enable), but it now has an extra step, and you are taking it under time pressure, in the middle of the night, on a system you did not just watch change.

But the revert is not the worst part. The agent's fix is not just undone. It is unrecorded. It never became a commit. No diff, no review, no history. The one artifact the whole organization trusts has no idea any of it happened. Your source of truth is now, precisely, not the truth.

2. The catalog disagrees with itself

The same tension is visible one level up, in who ships what.

This is the contradiction Pulumi embodies most cleanly. Its whole thesis is that infrastructure is code: versioned, reviewed, living in a repository. And it now ships agent skills that operate that same infrastructure conversationally, distributed to six platforms as something it plainly considers core, not a side integration.

But the problem is not Pulumi's alone. Everyone owns it, and the cleanest evidence sits in the catalog I opened at the top of this piece.

Two entries, a few lines apart in the same file. aws-core, author field Amazon Web Services, offers skills to author infrastructure as code. aws-agents-for-devsecops, author field Amazon Web Services, investigates incidents and runs penetration tests.

One of those exists because the repository should decide. The other exists because, in the middle of an incident, something faster than a human should. I have not found a page on either that mentions the other.

To be fair to AWS: their DevOps Agent investigates and recommends, and a human still applies the remediation. That is the responsible design, and most vendor agents today are read-heavy for exactly this reason. The mutation risk does not live in the vendor's own incident agent. It lives one layer over, in a coding agent that has your kubectl credentials and a vendor's skill telling it what "fix this" means. And it lives in the trajectory, because every one of these products is moving in the same direction, and none of the vendors shipping the procedures is moving toward asking permission more often.

And one vendor stayed out. Terraform, now an IBM product, taught a generation that the repository is the source of truth, and its catalog entry is an MCP server: a door, not a procedure. The one whose identity was built on "the repository decides" is the one that shipped no runbook. Read it as caution or as lag; either way it is the exception worth watching.

The pattern is uniform. The same vendors selling "the repository decides" are selling "the model decides, live." The controller is not broken; Argo CD reverting an out-of-band change is doing its job. That is the point. Both product lines work exactly as designed, and the designs disagree about who may change production. Nobody has reconciled them, and most teams will find out during an incident rather than a design review.

3. The audit log records the action, not the intent

Consider what the log looks like when a deploy was initiated by a model responding to the sentence "the staging cluster looks unhappy, sort it out."

The line reads: deployment updated, timestamp, actor. It is accurate. It is also nearly useless in a postmortem, because the thing you need to reconstruct is not what happened but why the system believed that was the right thing to do. The reasoning is not in the log. In most setups it is not anywhere. It evaporated with the session.

The better incident agents do capture this. AWS's DevOps Agent, for one, keeps an investigation journal with its reasoning. But that discipline lives in the specialized agents, not in the coding agent holding your kubectl credentials, and it is the coding agent that mutates state. We spent fifteen years building the discipline that every production change should be traceable to a reviewed, intentional decision. The audit trail was the enforcement mechanism. It still records changes perfectly. In the path that matters most, it has quietly stopped recording decisions.

4. You are running someone else's runbook without reviewing the diff

This is the one that should worry you most, and it is structural rather than hypothetical.

Your runbook went through code review. That was the entire point: a second engineer read it before it could page anyone.

The vendor's skills ship with the plugin. When the plugin updates, the procedures update. Ask yourself honestly: are you reviewing that diff? Is anyone on your team reading the changelog for the diagnostic logic that will run against your production system?

The mechanics are not subtle. If your plugin reference tracks a branch or a moving commit, upstream changes arrive in your engineers' sessions unannounced. That is not a criticism of anyone's design; it is how git works. But it means the vendor's operational logic is an unversioned dependency sitting in your production path, and the update lands without a pull request.

There is a second problem underneath, and it is worse. A skill is a markdown file that the agent reads as instruction, not as data. Whatever is in it enters the model's context with the authority of a procedure. If that file is ever modified (upstream, in a dependency, by anyone with commit access to a repository you do not watch), the modification is not a config change you can diff in review. It is an instruction the agent will follow. The security literature has been shouting about prompt injection through tool descriptions and skill content for years. The industry response has been to ship more skills.

The same literature has a name for the passive version of this risk: a rugpull, where a component that behaved one way when you vetted it behaves differently later. And it points at the mental-model problem underneath. Users experience this as connecting their agent to a service, when what they are actually doing is running someone else's code with their own credentials.

Anthropic clearly sees this. Their plugin system will not let a plugin-shipped agent bring its own hooks, MCP servers or permission mode, documented as a deliberate security decision. Plugins can ship disabled by default, specifically for cases that add scope a user should consciously opt into. Their marketplace pins approved plugins to specific commits rather than tracking a branch.

Those are good primitives. But they are primitives on the client side. They say nothing about whether your organization reviews your vendor's operational logic before it runs. Right now almost nobody does, because the review step never existed. There was never a vendor runbook to review.

5. Responsibility has no owner

An agent deployed the wrong thing in the middle of the night.

You typed a sentence. A model interpreted it. A vendor wrote the skill the model invoked. A second vendor's platform executed it.

Where does the postmortem land? That question is not philosophy. The incident review will ask it first, and there is currently no convention for answering it. "The agent did it" is not an answer any organization accepts twice.

The uncomfortable version: the engineer who typed the sentence will absorb it, because they are the only human in the chain. That is not a stable arrangement. It is how you lose senior people.

6. If the runbook self-executes, what is the on-call rotation for?

If a vendor's skill investigates on its own, do you still need someone awake?

Most teams will answer yes, of course, and then let the rotation atrophy, because the pager fires less often and the incentive to staff it decays.

The failure case is subtler than the agent missing something. The agent handles the routine 90% competently, the humans lose their calibration on the system because they have not touched it in four months, and then the 10% arrives, and the person who picks up the page has never operated the thing unassisted.

We have seen this film, and it is worth being precise about the ending, because the ending is not reassuring.

This is an old problem wearing new clothes, and it is worth saying so plainly rather than presenting it as a discovery. In 1983, the cognitive psychologist Lisanne Bainbridge named it the irony of automation: automate most of a process but not all of it, and you have not removed the operator. You have handed them a job they can no longer do, because the skills to take over are exactly the ones the automation stopped them practicing.

Aviation has spent the decades since failing to solve it, with far more pressure than we have. An FAA human factors report picked it up in 1996. In 2009, Air France 447 fell into the Atlantic after the autopilot handed control back to a crew short on hand-flying practice. Forty years, a regulator, mandatory training regimes, an industry where this failure mode kills people in visible numbers. Still unresolved. It is common enough by now to have its own review literature under titles like Ironies of Automation: Still Unresolved After All These Years.

I raise this as calibration, not warning. If you are assuming platform engineering will work this out in a couple of release cycles, look at what it took aviation to not work it out. We have no regulator, no mandatory training, no shared incident database, and our failure mode costs a quarter's revenue rather than 228 lives, which means less pressure to solve it, not more.

What to ask before you turn it on

The advice circulating right now is uniform and correct as far as it goes: start read-only, scope write access carefully, use dedicated service accounts rather than your own credentials, never hand an agent write access to a production database. Take that advice. I have written about the enforcement half of it before: the ceiling that makes an agent physically unable to cross a line, and the six-phase framework for taking agents to production at all.

But that advice addresses the access problem, and access is not the interesting problem here. Here is what I would ask a vendor before enabling their skills against anything that matters.

What is your update policy for these skills? Do they follow the plugin version, or can I pin them independently? If I cannot pin them, your operational logic is an unversioned dependency in my production path.
Do procedure changes appear in your release notes? The files are readable; they are markdown in a repository. The question is whether you treat a change to diagnostic logic as a documented release or as a silent commit. If your changelog does not mention skills, that is my answer.
What does the audit record capture when the actor is a model? Specifically: does it capture the prompt, the tool sequence and the reasoning, or just the resulting state change?
Which of these commands mutate? Not "which are dangerous". Which write. Give me the list, and give me a way to disable the mutating half without disabling the diagnostics.
Can the agent roll back its own mutations? And the harder half: does it know when it should? A rollback is a judgment, not a capability; something has to decide the intervention made things worse. If the answer is that a human steps in, be clear about what you are asking of that human. They are arriving at an undocumented state that a model produced and did not explain, under time pressure, at whatever hour this happens.
What is your position when your skill causes an outage? Not for the lawyers. I want to know whether you have thought about it at all.

If a vendor has good answers to all six, they have thought about this harder than most. I have not yet found one who has published answers to any. Not in a launch post, not in the docs. The conversation is happening elsewhere: lawyers are writing about the liability gap, insurers are excluding agent-related losses, regulators are naming autonomy and auditability as risks. The people shipping the procedures are not part of it yet.

The runbook used to be the artifact of a team's understanding. It was slow to write, and it was ours.

The new one arrives working, on day one, better than the one we would have written. That is a real gift, and I am not being sarcastic.

But we should be clear about the trade. We are accepting a vendor's opinion about how their product should be operated, and we are accepting it in a form we do not read.

That is not automatically wrong. Every dependency is a decision to trust someone else's judgment, and we make that decision a hundred times a day without agonizing. The difference is that code dependencies come with twenty years of convention: lockfiles, review, CVE feeds, SBOMs.

For operational dependencies, we have a marketplace listing and an install command.

Go read the skills your vendors shipped you this quarter. They are all markdown. It is a short read, and it is your production.

The Industry Is Hiring DevRel for Yesterday

Tatiana Mikhaleva (devops.pink) — Fri, 17 Jul 2026 00:00:00 GMT

We're building the future and hiring for the past. A field diagnosis of DevRel recruitment: eight symptoms, and the one fear underneath all of them.

Developer Relations is a young discipline with very old diseases. Right now the tech industry is building the infrastructure of the future: we're deploying Model Context Protocol (MCP) servers, wiring in autonomous AI agents, teaching models to hold complex context. And then, when it's time to hire the people who represent that work to the world, the process snaps back to 2012-era B2B marketing and HR screening from the age of the fax machine.

We build autonomous systems, and then we make human advocates recite metrics from a script like first-generation chatbots.

This is more than a broken hiring funnel. It's a diagnosis of an industry losing its best people, because senior professionals form their verdict on an employer inside the first five minutes of a call.

Start with the word itself. "DevRel" and "Developer Advocate" mean something different at every company: evangelist at one, developer-experience engineer at the next, disguised support at a third, all under the same title. The label carries no information. A candidate applies half-blind and only learns what the job actually is somewhere in the interview loop. So this piece has to do what the postings don't: name its slice. Developer Relations is a wide umbrella (community, developer experience, documentation, advocacy), and what follows is about the advocacy end of it: the outward-facing role whose job is reach, and whose value is the hardest thing on that list to hire for. Below are the main symptoms, some absurd, some expensive, and at the end, the single disease they all trace back to.

Symptom 1. The dead tutorial, and the fear of storytelling

Imagine ordering the most authentic, spiciest dish on the menu, then asking the chef to leave out every spice, just to be safe, so nobody gets alarmed.

That's how the corporate system treats a distinctive authorial voice. The company wants the market's attention but is afraid of the unconventional approach that actually earns it. And meanwhile it's still hiring people to write "technical articles" and record the hour-long live-configuration screencast: a camera on someone's terminal while they set something up in real time. That format is dead. Nobody finishes an hour of watching another person configure a tool; they open the docs, or they ask a model. And the traditional tutorial died with it: AI agents write code and documentation faster than any senior engineer, and they don't get tired doing it. The live, bare-handed demonstration is just as dated. In the age of AI-assisted work, watching someone perform a task raw, under a stopwatch, measures a skill nobody uses raw anymore.

To cut through the banner-blindness of exhausted developers, you don't need instructions. You need high-signal narrative, with real craft in how it's told. Engineers stop for aesthetics, intrigue, a distinct voice, a bold visual choice, the things a machine still can't generate. A strong DevRel today isn't a programmer with a microphone. They're the bridge between complex engineering and human attention.

Symptom 2. Title arbitrage: support in disguise

You open a "Senior Developer Advocate" posting. Beautiful copy: evangelism, the voice of the developer. Then the interview reveals the actual job: you'll be jumping on calls with customers whose setup is broken, showing them where to click.

That role has an honest title: Technical Support Engineer, Solutions Architect, or Customer Success Manager. The difference is fundamental. Support is reactive. It works with people who already bought and hit a wall, and it scales through hours worked. DevRel is proactive. It works with people who don't yet know you exist, and it scales through narrative and trust. Sometimes the swap is subtler than a ticket queue: they want the charisma, someone warm and articulate enough that customers who already signed don't drift away. But charm aimed at keeping existing accounts from churning is Customer Success, not Developer Relations. It's the same inversion: the function built to win people who've never heard of you, pointed backward at the people you already have. Put "DevRel" on the label and fill the box with a ticket queue, and the function that was supposed to win you the market stays a gaping hole.

Symptom 3. Cross-ecosystem influence vs. the corporate silo

Picture a symphony conductor hired by a committee of an accountant, a facilities manager, and a security guard. Everyone asks questions from their own domain. Every question is reasonable on its own terms. None of them have anything to do with music.

That's what happens when DevRel candidates are screened by managers who think entirely inside their own product's sales funnel. A marketer measures the world in MQLs. A sales leader looks for lead gen. Each asks the only question they know how to ask.

But the value of a strong DevRel professional is built at the intersection of ecosystems: open-source foundations, enterprise platforms, independent communities that don't share a Slack or a cap table. The work is translation: turning engineering language into business value, and carrying trust from one community into another. That's the asset. And it's exactly the asset a funnel-shaped interview can't see, because it doesn't fit the funnel. So the conversation drifts to whether the candidate can optimize a sign-up button on a landing page, and the real capability goes unmeasured.

Symptom 4. Catechism instead of strategy

A driver who just won the championship sits down across from you, and you pass on him, because he couldn't sketch a carburetor diagram from memory. He has the results. He just didn't pass your theory test.

The same scene plays out in DevRel hiring. A candidate with years of accumulated social capital sits down, and the first real question is: "Name five metrics of DevRel success for our CEO." It's 2026. Any language model will produce an academically flawless list in three seconds: time-to-first-hello-world, API sign-ups, activation rate, NPS. "Name five metrics" tests exactly one skill: the ability to quote a textbook. A skill that AI has commoditized completely and for free.

To be fair, companies don't ask this out of malice. They're tired of "star evangelists" who burn through travel budgets without moving the product a millimeter. But demanding that someone who carries real social capital recite the manual on how to measure it is screening out practitioners in favor of theorists.

Symptom 5. Spec work: the unpaid audition

At some point comes the request that sounds reasonable and isn't: "Put together a short video on our product, so we can see your approach." For a candidate with no public work, a junior or a career-switcher, this is fair; there's nothing to evaluate, so you ask for a sample. But the same request lands very differently when it's aimed at someone whose entire craft is already public: a channel reaching tens of thousands of engineers, a body of published work, metrics anyone can open in a browser. Researching a product, scripting, shooting, and editing a single video is fifteen to thirty hours of specialized production. Asking for that unpaid, as a screening step, from someone whose portfolio is one click away, is spec work by another name: the practice design and writing communities named and rejected a decade ago. DevRel simply hasn't caught up.

And it reveals the same disease as the metrics question: the company can't read a portfolio, so it falls back on a task it knows how to score. Worse, the filter is inverted. The people who agree to produce free spec work are, by definition, the ones with the least leverage and the least proof, the opposite of who the role needs. The strongest candidates decline, and the process quietly screens out exactly the signal it was meant to find.

The synchronous version is bolder still: "Share your screen and show us how you'd present our product, right now." Same unpaid work on their product, extracted live and dressed up as a conversation, with "show us how you'd sell it" quietly turning the interview into a request for free marketing.

Symptom 6. Startups: a full orchestra for the price of one violinist

A thirty-person startup posts a single opening: write the technical articles, edit the video, speak at conferences, run the Discord, support sales with demos. That's not a role. It's a full orchestra hired for the price of one violinist.

It's the headcount of a five-person department, offered to one person. And the startup, whose product no one has heard of yet, runs the interview from a posture of "prove you're worthy of us." A healthy business understands the math: at that stage, a strong DevRel who already holds the keys to established ecosystems brings more reputational capital to the company than the company brings to them. That conversation should happen between equals.

Symptom 7. The double bind: hired for reach, rejected for it

First they tell you the reach is the whole point: "we need someone with a real audience." Then, in the same process, that reach is turned against you: "But are you technically deep enough? You're really a content person, aren't you?" The exact asset they screened for becomes the reason to pass.

Underneath sits an engineering-purity test. To be clear: the technical depth is non-negotiable. A DevRel who can't follow the architecture, judge whether a technical claim holds up, or feel where engineers are really hurting is finished before they start. The question is how you measure that depth. Screening on "years employed as a software engineer" is a proxy, and a poor one: it passes people who shipped production code a decade ago but can't explain it, and it rejects people with current, demonstrable command of the technology who arrived by another road. The role is translation from end to end, taking complex systems and making engineers care, and translation demands real fluency on both sides. Someone who can make a distributed-systems concept land for tens of thousands of engineers is doing the other half of that work, not a lesser one. But the filter reads "not an SWE" and stops there.

Symptom 8. The invisible reporting line

Two "Senior Developer Advocate" postings can describe opposite jobs, and the thing that decides which is a single line the posting never shows you: who you report to.

Report into marketing, and you'll be measured on MQLs and lead gen you don't control. Report into sales, and you're pre-sales with a quota under a friendlier name. Report into product or engineering, and you might actually shape the thing you advocate for, the one line where the role can succeed. The org chart decides the outcome before your first day, and it stays invisible until you're already inside.

The same blind spot shows up in the room. It's common to move through an entire interview loop without meeting a single practicing DevRel, judged start to finish by people who have never done the job. That absence is upstream of everything else here: it's why the metrics catechism and the funnel questions feel reasonable to the people asking them. They're using the only rulers they have.

The disease beneath the symptoms

None of this is simple stupidity. It's fear.

Developer Relations spent 2023 through 2025 being cut first and cut deepest. When budgets tighten, the discipline whose contribution is hardest to tie directly to revenue is the easiest line to remove. Nearly every company hiring DevRel today remembers doing exactly that, or watching a competitor do it.

So they hire from fear. Fear is what turns a reasonable question into a catechism, a portfolio review into unpaid spec work, a senior conversation into "prove you're worthy of us." Fear demands guarantees a young discipline can't yet give, then punishes it for not giving them. The symptoms above aren't eight separate failures. They're one anxiety wearing different masks: we had to cut this once, and we're terrified of being wrong again.

And fear only ever looks in one direction: backward, at what it might lose. It's the same reflex that turns a DevRel hire into a retention job: guard the customers you have instead of reaching the ones you don't. A discipline whose entire purpose is forward motion, staffed by people told to stand still and protect the perimeter.

The irony is that hiring from fear guarantees the outcome it's trying to avoid. Screen for safe answers and compliant hires, and you get advocates who produce safe, ignorable work, the exact thing that got the function cut in the first place.

What a sane hiring process looks like

To hire the people who actually move product growth, rebuild the process:

A distribution audit instead of memorized metrics. "Show us your work from the last year. How do you build a high-signal story? What worked, what didn't, and why?" You can't Google your way through that.
A real launch, walked through live. "Take us through a launch you ran: how you built the communication, what worked, what didn't, what you'd change." That tests strategic thinking, on real decisions with real numbers, without asking for free work on their product.
Community references. Standing among architects, maintainers, and ecosystem leaders is the one signal in this profession that can't be forged.

In an era where any block of code, any paragraph, any list of metrics can be generated in seconds, human trust and attention have become the scarcest resources on the market. Neither can be measured by a question from an HR playbook. The companies that learn to recognize genuine social capital and real storytelling, the kind that lives outside the corporate script, will take the strategic advantage. The rest will keep hiring obedient straight-A students, and keep wondering why nobody notices their brilliant engineering.

How to Secure AI Agents in Production: IBM's Six-Phase Framework

Tatiana Mikhaleva (devops.pink) — Tue, 16 Jun 2026 00:00:00 GMT

The enforcement layer that gives an agent a hard ceiling (Vault, Sentinel, the rest) I covered already. This is the other half: the methodology IBM and Anthropic built to wrap around it. I read the whole guide. Here it is, phase by phase.

A prompt is not a security control. It is a wish.

I keep meeting platform teams losing the same fight. They write careful system prompts. They add a stern "never do X" section. They version their tools. Then one Friday evening an agent reads the rule, agrees with it warmly, and reaches for production anyway. That is what probabilistic systems do under pressure.

This is not a prompt-engineering problem. It is a category mistake. We are shipping a new kind of software, one that behaves a little differently every time it runs, on a playbook written for software that behaves the same way every time. So it breaks. The strange part is not that it breaks. It is that we keep acting surprised.

In October 2025, IBM published a guide called Architecting Secure Enterprise AI Agents with MCP, verified by Anthropic. It finally names the gap and gives it a shape: a framework called the Agent Development Lifecycle, six phases that stretch DevSecOps to fit stochastic, tool-using agents. I am an IBM Champion, and I have spent real hours inside this document. It is the clearest answer I have seen to the question every platform lead is now asking out loud: what does "safe" even mean when the thing you are shipping is non-deterministic?

This is my walkthrough of the six phases. What each one means, where teams fall down, and the one that saves you if you only have budget for one.

import VideoPlayer from "@components/VideoPlayer.astro";

Why the old playbook quietly stops working

Start with the assumption sitting under every CI/CD pipeline ever built: if it passed staging, it is safe to ship.

That holds because normal code is deterministic. Same input, same output, forever. Pass the test once and you have passed it for good. That is why staging means something, why version control means something, why the whole apparatus of scanning and signing and gating does what it claims.

Now look at what an agent actually is. Same prompt, same data, and the output is probably close. Not guaranteed. And the agent does not just emit text. It chooses tools, in some order, and the order changes what it does next. Your attack surface is no longer the code you wrote. It is the full space of decisions the model might make at runtime with the tools you handed it.

That is a different kind of system, and it fails in ways your pipeline was never built to catch: behavioral drift, prompt injection, tool misuse, autonomy that runs longer than anyone meant it to. Your pipeline misses all of it, because nobody ever asked it to look.

So the useful question is not "how do I write a better prompt." It is this: what do I build around the agent so that it physically cannot do the wrong thing for long? That is what the Agent Development Lifecycle answers.

The reframe that makes the rest click

Before the phases, one idea, because it reorders everything after it.

An agent is not an app you ship and forget. It is a system you watch, bound, and keep honest. Security stops being the last gate before release and becomes a thread running through the whole life of the agent, from the day you sketch what it should do to the day you switch it off.

That is uncomfortable for engineering culture, because we are trained to treat "shipped" as the finish line. With agents there is no finish line. The thing keeps deciding in production, and those decisions can drift for reasons that have nothing to do with your code: a model updated upstream, a tool added to its catalog, a slow change in how users phrase things. The agent that passed every test in March is not the same agent in September. Same weights, different behavior, because the world around it moved.

So: six phases. Not a checklist you finish once, but a loop you keep running.

Phase 1: Plan

Most teams lose here, before a line of code exists.

Two questions get settled in Plan, and both are awkward enough that people skip them and promise to sort it out later.

First: how will you know the agent is doing the right thing? Not "does it run." How do you measure rightness. IBM's guide calls this evaluation-first, and it is the agent-world version of test-driven development. You design the evaluation before you build the agent, because if you build first and evaluate after, you end up grading your own homework, generously. The evaluation has to be a separate artifact, written down, with criteria you could defend to a skeptic.

Second: how much freedom does the agent get? This is acceptable agency, the line between what the agent may decide alone and where a human has to sign. Most teams wave at it with "we'll keep a human in the loop" and never say which decisions actually cross the line. Write it down, and be specific. The agent may draft and send mail to internal addresses on its own. It may not contact an external address without a human approving it. That specific.

Skip Plan and every later phase is improvisation.

Phase 2: Code & Build

Short phase, one non-negotiable rule: a prompt change is a deploy.

Most teams version their code like scripture and treat the prompt that steers the agent as a note in a Notion page. That is backwards. The prompt is the agent's program. The tool definitions are part of that program. Edit either and you have shipped a new version of the system, whether CI ran or not.

So version prompts and tool definitions the way you version code. Diff them. Review them. Roll them back when they regress. Obvious on paper. Almost nobody does it on day one.

Phase 3: Test & Release

If you do only two phases well, do Plan and this one. Test & Release is the phase most teams skip, and the one that saves them.

It gets skipped because it is expensive and it does not look like testing. Traditional QA asks whether the code does what you wrote. Agent testing asks how the agent behaves under pressure, under attack, under inputs nobody planned for. Different muscle, and most orgs have not built it yet.

Three things have to happen here.

Red-teaming. You attack the agent on purpose. You feed it the most awkward, adversarial, malformed input you can invent and watch what it does. If it folds now, the lesson was cheap. If it folds in production, the lesson is expensive.

Model-graded evaluation, the "LLM as a judge" pattern, one model scoring another. It is not flawless. It is far better than nothing, and it scales the way human review never will.

A human with teeth. Not a rubber stamp. A person with the authority and the context to say no, after which the approved agent lands in a trusted catalog: the governed list of agents allowed to act in your environment. Not in the catalog, does not run.

This is where "it passed staging" finally dies, and good. Staging was never going to catch this one.

Phase 4: Deploy

Phase 4 asks a single question, and asking it honestly is the whole job: what is the blast radius?

For deterministic software, deploy means the binary is live. For an agent, deploy means this thing is now making decisions in the world. The better mental model is not pushing code. It is putting the agent in a locked room first, and opening the door only once you have checked what it can reach from inside.

This is where the framework extends DevSecOps instead of replacing it. Your container scanning, your image signing, your policy-as-code gates all stay. You add one class of check on top: the blast-radius check. If this agent goes rogue tomorrow, what is the worst it can do? You press Deploy only when the honest answer is "break itself, and nothing else." If the answer is anything larger than itself, you are not ready. Narrow the permissions, isolate the resources, shorten the credentials, then ask again.

Phase 5: Operate

This is the heart of the framework, and the phase with the most architecture in it.

In Operate, everything the agent does goes through one door: a secure MCP Gateway. Not ideally one door. Not mostly one door. One door. There is no other safe way to run an agent in production.

That door does four jobs, and none is optional. It checks who is asking, because every request carries an identity and there are no anonymous agent calls. It hands out least-access permissions, exactly what the task needs and nothing spare. It enforces your rules, the rate limits and allow-lists and denied paths and time-of-day constraints your governance demands. And it logs all of it, every request and decision and response, which is the only way you reconstruct what happened when something goes wrong.

While that runs, the agent itself sits boxed in a sandbox: an isolated execution environment with short-lived credentials that expire fast, instead of a password sitting in a .env file forever. If the agent is compromised, the blast radius is the sandbox. Not your database. Not your cloud account.

The temptation is to skip the gateway because it adds a little latency and feels like overkill for the proof-of-concept your team is poking at. Do not skip it. The gateway is the line between "an experiment that escaped" and "a system you can defend."

Phase 6: Monitor

The shift in Monitor is simple to say and hard to do: you stop checking only whether the agent is up, and start watching how it thinks.

For a normal service, monitoring is uptime, error rate, latency, a couple of business metrics. For an agent, monitoring means following the reasoning. What chain of thought got it to that decision? Which tools did it call, in what order? Did it get confused, double back, try something it should not have?

And you watch for drift. An agent that behaved in March can start misbehaving in September with nothing in your code changed: the upstream model got patched, a tool's response format shifted, the questions users ask moved on. Drift is silent, and it is the thing that gets you if you are only watching error rates. The job here is to catch behavioral change before your users do, and that needs telemetry your current observability stack does not produce by default. Plan to extend it.

What I would actually do on Monday

If you read this far staring at your own fleet of agents, do not try to stand up all six phases at once. You will finish none of them.

Pick Plan and Test & Release. Write down what your agent is allowed to decide on its own, then genuinely try to break it before it ships. Those two catch most of the pain. Layer the rest in over the following weeks.

And stop building your own version of this from scratch. I keep meeting platform teams burning a senior engineer's whole quarter on a homegrown sandbox, a homegrown policy layer, a homegrown audit log, rebuilding (worse) what the industry has now assembled properly. That is unbillable R&D inside a company whose actual job is retail, or fintech, or streaming. The framework exists. The primitives exist. IBM's guide is free to read. Use them, and put your senior people back on the product.

One last reframe

The line I keep coming back to: an AI agent is not an app. It is a system that keeps deciding, in production, against a moving world, with the tools you gave it. So stop shipping it like an app. Build the loop around it, not just the artifact.

The teams that win this next phase of the industry will not be the ones with the cleverest agent. They will be the ones who know, precisely, what their agent cannot do, and have the logs to prove it.

Your AI Agent Doesn't Need a Better Prompt. It Needs a Ceiling

Tatiana Mikhaleva (devops.pink) — Sat, 30 May 2026 00:00:00 GMT

I stopped writing safety rules into my agents' system prompts. Here's the stack that replaced them, and why one acquisition just made the whole thing boring, in the best possible way.

Every other post about "safe AI agents" lands in the same place. Write better guardrails into your prompt. Be more explicit. Add a never do X section and a stern tone. I did exactly that for months. The problem shows up the first time an agent reads "do not touch production without confirmation," agrees enthusiastically, and reaches for it anyway.

So let me say the thing plainly. A prompt is not a security control. It's a wish.

A language model is probabilistic by construction. When you write "never spend more than the budget" or "never open a public port," you are not setting a hard limit. You are nudging a token predictor and hoping the nudge holds under pressure. It usually does. Until the one time it doesn't, on a Friday evening, against the "unused" database that turns out to be load-bearing for somebody's revenue. Autonomy without a hard boundary isn't innovation. It's catastrophe at machine speed.

The interesting question was never how do I make the agent smarter. It's what can this agent physically not do, no matter what it decides. And the honest answer, for the first time, is: quite a lot. Most of it shipped in the last few months, and most of it now lives under one roof.

The boundary doesn't live in the prompt

So where does the boundary live, if not in the prompt? Over the last few months it moved down into the infrastructure layer. The clearest evidence is what HashiCorp shipped for native agentic identity in May 2026. The secrets handling is solid. But the part worth slowing down on is the authorization model, because it's what turns please behave into you can't.

Here it is, because it's the whole article. An agent's permitted action is the intersection of three policies: the human it's acting for, the agent's own policy, and a ceiling that nobody, human or machine, is allowed to cross. On top of that, the authorization is scoped to the specific request and expires with it.

Read that twice. The agent never holds a standing key. It receives a temporary, request-shaped permission that is the narrowest of what the human may do, what the agent may do, and what the ceiling allows. Traditional IAM was built for deterministic users doing predictable things. This is built for a non-deterministic actor that changes behavior at runtime every time it picks a different tool. Which is exactly the threat model everyone was hand-waving about a year ago.

A few things fall out of this the moment you build on it instead of arguing with the model:

Dynamic secrets instead of hardcoded ones. The agent needs database access to refactor a schema? It never finds a password in a .env file. Vault issues a short-lived, identity-bound credential that dies on a timer. If the agent hallucinates and dumps its credentials into a log, they're already worthless.

Every action is attributable. In HashiCorp's validated pattern, the path Web → Agent → MCP server → Vault carries one correlation identifier end to end. When something goes wrong, you don't ask "what did the AI do." You pull the trace and see precisely whose authority the agent was borrowing, for which request, and what it touched.

Policy-as-code does the enforcing, not goodwill. The agent can generate elegant, fast Terraform. If that Terraform creates an S3 bucket without encryption, Sentinel rejects the plan before it applies. The rule is enforced by a machine. It does not care how confident the model sounded.

None of that is a better prompt. All of it is a wall.

What IBM quietly assembled

While the rest of the industry argued about how to make agents behave, IBM was buying the parts to make sure they can't misbehave. The cage already exists. One company just spent the last year bolting the bars together.

IBM closed its $6.4 billion acquisition of HashiCorp in February 2025. At HashiConf 2025, HashiCorp's first conference as an IBM company, the direction stopped being abstract. MCP servers for Terraform, Vault, and Vault Radar gave AI agents a governed, role-scoped, auditable way to act on infrastructure, instead of handing them broad API tokens and praying. Then in May 2026, Vault shipped the native three-policy agentic identity model I just walked through, and at Think 2026 the secrets layer rolled forward into Vault Enterprise 2.0.

Stack it up and the shape is obvious.

Identity and a hard ceiling at the bottom: Vault. Policy-as-code on the deploy path: Sentinel. A governed interface for the agent to even reach your infrastructure: MCP servers. And over the top, a methodology. IBM published Architecting Secure Enterprise AI Agents with MCP (verified by Anthropic), introducing the Agent Development Lifecycle (ADLC): six phases (Plan, Code & Build, Test & Release, Deploy, Operate, Monitor) that extend DevSecOps for stochastic, tool-using agents, with an MCP Gateway that centralizes authorization, policy, rate limits, and audit. I walk through all six phases, one at a time, here. Treat agents not as static applications you ship once, but as long-running systems you continuously evaluate, secure, and govern.

And then there's the control plane. watsonx Orchestrate now governs an organization's agent fleet across frameworks (IBM-native agents, Langflow, LangGraph, agents built on the open A2A protocol) through one operational layer, with AgentOps providing lifecycle observability and real-time policy enforcement. The problem watsonx Orchestrate is built to solve has a one-word name: sprawl. Agents are being spun up in every team, on every framework. Without a single place to run, govern, and observe them, you don't have automation. You have a very fast mess with dashboards.

The practical takeaway for anyone running a platform team: stop building this yourself. I keep meeting teams burning senior-engineer quarters on homegrown sandboxes and wrapper scripts to stop AI tools from breaking things. Pure, unbillable R&D inside companies whose actual job is retail, or fintech, or streaming. The primitives are assembled now. Hand-rolling a worse version of Vault's ceiling is no longer brave, just expensive.

What's real, and what's still a slide

I'm an IBM Champion. Let me use that to be useful instead of to cheer.

What has actually shipped, and you can build on today: Vault's native agentic IAM, the MCP servers (beta, but real), Sentinel, watsonx Orchestrate with AgentOps, and the ADLC guide. That is a working foundation, not a roadmap.

And what is still a bet? Project Infragraph, HashiCorp's real-time infrastructure graph designed to be the context layer an agent reasons over, opened as a private beta in December 2025 and reached public preview at Think 2026 in May 2026, delivered as "HCP Terraform powered by Infragraph." But it's still beta, US-only, and HashiCorp itself discourages pointing it at production workflows. The vision is that the same graph will eventually let AI reason about infrastructure state, propose runbooks, and act across the lifecycle, and to connect outward to the broader IBM portfolio, including Red Hat Ansible, OpenShift, watsonx Orchestrate, Concert, and Turbonomic. That vision is the right one, because it answers the oldest objection to autonomous agents: the agent doesn't know your business context. But it is a bet. Architect on the cage (Vault, Sentinel, the MCP gateway), which is production-grade today. Pilot the context brain. Don't bet your 2026 on a beta the vendor won't yet aim at production, however good the demo looks.

That distinction is the whole point of reading independent analysis instead of a press release.

The job changes, it doesn't disappear

We're moving from hand-writing configuration to intent-based operation. Machines will write the infrastructure code. That isn't a forecast anymore. It's a release note.

But your value as a Head of Platform or an architect doesn't evaporate with it. It moves. You stop reviewing every line of YAML before the merge and start designing the boundary instead: where Vault's ceiling sits, what Sentinel rejects, which gateway the agent reaches through, which ADLC phases every agent clears before it sees production. You used to be the last pair of eyes before the merge. Now you're the architect of the cage the machine runs full-speed inside, and physically cannot break the things that must not break.

That's the end of TicketOps, and honestly, good riddance.

So. This one is for the platform leads. Stop writing your agents polite instructions and hoping they hold. Stop spending senior time reinventing a worse Vault. Put that time into the architecture of the boundary instead. This was the conversation across this spring's conference floors, RSAC in March, Think 2026 in May: the industry has finally stopped asking how clever we can make the agent and started asking how tightly we can bound it.

That was always the more interesting question. The future doesn't belong to whoever has the smartest agent. It belongs to whoever knows, precisely, what their agent can't do.

CNCF Q1 2026 Report — Why Feature Flagging Is the Hidden Gateway to Cloud Native Maturity

Tatiana Mikhaleva (devops.pink) — Sat, 16 May 2026 00:00:00 GMT

CNCF and SlashData just dropped their Q1 2026 State of Cloud Native Development report. Over 12,800 developers across 100+ countries answered it. And this is not a press release stuffed with vanity metrics. It's raw data on how the industry actually operates right now.

I read the whole thing, cover to cover, then went and pestered the author, Liam Bollmann-Dodd from SlashData, for the context that didn't make it into the public PDF. Fun fact: Liam is a former antimatter physicist with a PhD from CERN. Which explains so much about how carefully the statistics in this report are put together.

Here's what jumped out at me, and what I'll be watching next quarter.

20 million cloud native developers

The headline number first. The cloud native community has grown to 19.9 million developers, up from 15.6 million in Q3 2025. That's roughly 39% of every developer on the planet. Almost four in ten of us.

But there's a wrinkle in the backend data that most recaps are going to skip right over. Among backend developers, 52% are classified as cloud native. That's a drop from 58% last quarter. Still higher than the 49% we saw a year ago, though. And SlashData doesn't dodge it: either the 58% in Q3 2025 was inflated, or this is a real quarter-on-quarter correction. Q3 2026 will tell us where the true baseline sits.

One more number worth holding onto. 71% of backend developers use at least one cloud native technology, but only 52% clear the classification bar (which means using 3+ technologies). That 19-percentage-point gap? Those are people in the early innings of adoption. They've picked up a tool or two, but they're not running a mature stack yet.

Cloud native stopped being an emerging technology a while ago. It's now what git became a decade ago. The default baseline skill.

Containers became invisible

Container usage in the survey fell from a steady 60%-plus all the way down to 40%. Glance at that and you'd assume containers are dying.

They aren't. They just turned into infrastructure.

Some of the drop is methodology, plain and simple. SlashData widened the definition of a backend developer to fold in web backend folks who work through higher-level services. Run the model with the old historical definition and container adoption is actually 58%, not 40%. So changing who got surveyed mechanically dragged the number down.

The deeper story is the one that matters. 88% of backend developers now work with some form of infrastructure standardization, up from 80% six months ago. And the slice of developers with no formalized platform or DevOps practices dropped from 20% to 12%.

Platform engineering teams went and built internal developer portals. You click "deploy," and somewhere underneath there's Kubernetes, containers, orchestration, all of it humming along. You just never see it. No Dockerfile. No SSH-ing into a cluster.

The report has a striking example here. 39% of backend developers use microservices, yet only 27% explicitly say they use Kubernetes, even though microservices usually run on it. So the report poses a blunt question. When a developer ships a containerized app through an IDP without ever touching a Dockerfile, do they even think of themselves as a "container user"?

Containers haven't gone anywhere. They've become the electrical wiring in your office. Critically important. Completely invisible until the moment something fries.

And this is where I get a little nervous, and so do the report's authors. They say it outright: organizations need to make sure infrastructure expertise still exists within teams to manage, troubleshoot, and optimize the platforms that enable productivity. So when the platform breaks at 2am, who on your team actually knows what's under the hood?

I lurk in the DevOps communities, Reddit, Hacker News, the K8s Slack, and over the last six months a pattern has gotten really hard to miss. More and more mid-level developers are asking genuinely basic questions about kubectl. These are not juniors. These are people who've been deploying through an internal portal for three years and have literally never seen raw Kubernetes.

Feature flagging, the report's biggest surprise

This is the finding that makes the whole report worth your afternoon.

For the first time, SlashData ran association analysis. That means looking at which technologies show up together more often than random chance would predict. The metric is called "lift." A value above 1.0 means the technologies are connected. Above 1.7 is a strong connection.

The data shook out into three tiers of maturity:

Foundational: Kubernetes + microservices. The price of admission.
Mainstream: Observability, streaming/messaging, event-driven architecture. Operational sophistication.
Advanced: Immutable infrastructure, chaos engineering, service meshes. Only 6-7% of teams are here (immutable 7%, chaos 6%).

So the real question becomes: what actually moves a team from mainstream to advanced?

Your gut says more Kubernetes, or some fancy service mesh. Sounds reasonable. The data says no. The answer is feature flagging.

The specific lift numbers spell out why. Feature flagging has a strong link to mainstream and advanced practices at the same time:

with observability tools: 1.53
with event-driven architecture: 1.45
with chaos engineering: 1.44
with multicluster management: 1.40
with immutable infrastructure: 1.33

It's literally the bridge between tiers 2 and 3. For anyone who hasn't lived with it: feature flags let you deploy code to production without showing it to users right away. You roll a feature out to 5%, watch the metrics, then keep going. Or you roll it back without redeploying a thing.

The report explains the gateway effect like this. Feature flagging drills two ideas into a team. Decoupling deployment from release, and incremental testing on a subset of traffic. Those mental models carry straight over into advanced practices, chaos engineering (controlled failure injection) and immutable infrastructure (deployments as disposable experiments).

When I asked Liam about all of this, he handed me the context that never made the PDF:

"We did the analysis blind, so as not to put any of our expectations on it. However, for several years we have been grouping these cloud native practices and technologies into three groups on usage rates (entry, mainstream, advanced). This has kind of been normalised as a description, but has previously lacked the data to demonstrate that this tiered approach reflects an actual journey of maturity. During the analysis, we found validation for our previous descriptions, but were surprised by how pivotal feature flagging as a practice was to the cloud native maturity journey. Bringing this to people I consider experts in this space, the general consensus was that it 'makes sense' for feature flagging to be so important to engaging in the elite cluster of practices, but they would not have predicted how important it was."

— Liam Bollmann-Dodd, Principal Market Research Consultant, SlashData

There's an important nuance buried here: there are two roads to the advanced tier, not one. You get there through experimentation maturity (feature flagging) or through operational visibility (observability tools, which carry a 1.33 lift with immutable infrastructure). But feature flagging is the friendlier on-ramp.

Why does that matter in practice? Because you can stand up feature flagging without re-architecting your whole system. It isn't a months-long migration. For teams stuck spinning their wheels in the mainstream tier, the data hands you a specific, actionable answer.

One last detail, and it's a good one. The strongest connection in the entire dataset is immutable infrastructure + chaos engineering, sitting at 2.22. Which tells you that teams reaching the advanced tier don't pick these practices off one at a time. They adopt them as a bundle. The advanced tier isn't a gradient. It's a cluster. You're either in it or you're not.

AI teams are taking a different path

Here's where the data gets genuinely fun. AI teams are not walking the same maturity path as backend teams.

For your standard backend developer, immutable infrastructure is an elite-tier destination (that 2.22 lift with chaos engineering). For AI teams? Immutable infrastructure is a gateway technology they reach for early.

Why? Reproducibility. The report says it plainly: for AI teams, immutable infrastructure ensures reproducible training environments and consistent deployment artifacts. Plenty of AI teams park in the experimentation phase, where reproducibility is everything and chaos testing simply isn't. Which is exactly why, for AI, immutable infrastructure is bound more tightly to observability (1.58) than to chaos engineering (1.28, versus 2.22 for general backend).

The second surprise is remote procedure calls (RPC). In standard backend development, RPC is nearly invisible. For AI teams the connection between RPC and feature flagging jumps to 2.07 (against 1.16 for general). That tracks with how central RPC is to model inference APIs, distributed training, and feature store access.

So the practical takeaway for anyone building platforms for AI teams:

Not every AI team needs production-scale complexity. Many legitimately stop at the experimentation or training stage.
Feature flagging and immutable infrastructure are dual prerequisites for production AI. This is a key bottleneck.
Service mesh, chaos engineering, and multicluster management need to be framed specifically for AI: traffic splitting for A/B testing models, resilience testing for model degradation, geo-distributed inference. Don't use generic infrastructure benefits to sell it.

If your org runs both backend services and AI workloads, then your platform team is quietly building toward two completely different definitions of "good" all at once.

What didn't make the report

I asked Liam whether anything interesting in the data got left on the cutting room floor. His answer turned out to be the most valuable bit of the whole conversation.

The report notes that 88% of developers work with some form of DevOps standardization, but the approaches swing wildly for organizational reasons. Liam flagged this as a personal interest of his. The shift-left and shift-right approaches to standardization.

A few specifics he gave me:

Highly regulated industries (finance, healthcare) get aggressive about standardization.
SaaS companies lean toward looser standardization.
Developer density at a company is a major driver of which methods get chosen.

And here's his core message to vendors:

"...most teams are working with extreme constraints on capital, people, or tool access. As such, I want to continually remind vendors and platform tooling companies that for many organisations it is heterogenous mess of a tech stack that is held together more by hope than a perfectly designed and architected system."

— Liam Bollmann-Dodd

Sit with that one for a second. Conversations about "good engineering teams" love to get stuck in philosophy. Framework choices. Endless debates about architectural purity. Meanwhile actual teams are operating under brutal constraints. Their stack is whatever managed to survive three reorgs, two cloud migrations, and an acquisition.

That's not a failure on their part. It's the real operating environment of cloud native development in 2026.

I read engineering blogs, incident post-mortems, community Slack threads. Liam's point checks out everywhere I look. Teams from scrappy startups to FAANG describe their stacks the exact same way. "It's a mess, but it works." The only thing that changes is how willing they are to say it out loud.

What I'm watching for in Q2

When the Q2 report lands (usually June-July), here's my list:

Will the backend cloud native percentage steady out? 52% in Q1, after 58% in Q3 2025. SlashData themselves say Q3 2026 reveals the true baseline. This is a leading indicator for the health of cloud native adoption.
Will feature flagging graduate from "predictor" to "default"? The report has now named feature flagging as a gateway. Will engineering leaders read that and actually move? If adoption spikes among mainstream teams, we'll know industry research is genuinely steering decisions.
Will the gap between AI and backend paths get wider? Q1 showed AI teams using immutable infrastructure as a gateway rather than a destination, and RPC as critical for them. Q2 tells us whether that's a stable pattern or just an artifact of where AI maturity sits today. My money's on stable.
Will the advanced tier stay rare? It's at 6-7% right now. If Q2 shows growth, something shifted in tooling accessibility. If it stays flat, we're staring at a genuine industry ceiling, meaning most teams will never reach the advanced tier no matter how many conference talks get given on chaos engineering.
What new analytical trick will SlashData pull out? Q1 introduced association analysis with the lift metric and journey maps. That was a serious methodological leap. So what does Q2 add?

Practical takeaways for right now

Don't sit on your hands waiting for Q2. Q1 already handed us things to act on today:

If your team is stuck in the mainstream tier, take a hard look at your feature flag tooling and discipline. The lift data says this is your most reliable bridge to the advanced tier. The backup route is through observability.
If your developers can't pop the hood on a container when it breaks, you've got a training gap. The report says it flat out: make sure infrastructure expertise actually lives inside your team.
If your platform serves AI workloads, remember those teams are on a different path. Immutable infrastructure is their gateway, not their destination. And RPC matters more than you think.
If your stack is held together by hope and stale Confluence docs, congratulations, you're in the majority. That isn't a failure. The only failure is pretending otherwise in roadmap meetings.

The Q1 2026 report gave us the data. Q2 will tell us what we actually did with it.

The State of Cloud Native Development Q1 2026 report was published by CNCF and SlashData based on the 31st wave of the Developer Nation survey (December 2025 — January 2026). 12,800+ developers across 100+ countries. Liam Bollmann-Dodd, Principal Market Research Consultant at SlashData and author of the report, provided exclusive commentary for this article.

AI SRE Joined My On-Call — A Beginner-Friendly Walkthrough of Rootly

Tatiana Mikhaleva (devops.pink) — Tue, 12 May 2026 00:00:00 GMT

You know the feeling, darling. You finally sat down to eat, or just closed your laptop for the night. Then your phone lights up. P1. Prod is down.

If you're new to on-call, that first incident is rough. Slack has twelve people typing. Your dashboards are a wall of red. And you're flipping between logs, recent deploys, and that PR a coworker merged twenty minutes ago. Was it the deploy? The cache? CI/CD? Half the code in your stack was written by someone who left two years ago. The other half? Written by an AI nobody fully audited. Welcome to modern on-call, queen.

There's a whole new category of tooling trying to close that gap, and it goes by AI SRE. So I walked through one of them, Rootly. Here's the honest beginner's take.

import VideoPlayer from "@components/VideoPlayer.astro";

Why "AI SRE" became a thing in 2026

Three forces converged here. First: microservice sprawl. No single human can hold the whole architecture in their head anymore, full stop. Second, the people who actually wrote half the code have moved on, and they took all their context with them. Third, LLMs finally got good enough at code reasoning that they can plausibly rebuild that lost context from logs, runbooks, and old postmortems.

So no, "AI SRE" isn't a fancy way of saying "we dropped a chatbot in our incident channel." It's tooling that swallows your whole incident surface area, runbooks and past postmortems and Slack incident channels and IaC and application code, and then helps you reason about a failure faster than you ever could on your own.

The AI is really doing two jobs here.

Indexing your tribal knowledge. Every postmortem you've ever written. Every Slack thread where someone went "oh, this is just X again." That's all training material your AI SRE keeps loaded and searchable, sis.
Correlating live signals when an alert fires. Logs, metrics, recent commits, recent deploys. It yanks those together and hands you a hypothesis with citations: "This looks similar to incident #438 from last March, and a deploy went out 12 minutes ago that touched the same code path."

You still decide what to do. You just skip the thirty minutes of frantic tab-switching that usually comes before any real thinking starts.

How Rootly handles trust: the four-level model

Okay, this is the part I actually cared about. AI in production sounds dreamy in a demo. It sounds terrifying when it's firing on a real incident at 3am. Because nobody, and I mean nobody, wants an autonomous agent rolling back deploys because it pattern-matched on the wrong thing.

Rootly publishes an AI SRE Maturity Model with four explicit levels, and you adopt them one at a time. The names in the docs are pretty formal. Here's the practical version, code cuties.

Level 1 — Observe. (Officially: "Read-Only Copilot.") The AI watches and produces context packets with verifiable hypotheses linked to evidence. It does not execute anything. This is the trust-building stage. You can challenge every conclusion, and the AI shows its work.

Level 2 — Advise. Still technically part of Level 1 in the formal model, but worth calling out on its own. Now the AI suggests specific next steps and brings a reasoning trail along: "Consider rolling back deploy abc123. Here's why." You still drive.

Level 3 — Approve. (Officially: "Assisted Actions With Approvals.") Now the AI can initiate actions like rollbacks, config changes, and scale-ups, but only through a workflow engine that enforces RBAC, audit logs, and verification gates. Nothing executes without a human approval click. This is where the time savings really start to stack up.

Level 4 — Autonomous. (Officially: "Guardrailed Autonomy for Narrow, Reversible Failure Modes.") As Rootly puts it: "This is not 'AI resolves incidents.' It is 'AI resolves a small number of repeatable incidents safely.'" Autonomous execution applies only to allow-listed, reversible runbooks with clear preconditions and stop conditions. Most teams get here only for a handful of specific failure modes, and only after months of safe operation at Level 3.

The philosophy holding all of this up is what Rootly calls "human-on-the-loop." An engineer always has the final say on critical actions. Accountability stays human. That's the right framing, and honestly it's what separates the serious AI SRE products from the demoware.

What stood out beyond the trust model

The post-incident timeline writes itself. Once an incident closes, Rootly assembles the full sequence: when the alert fired, who joined the war room, what commands got run, what was tried, and what actually fixed it. My postmortems usually eat an hour, minimum. This drops the whole thing to "review and edit." Bless.

Citations on every recommendation. When the AI suggests a fix, it links straight to the past incident, runbook, or code line that informed the call. You can push back. AI tools that refuse to show their work make me nervous, and this one doesn't.

Bring your own AI API key. You plug in your own LLM credentials, whether that's OpenAI, Anthropic, or a self-hosted model. Your incident data stays scoped to your account. And Rootly's docs are blunt about it: "PII is automatically scrubbed and never used for training. Opt out anytime." For anyone in a regulated industry, that one line is the difference between "let's evaluate this" and "we can't even start the conversation."

The Rootly MCP server. Now this is the very 2026 part I didn't see coming. Rootly ships an MCP (Model Context Protocol) server that wires your incident context straight into IDEs like Cursor, Windsurf, and Claude Desktop. Mid-incident, you can ask your editor "what was the last change to the auth service?" and the answer comes back from Rootly's correlation engine, no copy-pasting between five windows. If you've been watching the MCP wave, this is exactly the kind of practical integration the protocol was built for.

The customer list leans heavy on names you'd know on sight: NVIDIA, Canva, Webflow, Figma, LinkedIn, Replit, Grammarly, Mistral AI, Brex, DoorDash, SoFi. That's not some weekend side-project tool. That's running production at scale.

Will it replace me?

Honest answer? No. But it does change the job.

Think about what a junior on-call shift looks like today. Mostly it's "navigate to the right dashboard, spot the obvious thing, page a senior if it's not obvious." Levels 1 and 3 of the trust model swallow the navigation and the obvious stuff. What's left for the human is the part that's actually judgment: "is this the right rollback target," "do we communicate to customers now," "is this incident a symptom of a deeper architectural problem."

And that's a better job, sis. Less tab-juggling, more thinking. The road from junior to senior gets shorter, because you spend your rotation on real decisions instead of pattern-matching against dashboards all night.

Who this is for

Solo SRE drowning in alerts? This is for you. Team lead watching your engineers burn out on rotation? Also for you. And if you're early in your career and just want to see what production on-call actually looks like, walking through Rootly's setup is a genuinely decent way to learn what the work feels like before your first real pager.

The promise here isn't "AI replaces your on-call." It's "AI handles the busywork so the thinking part goes faster." Which, after a year of false-positive alerts and broken pager rotations, is what most of us actually need.

So if on-call is starting to hurt, Rootly is worth a real evaluation. Start at Level 1, observe-only, and see what it catches that you'd have missed. You don't promote to Level 3 until you trust the Level 1 output. That's the right shape for adopting any AI tool in production, queen.

Stop Lying About Your Backups — Zero-Trust Recovery with Plakar

Tatiana Mikhaleva (devops.pink) — Tue, 10 Feb 2026 00:00:00 GMT

Hey my DevOps queens (and kings, too)! 👑

Sit with me for a sec. Put down your coffee. Close your tickets. I want to talk about something a little uncomfortable, because I know your secret.

You're lying.

Every morning, you look at those green backup checkmarks and tell the business:

"We are protected."

And deep down? You're praying you never have to test that theory. Because here's the thing you already know in your gut: if prod goes down, those checkmarks won't save you.

That's not a strategy, sis. That's chronic fear.

So relax. ✨ We're not fixing your services today. We're treating your fears. The stuff that keeps you up at 3am, scrolling, wondering. We'll walk through your traumas one by one, and we'll shut every single one of them down.

And for this, we'll use Plakar. 🛡️

It's Open Source, which I know matters to you. No black boxes.

import VideoPlayer from "@components/VideoPlayer.astro";

1. The Fear of Recovery

Your first trauma? The fear of recovery.

You know the nightmare. You restore the files, and then the system just... doesn't work. Why? Standard backups save the data, but they lose the context. So you end up with:

Permissions are broken
Timestamps are reset
Dependencies are gone

Pure chaos. You've got all the pieces and none of the picture. Your system has amnesia, darling.

Plakar is Digital Memory

It preserves the exact state: ownership, modes, extended attributes. The relationships between files stay intact. You open Plakar, you restore the snapshot, and that's it. Fast, granular, and reliable.

2. The Trap of Dependence

Next one. You feel dependent.

Everything lives in the cloud, and you know exactly what that means. If they hike prices tomorrow, or lock your account, you can't get your data out fast. You're trapped.

Plakar treats this with total portability. It packs your data into a Kloset, a self-contained repository. 📦

Keep it on S3 today. Tomorrow, replicate those snapshots to a totally different Kloset store:

Local disk
Another cloud provider
Wherever you want

No format conversion. No painful migrations. The data belongs to you, not the infrastructure. You are free to choose where to live.

3. Paranoia

Point three is Paranoia.

You send data to the cloud, and so often, the control over where and how encryption happens just isn't yours. You're forced to take their word for it.

But what if they get hacked? What if some rogue insider decides to peek at your files? You're handing your secrets to total strangers.

Client-Side Encryption

Plakar does it differently, queen. Data gets encrypted on your end, at the source, before anything leaves for storage. Nothing readable ever reaches the cloud.

To the outside world, it's just encrypted chunks. Meaningless without your keys. You can delegate storage without ever delegating access. And the risk of a cloud breach? It drops, hard.

You are protected.

4. Budget

And finally. Budget.

You stare at the cloud bill and it hits you: you're paying for air. Fifty copies of the same operating system, sitting there. You're paying for the same thing fifty times over. Your infrastructure is bloated, plain and simple.

Smart Deduplication

Plakar cuts the fat. It breaks files into chunks. So if you've got a hundred near-identical servers, those repeated chunks don't get duplicated. Not even once.

What you get:

Drastically smaller storage footprint
Significantly lower storage bills
No wasted company money

And your CFO will finally be happy.

The Prescription

Your fears aren't just "part of the job," code cuties. They're symptoms of outdated architecture.

You don't have to learn to live with the pain. You need to change the tool.

Here's what Plakar gives you:
✅ Predictable recovery
✅ Independence from clouds
✅ Real privacy
✅ Smart savings

That's our session for today. Go try Plakar, and start sleeping peacefully again.

Escaping the Command Line Cartel: Why I Mandate Visual Git in Enterprise DX

Tatiana Mikhaleva (devops.pink) — Thu, 15 Jan 2026 00:00:00 GMT

Okay, darlings. Let's talk about the elephant in the server room. I mean the way we all worship the CLI like it's sacred. 💅

I get it. For years now, living inside the terminal has been this little badge of honor in engineering. You're "real" if you never touch a mouse. But here's my hot take, queen: judge it strictly as a Developer Experience problem and the terminal starts looking less like a flex and more like a toxic ex. Endless flags. That tiny heart-stop before you hit Enter on a force push. All that mental juggling we just... accept, because "that's how real engineers do it." No. That's gatekeeping wearing an architecture costume. Real engineering cares about safety and speed and actually being able to SEE what's happening. So I ripped up my whole version control workflow and made GitKraken my main Git interface. Best decision, honestly.

Let me walk you through why the visual approach wins. Section by section, sis.

import VideoPlayer from "@components/VideoPlayer.astro";

1. High-Signal Telemetry (Total Honesty)

The terminal hides the story from you. Want to understand how a messy repo actually got messy? You interrogate it with git log and then try to draw the whole multi-branch commit tree in your head like some kind of psychic. Cute. Exhausting.

GitKraken just shows you. Right there. The commit graph is laid out in full, every branch and every merge and every weird little pivot, all mapped in front of your eyes. And it isn't only a pretty GUI, code cuties. It's an honest, auditable picture of what your team actually did. You see who, what, and why. No query required.

2. Tactile Architecture & Frictionless Workflows

In the CLI you're basically muttering abstract spells into a black box and hoping. There's this gap between the command you type and the thing you're actually trying to do.

GitKraken closes that gap. It makes version control something you touch. Need to merge or rebase? I don't sit there reciting syntax from memory like it's a final exam. I grab the branch. I pull it onto the other one. Drag. And. Drop. That's it. The distance between "what I meant" and "what happened" basically disappears, and I get to move at the speed of my own brain.

3. Adult Conflict Resolution

Resolving a gnarly merge conflict in the CLI is, honestly, a stress-management exercise. The terminal hits you with a wall of text, and one bad keystroke breaks the build. Fun!

GitKraken turns that whole panic spiral into a calm little conversation with your code instead. The visual merge conflict editor? Chef's kiss. Honestly a masterclass in DX:

I see my version.
I see the incoming version.
I see the output.

A couple of clicks to pick what stays and what goes. No spiraling. No mangled syntax. Just a clean, resolved deployment and a queen who is still relaxed.

4. Psychological Safety (The Magic Button)

Enterprise infrastructure needs real guardrails. Because we all mess up sometimes, and in the terminal a bad commit feels like the end of the world.

So here's the part I'm a little obsessed with. GitKraken gives you the Undo button. Drop a stash? Botch a rebase? Commit to entirely the wrong branch? One click and the state snaps right back to where it was. Knowing that safety net is there genuinely changes how I work. I get bolder. I move faster. I stop tiptoeing.

5. Ecosystem Interoperability

A tool is only as good as everything it talks to. And GitKraken doesn't sit off in its own little corner, sis. It plays nicely with the rest of your stack.

It hooks straight into Jira, GitHub, and GitLab, so all the context lives in one spot and I'm not drowning in ten browser tabs anymore. Even better: through GitLens in VS Code, that visual context follows me right into my IDE. You get inline telemetry showing exactly who wrote a line and when, sitting quietly in your editor, ready the second you need it.

The Executive Verdict

Gorgeous. Intuitive. Ruthlessly efficient. It handles merge conflicts where you can actually see them, slots neatly into the enterprise stack, and cuts down on the dumb human errors we all make.

Does your terminal do that?

If you're done fighting your own tools and you want to level up your Developer Experience, grab GitKraken through my strategic alliance link below.

🦑 Deploy GitKraken Pro (50% Executive Subsidy) ->

Then come tell me about it in the Discord Syndicate: are you staying loyal to the terminal, or are you ready to upgrade your architecture?

Kubernetes Is No Longer Number One — The REAL 2025 Cloud Native Report (CNCF x SlashData)

Tatiana Mikhaleva (devops.pink) — Sun, 30 Nov 2025 00:00:00 GMT

Hey my cloud-native queens, kings, and everyone shipping to production in between.

So I read the whole thing so you don't have to. We're walking through the key facts from the 2025 “State of Cloud Native” report by CNCF and SlashData, and there's a lot here.

The big spoiler first: Kubernetes is NO LONGER the most interesting number.

Everyone's chasing K8s. Meanwhile the real action is happening somewhere else entirely.

Where do these numbers come from? Over 12,000 developers from 128 countries, surveyed between June and July 2025, sliced by role: backend, DevOps, ML/AI, IoT, and games. Solid sample, darling.

Okay. Facts time.

import VideoPlayer from "@components/VideoPlayer.astro";

Finding Number One: Backend won

56% of backend developers are now cloud native.

Put that in raw headcount and you get 15.6 million cloud-native developers, of which 9.3 million of them are backend. Backend is the engine room, sis.

Why care? Because backend teams are the ones carrying the weight. APIs, observability, microservices, CI/CD, who actually owns a service at 3am. All of it.

So if you're building a platform, build it for backend and DevOps. Not for “everyone in general,” because “everyone in general” never ships.

Backend + DevOps is the new core of the cloud-native community.

Finding Number Two: AI is not that cloud native

You'd assume AI/ML lives in the cloud, GPUs blazing, all-in. Nope. Only 41% of ML/AI professionals are cloud native.

The report points to one big culprit: heavy reliance on MLaaS, those managed services that hide the infrastructure from you completely.

Here's the gap. AI models keep scaling like crazy. But the boring DevOps discipline — logs, versioning, deployments — tends to limp along behind.

And that gap? That's the opportunity, queen. If you're in DevOps, SRE, or Platform Engineering, this is your moment to bring real engineering hygiene into MLOps. Actual pipelines. Versioned environments. Logs that exist. Managed clusters that someone owns.

Finding Number Three: What's really being used

The most-used cloud-native tech is not exotic. Not even a little. It's deeply, refreshingly boring:

API gateways — 50%
Microservices — 46%
Kubernetes — 28%
Observability — 28%

Notice anything? Observability (28%) just caught up to Kubernetes (28%). People finally clocked that “just running it” isn't the finish line. You have to see what's happening too.

Then there's service mesh. 8%. Eight percent, code cuties. The hype made it sound like 80.

So no, the world is not living in “service mesh everywhere.” The world is living in:

just give me a solid gateway, logs, and orchestration.

Building a product for DevOps? Aim at this reality. Not at some super-exotic architecture almost nobody actually runs in prod.

What to do with this data

If you're an architect, a DevOps lead, or the person building the platform, here's what the report is really telling you.

Go backend- and DevOps-first. These two groups are the most cloud-native in the whole report. This is where IDPs, artifact repositories, and policy-as-code earn their keep.
Support hybrid. 30% of all developers are on hybrid cloud, and 23% are multi-cloud. Your networking, secrets, and observability have to span everything. One provider is not the whole picture anymore.
Bring ML teams up to code. Got ML folks in-house? Give them the exact engineering hygiene your production teams already have. Versioned environments, pipelines, logs, clusters, proper deployments. The works.
Don't over-engineer. The mainstream stack is this: API gateways, microservices, Kubernetes, plus observability. It is not a universal service mesh draped over everything. It's mature, it's understandable, and you can actually ship on it and make money.

Final verdict

Cloud native is now mainstream for backend and DevOps. AI is the one still playing catch-up.

So how does this map to your world? Do these numbers match what you're seeing day to day, or is your stack heading somewhere totally different?

Tell me in the comments, darling. I'm genuinely curious how this data lands against real life.

Amazon Q - The AI DevOps Tool That Fixes AWS Headaches

Tatiana Mikhaleva (devops.pink) — Mon, 10 Nov 2025 00:00:00 GMT

You know that feeling when something breaks in AWS and nobody can tell you why?

Yeah. Today's post is about fixing that.

import VideoPlayer from "@components/VideoPlayer.astro";

Meet Amazon Q

An AI assistant, baked right into AWS. Marketed as your shiny new cloud teammate.

But it's not here to chat, darling. It's here to actually help.

Not “Hello, World.” More like:

“Why does your IAM keep blocking Lambda again?”

It looks at your setup. Your permissions. Your whole infrastructure.

Picture a senior AWS engineer trapped inside your console, and you get to say:

“Please explain why nothing works. Again.”

And honestly? Sometimes it beats that coworker who answers three days later and still misses the point entirely.

How It Works in Real Life

Sounds lovely on paper. But what does it look like once you're actually in there?

Here are a few moments anyone who's touched AWS will recognize instantly.

Example 1: The Silent Lambda

You try to run a Lambda. Nothing happens.

No errors. No logs. Just silence.

So you start guessing. Wrong trigger? Bad permissions? Who knows.

Q checks your config, your IAM, your event sources, and comes back with:

“Missing permission here. Add this - and you're good to go.”

Example 2: Building a VPC

You want to spin up a VPC with NAT and two subnets.

The usual cost: 30 minutes of Googling and a hundred lines of YAML-induced misery.

Q just goes:

“Here's the template. One click - done.”

Example 3: Route 53 DNS Setup

Now you need to configure DNS in Route 53.

You open the console and suddenly it's day one in AWS all over again.

Q won't bury you under 10 outdated forum links. It tells you what to do and why it matters, and it walks you through the steps. You'll still need to describe your setup, of course.

Who Amazon Q Helps

This isn't only for the people drowning in IAM configs or forgetting how to YAML for the fifth time today.

New to AWS? Q will explain where you got stuck, and why.
Already experienced? It'll hand you back a couple of hours a day.
Working in a team? Fewer sync calls. More releases. Way less pain.

Q's always got your back, sis.

ChatGPT vs Amazon Q

But what about ChatGPT? It knows everything too, right?

Well, not your account. ChatGPT gives you theory. Q gives you context.

Think of it as handing ChatGPT the keys to your AWS console and whispering:

“Just don't break anything.”

A Few Things to Keep in Mind

A little reality check before you go all in, queen:

Some features are still in Preview
It's not available in every region yet, but it works in us-east-1, us-west-2, and eu-central-1
Got a genuinely complex setup? You'll still need to get hands-on
Living in Terraform or other IaC? Q shines in your editor or CLI, not just clicking around the console

Final Thoughts

Here's the deal, code cuties.

This is the first AI tool that genuinely helps DevOps engineers. Not with theory. With real, practical answers you can actually use.

And not only for the folks who read AWS docs like bedtime stories. Q just gets things done.

So now there's only one question left:

“Will you try it - or keep debugging IAM on Saturdays?”

Join the Conversation

Found this article helpful? Give it a share 😄

Subscribe if you want more DevOps, cloud, and automation content, and come join our Discord (link's in the description).

And tell me in the comments:
What's the one AWS thing that always trips you up?

Maybe Q already knows how to fix it 😉

Inside Helm - How Charts, Releases, and State Work in Kubernetes

Tatiana Mikhaleva (devops.pink) — Sun, 09 Nov 2025 00:00:00 GMT

Hey my DevOps queens (and kings, too)! 👑

Ever deployed an app to Kubernetes and then sat there thinking, “Wait… what actually happens after I type helm install?” Yeah. This one's for you, sis.

Helm makes Kubernetes deployments look easy. Too easy, honestly. Because behind the scenes it's doing way more than rendering a few YAML files. It's a stateful release manager. It tracks every change you make, stores versioned state inside your cluster, and handles upgrades like it actually knows what it's doing — and there's no external database anywhere in sight.

So let's peek behind the curtain. How are charts put together? Where does your release data actually live? And how does Helm keep the whole thing consistent and versioned without breaking a sweat? Grab your coffee. 💅

What's Inside a Helm Chart

A Helm chart is a package. It describes how your app should land on Kubernetes, and it's structured and predictable. Do it right and it becomes gorgeously reusable, too.

my-chart/
  Chart.yaml              # metadata (name, version, dependencies, etc.)
  values.yaml             # default configuration values
  templates/              # Go templates for Kubernetes manifests
    _helpers.tpl          # reusable named templates and functions
  charts/                 # subcharts (dependencies)
  files/                  # arbitrary files used in templates
  crds/                   # CustomResourceDefinitions (installed first)
  .helmignore             # like .gitignore for packaging

Picture it as the blueprint for your app. You flex it through values.yaml, and you can override the defaults at deploy time whenever you like.

Pro tip: CRDs in the crds/ directory are:

installed first,
not templated,
and never upgraded or deleted — this protects existing Custom Resources and data.

What Actually Happens When You Run helm install

There's a sequence here, and it matters. Run helm install and Helm doesn't just “apply some YAML.” It walks through clear steps:

Loads the chart (local or remote).
Merges values from multiple sources:
- base values.yaml;
- any additional files: -f base.yaml -f prod.yaml (left-to-right; later overrides earlier);
- inline flags: --set, --set-string, --set-file, --set-json (these always take precedence).
Renders Go templates into complete Kubernetes manifests.
Applies them to the cluster.

Clean install? Helm just creates the resources. Easy.

Things get a little more interesting if the resources already exist. When they carry the correct Helm annotations (meta.helm.sh/*, app.kubernetes.io/managed-by=Helm), Helm will happily adopt them. If they don't, here's what you get:

Error: invalid ownership metadata

During upgrades or rollbacks, the story changes again. Helm runs a three-way strategic merge, comparing the previous manifest, the new manifest, and the current cluster state. That whole comparison happens client-side, through client-go.

Where Helm Stores Release State

Every Helm release lives inside your cluster. No external DBs. No magic. Promise.

By default, your release info goes into a Kubernetes Secret. You can swap that out for a ConfigMap or a SQL driver (PostgreSQL) if you'd rather.

Default object structure:

kind: Secret
type: helm.sh/release.v1
metadata:
  name: sh.helm.release.v1.<release>.v<revision>
  namespace: <release-namespace>

Now, the .data.release field. This is where the good stuff hides: a base64-encoded, gzip-compressed blob holding the chart archive, the rendered manifests, your merged values, hooks, plus release metadata like revision, timestamps, and status.

One quirk worth knowing. Kubernetes already base64-encodes Secret data, and the release payload also includes encoded sections of its own, so you end up with nested encoding. Encoding inside encoding. Cute, in a confusing way.

Heads up: etcd enforces a ~1 MiB limit for Secret data. Bump into this:

Too long: must have at most 1048576 characters

and it's time to switch to SQL storage:

export HELM_DRIVER=sql
export HELM_DRIVER_SQL_CONNECTION_STRING=postgresql://user:pass@host/db

Labels and Annotations

Helm labels everything it touches so it can track ownership down to the detail.

Added automatically:

app.kubernetes.io/managed-by=Helm
meta.helm.sh/release-name=<release-name>
meta.helm.sh/release-namespace=<namespace>

Best-practice labels (usually added by chart templates):

app.kubernetes.io/instance=<release-name>
helm.sh/chart=<chart-name>-<version>

When these don't line up during an upgrade, Helm refuses to take ownership. And that, darling, is exactly where the classic invalid ownership metadata error comes from.

What Is a Helm Release?

A release is one installed instance of a chart, with a specific set of values, living in a namespace.

Every change you make becomes a new revision. Install, upgrade, rollback, doesn't matter. Each one gets stored right there in your cluster. No external database. No API extension. Just plain old Kubernetes objects, quietly doing their job.

The Three-Way Merge Explained

Here's what Helm lines up side by side when you upgrade:

the previous rendered manifest,
the new manifest (after your changes),
the current live resources.

From those three, it works out a three-way strategic merge patch and applies only what actually changed. Less disruption that way, and your manual tweaks survive where they can.

:::note This logic runs client-side, not via Server-Side Apply. For CRDs or unstructured resources, Kubernetes uses JSON merge-patch, which can behave slightly differently. :::

Namespaces: Release vs Target

Helm splits namespaces into two flavors:

Release namespace — where Helm stores its Secret or ConfigMap.
Target namespaces — where chart resources are deployed (can be multiple).
--create-namespace only creates the release namespace (the one you pass with --namespace).

Got a chart that spreads across namespaces? Then create them yourself, or template them inside the chart.

Tip: Try not to hardcode metadata.namespace unless you genuinely need to. Otherwise helm template | kubectl apply might quietly shove your resources into default.

Storage Drivers

Helm gives you a few backends for storing release state:

export HELM_DRIVER=secret      # default (encoded, secure)
export HELM_DRIVER=configmap   # readable, not encrypted
export HELM_DRIVER=sql         # PostgreSQL – best for large releases
export HELM_DRIVER=memory      # ephemeral, for tests only

Managing Release History

Helm hangs onto all revisions unless you tell it not to. So put a cap on it:

helm upgrade --history-max 10 ...
export HELM_MAX_HISTORY=10

Want to poke through the history? Anytime:

helm history <release>
helm get values <release>
helm get manifest <release>

TL;DR

Helm isn't magic. It's just clean engineering. Every time you fire off helm install, it:

loads, merges, and renders templates,
stores state inside your cluster,
tags resources for ownership tracking,
applies three-way strategic merges on upgrade,
manages revisions — all with zero external dependencies.

Once the inner workings click for you, Helm stops feeling like a mystery box. It starts feeling like your favorite DevOps assistant. 💖

Quick Debug Tip

helm ls -A
kubectl get secrets -A -l "owner=helm" -l "status=deployed"

Great for a fast audit, or just snooping on what Helm's been up to lately.

Git Merge Conflicts for Beginners - What to Do When Your Branches Have Beef

Tatiana Mikhaleva (devops.pink) — Mon, 14 Jul 2025 00:00:00 GMT

Hey queens! ✨

Okay, picture it. You've been grinding for days on a sick new feature, tucked away in your own cozy little branch. The code is flawless. Everything works. And you're finally ready to share your masterpiece with the world (or, you know, the main branch). So you proudly type out that magic git merge command and… oops! 😬

Git literally screams at you: "CONFLICT! I have no idea what to keep!" Sound familiar? Your first instinct is full panic mode. You want to slam the laptop shut and pretend none of it ever happened. But hold on. Don't freak out. We're gonna walk through this together, and I'll spill all the tea.

Wait, What Even Is `git merge`?

Here's the deal. When you work on a project, you create branches, which are basically parallel universes for your code. Whatever you want to try, you try it in your own branch, no harm to the main project. It's your personal creative space.

And git merge is the command that drags your little universe back into the main timeline.

For example:

git checkout main
git merge feature/new-login

That's literally you telling Git, "Hey, take all the awesome stuff I built in feature/new-login and add it to the main branch, please!"

When It's a Buttery-Smooth Ride

(The Fast-Forward Merge)

Say you and your teammates were touching totally different files. Git is a genius about it. It just combines everything on its own and you barely notice. Pure magic! ✨

The technical name for this is a Fast-Forward Merge. It kicks in when the main branch hasn't picked up any new commits since you branched off. Git simply "fast-forwards" the main pointer so it includes all your shiny new commits. Easy.

Now, sometimes a dev wants a cleaner history, so they force Git to tie a little merge "knot" even when a fast-forward was totally possible. You do that like this:

git merge --no-ff feature/new-login

…and it leaves a cute little note in the project history that says, "This feature was merged right here."

When Git Has a Meltdown (aka a Conflict)

So here's where the drama starts. A conflict pops up when you and someone else (or, honestly, past-you on a different branch) edited the exact same line of code in two different ways. Git gets overwhelmed. It stares at both versions and just cannot pick a winner. It's basically looking at you like, "OMG, girl, I can't decide. You have to choose!"

What This Hot Mess Looks Like in Your Code

You open the file, and boom — Git greets you with something like this:

<<<<<<< HEAD
The version of the code from the main branch
=======
The version of the code from your new feature/new-login branch
>>>>>>> feature/new-login

Don't panic!

This isn't an error. It's Git's way of saying:

"Hey, I found two different versions of this code and I don't know which one to keep. Can you help me out?"

Those weird lines actually mean something. Here's the breakdown:

<<<<<<< HEAD - This is what's currently in your main branch.
======= - This line separates the two versions.
>>>>>>> feature/new-login - And this is the version coming from your branch.

Okay, So How Do I Fix This? A Step-by-Step Guide!

Breathe! You've got this.
Analyze the code. Take a look at both versions. Which one do you need? Maybe you need a little bit of both? The final decision is all yours.
Edit the file. Just delete the code you don't want and leave only the code that should be there.
Delete the markers. You have to get rid of the <<<<<<<, =======, and >>>>>>> lines. They've served their purpose.
Save the file.

And that's it! The conflict in the code is officially resolved.

The Final Steps: Letting Git Know You're a Genius

Now you just have to tell Git you've handled it and everything is okay:

Tell Git you've resolved the conflict in this file

git add <filename>

Finalize the merge with a commit

git commit

Git usually pops up a pre-written commit message for you. Honestly? Just use that one. No notes.

And you're done! The merge is complete, and your amazing new feature is safe and sound in the main branch! 🎉

SOS! What If I Messed Everything Up?

Maybe you started fixing a conflict and suddenly realized you're in way over your head. Don't worry, sis. There's an escape button:

git merge --abort

This one cancels the merge completely, like it never even happened. Your project snaps right back to how it was before you started. Take a breath. Try again when you're ready.

How to Vibe with merge and Avoid Conflicts

Always stay updated! Before you start a new feature, update your main branch first. The safest move is a little two-step: run git fetch (this just downloads the latest changes without touching your code) and then git merge origin/main (this applies those changes). It seriously lowers your odds of a conflict.
Stay in your own lane. When you can, try to work on different files than your teammates.
Communicate! This is the big one, queen. Actually talk to your team about who's working on what. A good convo is the secret to a conflict-free life.

The Takeaway

Git conflicts are not the end of the world. They're normal. Super normal. They don't mean you're a bad developer, not even a little. It's literally just Git going, "Hey! I've got two different things here—can you help me choose?"

And now? You know exactly how to help. You're already one step closer to feeling like a total pro in Git.

Keep coding, girl! You're killing it! 💖

Git Branches - How to Not Break Prod and Stay Alive

Tatiana Mikhaleva (devops.pink) — Mon, 16 Jun 2025 00:00:00 GMT

Hey queens. You're building stuff. Pushing code. Shipping features.

And then someone says:

“Just create a branch for that.”

Wait — a what?

Real talk: Git can feel like sorcery at first. Branches? Rebases? Merge commits? Upstream what?

But here's the truth:

Branches are not scary. They're your safety net. Your creative zone. Your undo button.

They let you try bold things without risking production.

They help teams build fast — and stay sane.

This guide breaks it down, step by step.

No buzzwords. No hand-waving. Just real Git, the way developers actually use it in 2025.

Let's start from the core idea — what even is a branch?

What's a Branch, Really?

A branch is a pointer (a variable) that references a commit.

In practice, it's a parallel version of your codebase where you can work safely — nothing affects main until you decide it's ready.

Branches give you:

freedom to experiment,
a clean commit history,
protection from disaster,
and a solid setup for teamwork.

How to Work with Branches - Step by Step

1. Create a New Branch and Switch to It

Modern way (Git ≥ 2.23):

git switch -c feature/signup

switch is a modern, more readable alternative to checkout.
-c means “create a new branch.”

Classic way (still valid):

git checkout -b feature/signup

🧭 Tip: Use meaningful, kebab-case names with prefixes like: feature/signup, bugfix/fix-login, hotfix/crash-on-submit, release/v1.3.0

2. Do Some Work: Commit & Push

Example:

echo "Sign-up logic" > signup.js
git add signup.js
git commit -m "Add sign-up logic"
git push -u origin feature/signup

-u sets the upstream branch so future git push and git pull work without arguments.

📌 After this, you can simply use git push and git pull without specifying branch names.

3. See What Branch You're In

git branch

The current branch is marked with a *.

To create a branch without switching:

git branch feature/experiment

📌 Quick jump back to the previous branch:

git switch -

Super handy when jumping between main and a feature branch.

4. Switch Back to main and Update It

git switch main
git pull --ff-only origin main

🧭 Important:

Run this from the main branch.
If you have local commits, Git will stop politely — preventing accidental overwrites.

5. Merge Your Branch into main

Standard merge:

git merge feature/signup

If main hasn't changed since you branched off, Git performs a fast-forward — just moves the pointer.

Want to preserve a visible merge commit?

git merge --no-ff feature/signup

🧭 Great for tracking feature branches in project history or pull requests.

6. Handling Merge Conflicts

If Git reports a conflict:

Open the file and look for:

<<<<<<< HEAD
code from main
=======
code from your branch
>>>>>>> feature/signup

Manually fix the file.
Stage the resolved file:
```
git add filename
```
If a real merge happened (not fast-forward), finish with:
```
git commit
```

💡 If it was fast-forward, Git already did everything — no commit needed.

7. Delete the Branch

Locally:

git branch -d feature/signup

If the branch hasn't been merged yet, use:

git branch -D feature/signup

Remotely:

git push origin --delete feature/signup

📌 An alternative is:

git push origin :feature/signup

—but it's less readable.

8. View Branch History Visually

git log --oneline --graph --decorate --all

This shows your full commit tree, across all branches — clean and visual.

Merge vs Rebase: When and Why

merge preserves full history and creates a merge commit.
rebase rewrites your branch history to make it look like you started from the latest main.

To rebase:

git fetch origin
git rebase origin/main

🧭 Only rebase private branches.

If someone else has pulled your branch — do not rebase unless the team agrees.

If you must force-push after a rebase, never use --force directly. Use:

git push --force-with-lease

✅ This makes Git check that nobody has pushed since your last pull — safer for teams.

Suggested Team Workflow

Start a feature branch from main:
```
git switch -c feature/add-login
```
Work, commit, push:
```
git push -u origin feature/add-login
```
Open a pull request on GitHub/GitLab for review and CI checks.
Once approved, merge it — ideally with --no-ff.
Delete the branch locally and on the remote.
Keep main clean and always production-ready.

Working with Remotes

Task	Command
Push and set upstream	`git push -u origin feature/branch`
Pull updates with rebase	`git pull --rebase origin main`
Delete branch on remote	`git push origin --delete feature/branch`
Clean up remote branch refs	`git fetch --prune` or `git remote prune origin`
Safe force-push after rebase	`git push --force-with-lease`

📌 Make pruning automatic:

git config --global fetch.prune true

📌 Make rebase your default pull strategy:

git config --global pull.rebase true

Or do it manually per pull:

git pull --rebase

Keeps your history linear and avoids noisy merge commits.

Command Cheat Sheet

Action	Command
Create + switch to new branch	`git switch -c feature/branch`
Switch branches	`git switch branch-name`
Create branch without switching	`git branch branch-name`
See all branches	`git branch`
Jump to previous branch	`git switch -`
Update main before merge	`git switch main && git pull --ff-only origin main`
Merge branch	`git merge feature/branch`
Merge with visible history	`git merge --no-ff feature/branch`
Rebase feature onto latest main	`git rebase origin/main`
Delete local branch	`git branch -d branch-name` or `-D`
Delete remote branch	`git push origin --delete branch-name`
Visualize all history	`git log --oneline --graph --decorate --all`
Safe force-push after rebase	`git push --force-with-lease`
Clean deleted remotes automatically	`git config --global fetch.prune true`
Use rebase by default on pull	`git config --global pull.rebase true`

Best Practices (And Why They Matter)

One branch per task
Keeps changes isolated, focused, and easy to review.
Use clear, consistent naming
Prefixes like feature/, fix/, release/ help.
Use lowercase + hyphens: feature/add-login.
Use pull requests
Code reviews, CI checks, and visibility improve code quality.
Avoid --force — use --force-with-lease
Don't overwrite others' work by mistake.
Clean up your branches
Remove them when they're done — both locally and on remote.
Only rebase private branches
Never rewrite history others rely on.

Final Thoughts

Git branches aren't just a tool — they're a mindset.

They give you a safe space to build, break, and experiment — without breaking production.

With branches, you can:

isolate ideas,
collaborate without chaos,
and build with confidence.

Branch = creativity
Main = stability
You = the developer who keeps both in harmony.

Docker MCP - How GPT Agents Now Use Slack, GitHub, Stripe & More

Tatiana Mikhaleva (devops.pink) — Mon, 09 Jun 2025 00:00:00 GMT

So here's the story I want to tell you, darling. It's about how models like GPT and Claude stopped just talking, and started actually doing things.

Think of it as them getting hands. By “hands,” I mean agents: little helper programs that let the model reach out and trigger real-world tools.

For example:

send a message in Slack,
check a payment in Stripe,
or open a pull request on GitHub.

No magic involved. Just MCP, an open standard called the Model Context Protocol.

It hands language models one consistent, secure way to talk to outside tools. APIs, databases, cloud services, all of it.

import VideoPlayer from "@components/VideoPlayer.astro";

The Challenge: Why This Was Hard

Getting here wasn't easy, though.

So let me walk you through what made it such a pain originally, how the whole thing works now, and where Docker comes in to keep everything tidy, isolated, and easy to ship.

Here's the thing. AI has always been a brilliant advisor. It writes code. It hunts down bugs. It'll even whip up a poem when you're having a rough day, queen.

But the second you asked it something basic, like:

“Hey, can you post in Slack that the task is done?”

It would just blink at you and go:

“Uh… I'd love to, but I'm just a language model. I can talk — but I can't do.”

And honestly? Fair. It's smart. It just couldn't act on its own.

The brain was all there. Logic, knowledge, reasoning that actually made sense.

Actually taking action, though? Never made it into the job description.

Enter Agents (a.k.a. Hands for Models)

To close that gap, developers started handing models a way to act. They wired them up to small helper services called agents.

In MCP, we call these MCP servers. And the app that connects the model to those servers? That's the host.

How It Works, Step by Step

The model says what it wants to do, like “Send this message to Slack.”
The host takes that request and passes it to the right MCP server.
The MCP server performs the action. Sends the message, makes the API call, whatever.
The host takes the result and gives it back to the model, so it can finish its reply.

Simple: the brain thinks, the hands act, and MCP is the cable running between them.

The Catch: Why It Was a Headache

For the longest time, setting all this up was… painful.

On paper, gorgeous. In real life? A full hacker quest, sis.

You had to spin up MCP servers manually.
Each agent dragged in its own messy stack. Python, Node, Chromium. Conflict city.
API keys? Sitting there in raw JSON. Easy to use, terrifying to babysit.
And running two or three agents at once? Oh, brace yourself.

All you wanted was to check a Stripe payment. Suddenly you're knee-deep in DIY DevOps.

And That's Where Docker Comes In

It made launching MCP agents simple, consistent, and actually reliable.

Picture it. Your AI finally gets hands, but you really don't want those hands rummaging around your system.

Docker hands them gloves. Clean, contained, safe.

The model still gets to act freely. The boundaries just don't move.

Each agent runs in its own container
It only sees what you allow
No mess in your system
No library conflicts
And no “whoops, I just deleted my desktop”

So What's Changed?

Docker now ships with the MCP Toolkit. And with it comes an official catalog of over 100 ready-to-go agents.

Open Docker Desktop, click into the MCP Toolkit tab, and there they are. Ready to go.

Go browse the full Docker MCP Toolkit and poke around the MCP Servers on Docker Hub. That's over 100 officially supported tools you can launch in seconds.

What Happens When You Use an Agent?

You pick an agent image, let's say GitHub
Docker spins up a container
The agent starts listening for commands from the model

That's the whole thing. No console gymnastics, code cuties.

Solving the Duplicated Agent Problem

Back in the day, running multiple apps was rough. Claude, VS Code, whatever you had open, none of them knew the agent was already running. So each one fired up its own copy.

Which got... messy:

Two containers doing the same job
Two access tokens
Two network connections
And a whole pile of wasted resources

Clunky. Risky. Pointless, really.

Now? One agent. One container.

Tons of clients can connect to that single one. No duplication, no conflicts, nothing extra dragging along.

But Is It Safe?

Yes. Here's why.

Agents live inside isolated Docker containers. Every container gives you a clean, controlled little environment.

The agent only sees what you choose to share with it: folders, environment variables, network access. Isolation is the default, not something you opt into. Docker draws a hard boundary around your agent, so a mistake or a bug or even a compromised tool can't wander into your system.

That said, like with any software, it pays to peek under the hood and see what it's actually doing.

Stick with well-maintained agents, follow the usual best practices, and you'll be just fine.

And yes, like any powerful tool, you can switch the safety off if you really want to.

Add --privileged, or mount the Docker socket, and that boundary is gone. But leave the defaults alone, and Docker handles the hard parts for you.

Who Is This For?

You're already on GPT, Claude, or Copilot, and you want them to actually do stuff, not just write about it
You're in DevOps, and you're sick of scripting the same tools again and again
You're a product person, and you want AI wired into Jira, GitHub, Stripe, or whatever, in 10 minutes flat

What You Actually Get

An agent up and running in a couple of minutes
Isolation and safety baked right in
And when you want to scale up? Just add more agents.

That's it. That's the whole trick.

Thanks for reading! Be sure to watch the video version for extra insights and helpful visuals.

Kubernetes on Your Laptop — No Cloud, No Boring Docs, Just Magic

Tatiana Mikhaleva (devops.pink) — Thu, 29 May 2025 00:00:00 GMT

Hey there, tech goddess (or just someone who's allergic to boring docs 👀)

You've probably heard of Kubernetes, but every tutorial starts with “cluster,” “orchestration,” and “in the cloud”?

😩 No thanks.

But what if I told you that you could launch your own website in Kubernetes, right on your laptop, set up environment variables, pass in secrets — step by step, no AWS, no tears, no PhD required?

Docker, Minikube, kubectl, Pod, Deployment, ConfigMap, Secret — all of it. I'll walk you through everything.

You just open VS Code, copy a few commands — and boom: a real cluster,spinning, working, and doing your bidding like a true DevOps enchantress. Enough theory — let's do some hands-on magic.

No AWS, no signups, no credit cards — just you, your laptop, and your curiosity. 🚀

Step 1 — Installing Docker (and figuring out why you even need it)

Scene 1: "What even is Docker?"

Imagine you're trying to run an app. It works perfectly for your friend on Windows, but not for you on a Mac. She's on Windows, you're on a Mac. It needs a bunch of libraries you don't have.

🎯 The fix? A container — a self-contained package that already includes everything the app needs.

🧳 A container = a suitcase with code, tools, and everything else bundled in.

Docker is the program that runs those suitcases — right on your machine.

Scene 2: "Download and install Docker"

📝 Do this:

Go to 👉 https://www.docker.com/products/docker-desktop
Choose Docker Desktop for macOS (or your OS).
Download the installer.
Install like any other app: drag the Docker icon into your Applications folder.

📌 Once it's installed — launch Docker Desktop (via Spotlight or Launchpad).

Quick check: is Docker working?

🔧 Open Terminal (Cmd + Space, type “Terminal”).

Run this command:

bash docker --version

You should see something like:

Docker version 24.0.2, build abc123

That means Docker is installed!

Next, run:

docker ps

If Docker is running, you'll see an empty table, like:

CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES

That's totally fine — it just means no containers are running yet.

😱 If Docker doesn't start or docker ps throws an error:

🧨 What's happening	💡 Try this
`docker ps` doesn't work	Make sure Docker Desktop is running — look for the 🐳 icon in your top menu bar
Command not found	Restart your Terminal or reboot your machine
Docker launched, but nothing's happening	The first launch can take a couple of minutes — be patient
It's asking for permissions	Check if macOS is waiting for you to approve something — a pop-up might be hiding behind other windows

Why does this matter?

We'll be launching our Kubernetes cluster using Minikube, and Minikube runs containers under the hood.

No Docker = no cluster = no “Hello, Pod.” 😬

✅ TL;DR — You're ready to move on if:

You installed Docker Desktop
docker --version works
docker ps shows an empty table (and no errors)

If all that's good — let's install Kubernetes (via Minikube)!

Step 2 — Installing Minikube & kubectl (and launching your first cluster!)

Scene 1: “What are Minikube and kubectl?”

🛠 Minikube is like a mini version of Kubernetes you can run right on your laptop.

That means: no server, no cloud, no AWS, no mystical cluster setup — Minikube spins it all up locally.

🎮 kubectl (say “cube control” or “kube cuddle”) is your remote control for that cluster.

You'll use kubectl to create pods, check logs, update apps — basically, run the show.

Scene 2: Install kubectl and Minikube

📝 If you're on a Mac:

Open Terminal and run these one by one:

brew install kubectl

Then:

brew install minikube

🧘‍♀️ Take a moment, let Homebrew do its magic.

Scene 3: Start the cluster

Once it's installed, fire up your mini-cluster:

minikube start --driver=docker

💡 What's happening here:

Kubernetes is starting inside Docker (which you set up in Step 1).
Minikube creates a “virtual machine” running your cluster.

⏱ This may take 1-2 minutes, so... deep breath.

Check if everything's working

Run this command:

kubectl get nodes

📋 You should see something like:

NAME STATUS ROLES AGE VERSION
minikube Ready control-plane 1m v1.29.0

If you see STATUS: Ready - congrats! 🎉

Your first cluster is up. You literally just spun up your own infrastructure.

:::note Minikube runs a single-node cluster - perfect for learning and testing, but not meant for production. And that's totally fine — we're here to get hands-on, not deploy Netflix. :::

If something goes wrong - don't panic!

🔥 Problem	💡 What to check	🛠 Example
`kubectl` not recognized	Did the install finish cleanly? Try restarting your terminal.	—
`minikube` won't start	Is Docker Desktop running? Look for the 🐳 icon.	—
`minikube start` just hangs	Try restarting Docker, rebooting, and make sure you've got at least 4 GB of free RAM	—
`kubectl get nodes` shows nothing	Check if the cluster is running	`minikube status`
Cluster not started	Just run it again	`minikube start`

Why did we do this?

Kubernetes is how you run and manage container-based apps.
Minikube lets you explore it without needing cloud servers.
kubectl is your command center.

Now you're ready to create pods, deployments, services - everything a true DevOps witch needs.

Step 3 — My First Pod: Running an App in Kubernetes

Scene 1: “What even is a Pod?”

📦 In Kubernetes, everything revolves around Pods.

Think of a Pod as a little room with one (or more) containers inside that:

share network and storage
start together
live and die together

A Pod usually runs just one container (like our nginx example) - but it can have multiple, like sidecars.

Scene 2: Create a YAML file for your Pod

📁 Open VS Code or your favorite code editor. Create a new file and name it:

pod.yaml

✍️ Paste this inside:

apiVersion: v1
kind: Pod
metadata:
  name: my-first-pod
spec:
  containers:
    - name: nginx
      image: nginx:alpine
      ports:
        - containerPort: 80

✨ What's going on here:

apiVersion, kind, metadata — just Kubernetes boilerplate: "this is a Pod, name it like this".
Inside containers: you're saying: “Run a container using nginx:alpine and open port 80.”

Scene 3: Apply the file and launch the Pod

In your terminal, while inside the folder with the file:

kubectl apply -f pod.yaml

👉 This tells Kubernetes: "Here's the definition — go make it real!"

Then check:

kubectl get pods

You should see something like:

NAME READY STATUS RESTARTS AGE
my-first-pod 1/1 Running 0 10s

✅ STATUS: Running means your Pod is alive and well! 🎉

Scene 4: Open your app in the browser

Now let's actually see nginx in action. Time to forward that port:

kubectl port-forward pod/my-first-pod 8080:80

💡 What's this doing?

It tunnels port 80 from inside the container to your localhost:8080.
Meaning: whatever nginx serves, you can see in your browser.

Scene 5: Check if it's working

Pop open your browser and go to:

http://localhost:8080

If you see the default nginx page — boom, success!

If it didn't work — deep breath, let's fix it

🔥 Problem	💡 What to try	🛠 Command
Browser says “site can't be reached”	Make sure the terminal with `port-forward` is still open	—
`kubectl port-forward` hangs or fails	Cancel it (`Ctrl + C`) and try again	`kubectl port-forward pod/my-first-pod 8080:80`
Port 8080 is already in use	Try a different port	`kubectl port-forward pod/my-first-pod 8081:80` and go to `localhost:8081`
nginx didn't start in the Pod	Check the logs	`kubectl logs my-first-pod`

So far, you've:

✅ Started your cluster
✅ Created your very first Pod
✅ Launched nginx
✅ Accessed it through the browser

This was your first real app running in Kubernetes — and that's a huge milestone 👏👏👏

Step 4 — Deployment: So Your Pods Don't Break (And If They Do — They Auto-Heal)

Scene 1: “What is a Deployment, anyway?”

In the last step, you manually created a Pod. But here's the problem:

If it crashes — nobody restarts it
You want two Pods for reliability
You want Kubernetes to watch over them automatically

🎯 Enter the Deployment. It:

✅ creates Pods
✅ scales them (1, 2, 10, 100 — whatever)
✅ restarts them if they crash
✅ makes it easy to update images

Basically — a Pod manager that keeps your app alive and thriving.

Scene 2: Create the Deployment YAML

📁 Create a new file called:

deployment.yaml

✍️ Paste this in:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx:alpine
          ports:
            - containerPort: 80

💡 What's happening here:

replicas: 2 — we're saying “Give me 2 identical Pods”
selector.matchLabels + template.metadata.labels — this connects the Deployment to the Pods via app: nginx
containers — same as before: launch nginx

Scene 3: Apply the Deployment

Open your terminal and run this:

kubectl apply -f deployment.yaml

🔍 You're telling Kubernetes: "Here's the blueprint — build it."

Now check that it worked:

kubectl get deployments

You should see something like:

NAME READY UP-TO-DATE AVAILABLE AGE
nginx-deployment 2/2 2 2 10s

✅ Which means: 2 Pods are up and running.

Now check the actual Pods:

kubectl get pods

You should see two Pods with similar names, like:

nginx-deployment-xxx-yyy 1/1 Running
nginx-deployment-aaa-bbb 1/1 Running

Scene 4: Let's test the auto-recovery

🧪 Tiny experiment: delete one of the Pods

kubectl delete pod <one-of-the-pod-names>

A few seconds later:

kubectl get pods

You'll see 2 Pods again.

🤯 Because the Deployment noticed one was gone — and created a new one automatically!

If the Deployment doesn't launch or Pods don't appear

🔥 Problem	💡 What to check	🛠 Example Command
`kubectl apply -f deployment.yaml` does nothing	Make sure the file is named correctly and you're in the right folder	`ls`
`kubectl get deployments` shows nothing	Could be a YAML error (indentation, missing keys)	Run `kubectl apply -f deployment.yaml` again to see the error
Pods crash (`STATUS: CrashLoopBackOff`)	Something is breaking inside the container — check the logs	`kubectl logs <pod-name>`
Don't know the Pod name	Just list all Pods	`kubectl get pods`
`error: unable to recognize`	Your YAML might be broken — check the format	Use YAML Linter

📌 Pro tip: You can always list Pods with:

kubectl get pods

Why this matters

Now you've got:

Two Pods = more reliability
Self-healing containers
Easy updates in the future

You just leveled up from “one test container” to a real Kubernetes-managed application.

Step 5 — Service: How to Open a Pod in the Browser (Without Magic)

Scene 1: “What is a Service?”

You already launched 2 nginx Pods — but right now, they're hiding behind a wall.

🙅‍♀️ Without a Service, you can't just open them in the browser. Because:

Pods have internal IPs
They're not accessible from “outside”
If a Pod restarts, its IP might change

🎯 A Service is like a stable front door to your app.

It knows where your Pods are and routes traffic to them.

Even if a Pod dies, restarts, or moves — the Service still leads to the right place.

Scene 2: Create `service.yaml`

📁 Create a new file and name it:

service.yaml

✍️ Paste this in:

apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  type: NodePort
  selector:
    app: nginx
  ports:
    - port: 80
      targetPort: 80
      nodePort: 30080

💡 What this does:

type: NodePort — tells Kubernetes: “Expose this to the outside world via a port”
selector: app: nginx — the Service will forward traffic to Pods with that label
port — the port the Service listens on (inside the cluster)
targetPort — where to send traffic inside the Pod (nginx listens on port 80)
nodePort — the external port you'll use in your browser

Scene 3: Apply the Service

In your terminal:

kubectl apply -f service.yaml

🎉 Boom — your Service is live!

Now run this:

minikube service nginx-service

🪄 That command will automatically open your site in the browser — no need to worry about ports, IPs, or voodoo.

Didn't open? You can do it manually:

minikube ip

👉 You'll get an IP, like 192.168.49.2

Now go to:

http://192.168.49.2:30080

✅ You should see the nginx welcome page!

What did we just do?

You created a Service to route traffic to your Pods
Used NodePort to make it accessible from outside
Opened a real website running inside Kubernetes — without port-forward

You're now officially at the “my app runs in K8s and opens in a browser” level —

aka your very first Kubernetes web app prototype!

Step 6 — ConfigMap: Passing Variables Into a Container (No Rebuilding Needed)

Scene 1: “Why do we even need ConfigMap?”

Let's say you've got a website. And now you want to:

show a different welcome message
tweak the behavior without rebuilding the image
keep settings separate from your code

📦 ConfigMap is how you pass variables into your Pods.

Think of it like: “Here's a YAML with your config — grab it when you start up.”

Scene 2: Create the ConfigMap

📁 Create a file called:

configmap.yaml

✍️ Paste this:

apiVersion: v1
kind: ConfigMap
metadata:
  name: nginx-config
data:
  WELCOME_MSG: "Hello from ConfigMap!"

✨ What's going on here:

data: is just a key-value map
WELCOME_MSG is an example string (but it could be a URL, a mode, a path — anything)

Scene 3: Update your deployment.yaml

Open your deployment.yaml and inside the container block, add this under spec.containers[0]:

env:
  - name: WELCOME_MSG
    valueFrom:
      configMapKeyRef:
        name: nginx-config
        key: WELCOME_MSG

📌 This tells Kubernetes: “When launching the container, pass it this environment variable from the ConfigMap.”

Scene 4: Apply it all

In your terminal, run:

kubectl apply -f configmap.yaml
kubectl apply -f deployment.yaml

🔄 This updates both the ConfigMap and the Deployment so everything is hooked up.

Scene 5: Check if the variable is inside the container

First, get the name of one of the Pods:

kubectl get pods

Copy a name (like nginx-deployment-xxx-yyy) and jump inside:

kubectl exec -it nginx-deployment-xxx-yyy -- /bin/sh

Now run:

echo $WELCOME_MSG

✅ You should see:

Hello from ConfigMap!

🎉 It worked! The variable made it all the way into your container from Kubernetes.

If the variable didn't show up

🔥 Problem	💡 Check this	🛠 Example command
`echo $WELCOME_MSG` shows nothing	Make sure you saved changes and re-applied `deployment.yaml`	`kubectl apply -f deployment.yaml`
It looks right but still no variable	The Pod may not have restarted — delete it manually and let Deployment recreate it	`kubectl delete pod <pod_name>`
Can't get into the Pod	Double-check the Pod name	`kubectl get pods`
`kubectl exec` doesn't work	Pod may have crashed — check status or logs	`kubectl get pods`, `kubectl logs <pod_name>`

📌 Pro tip: For the new config to appear, the Pod usually has to be recreated.

kubectl apply updates the Deployment, but won't restart running Pods.

What did you just do?

Created a config variable in Kubernetes
Passed it into a Pod via Deployment
Saw the variable live inside your container

This is key when your app needs to be flexible — change config without rebuilding the Docker image.

Step 7 — Secret: Safely Passing Passwords and Tokens into a Pod

Scene 1: “ConfigMap vs Secret — what's the difference?”

💡 ConfigMap — for regular settings: modes, messages, URLs.

🔐 Secret — for anything you don't want exposed to the world:

passwords
access tokens
API keys

❗ Heads up: Secret values are automatically base64-encoded.

That's not encryption — just a way to hide them from curious eyes.

Scene 2: Create a secret file

📁 Create a new file:

secret.yaml

✍️ Paste this:

apiVersion: v1
kind: Secret
metadata:
  name: nginx-secret
type: Opaque
data:
  SECRET_MSG: SGVsbG8sIGZyb20gU2VjcmV0IQ==

✨ What's going on:

type: Opaque — standard type of Secret
data: — key-value pairs (in base64)

📌 Example:

echo -n "Hello, from Secret!" | base64

Which gives you: SGVsbG8sIGZyb20gU2VjcmV0IQ==

Scene 3: Link the Secret to your container

Open your deployment.yaml.

Inside containers > env, add:

- name: SECRET_MSG
  valueFrom:
    secretKeyRef:
      name: nginx-secret
      key: SECRET_MSG

📌 Works exactly like ConfigMap — just a different data source: a Secret.

Scene 4: Apply the changes

In your terminal:

kubectl apply -f secret.yaml
kubectl apply -f deployment.yaml

📦 Kubernetes will update the Secret and roll out the changes.

Scene 5: Check the container

First, get your Pod's name:

kubectl get pods

Then hop inside one:

kubectl exec -it <pod_name> -- /bin/sh

Now check the variable:

echo $SECRET_MSG

✅ You should see:

Hello, from Secret!

🎉 That means your Secret was passed into the container successfully!

If the Secret variable didn't show up

🔥 Problem	💡 Check this	🛠 Example command
`echo $SECRET_MSG` shows nothing	Make sure you saved and re-applied `deployment.yaml`	`kubectl apply -f deployment.yaml`
Secret wasn't created	Verify it's actually there	`kubectl get secrets`
Pod didn't restart	Delete it manually — Deployment will recreate it	`kubectl delete pod <pod_name>`
base64 was wrong	Make sure you encoded without newline	`echo -n "Hello"
Can't enter the Pod	Double-check the Pod name	`kubectl get pods`

📌 Pro tip: If the variable doesn't show up after apply, manually deleting the Pod usually helps.

Why does this matter?

🔐 Secret is the standard way to safely pass sensitive data into your app — no hardcoding, no YAML leaks.

You just:

created a Kubernetes Secret
passed it into a container
verified it from the inside

Magic. Secure magic. 💫

⏸️ Now pause for a second.

Do you realize what you've just done?

You installed a cluster. Deployed an app. Passed it configs and secrets — the full DevOps starter pack.

🤯 No clouds. No five tabs of Stack Overflow. No fear of hitting Enter.

Let's wrap it all up in a beautiful summary:

Final Recap — What You Did and Why It Matters

Step	What You Did	Why It Matters
1	Installed Docker	Runs containers — the foundation for Kubernetes
2	Installed Minikube and kubectl	Local cluster and control tool
3	Created a Pod	Ran your first app in Kubernetes
4	Set up a Deployment	Manages and scales Pods automatically
5	Added a Service	Made your app accessible from the browser
6	Connected a ConfigMap	Passed env vars without rebuilding the image
7	Connected a Secret	Securely passed passwords and sensitive data

✨ You just built a mini-infrastructure on your own laptop.

This isn't just “hello world” — it's hello Kubernetes.

So, what's next? Two paths:

Want to take a break and return later?

Stop the cluster:

minikube stop

Optionally quit Docker Desktop:

Click the 🐳 icon in the top bar → Quit Docker Desktop

🛑 That's like hitting "pause."

Nothing will be deleted — everything stays just as it is.

👉 When you want to come back:

Start Docker Desktop
Then run:

minikube start

💡 And boom — your Pods, Services, Configs, Secrets... all back in action.

Not planning to return?

If you want to fully clean up everything we built:

minikube delete

This removes the cluster, all Pods, configs, and secrets — clean slate.

You can leave Docker installed — you'll probably use it again (a lot).

Even if you never touch Kubernetes again — know this:

You started it. You understood it. You owned it. That's already a huge step into the DevOps world.

10 Docker Interview Questions & Answers for DevOps & Cloud Engineers

Tatiana Mikhaleva (devops.pink) — Mon, 26 May 2025 00:00:00 GMT

Prepping for a Cloud or DevOps Engineer interview in 2025? Then you already know Docker is going to show up. It always does. Every single time.

So here are 10 questions you'll probably get asked, plus how to answer each one without sweating through your shirt. Let's get you ready, queen. 💪

import VideoPlayer from "@components/VideoPlayer.astro";

First, A Quick Refresher: What Is Docker?

Docker is a platform that runs your apps inside isolated little boxes called containers.

The magic part? A container behaves the same no matter where it runs. Your laptop, a test server, production, doesn't matter. None of that "but it worked on my machine" drama. 😅

And in actual DevOps work, you'll find it pretty much everywhere: app development, testing, CI/CD pipelines, cloud deployments. The whole pipeline, really.

Question 1: What's the difference between an image and a container? And what happens if you delete the image?

Okay so think of a Docker image as a frozen recipe for your app. It packs everything the app needs to run, code, libraries, environment settings, all of it.

A container is what shows up when Docker actually cooks that recipe. The recipe becomes a real dish, sizzling on the stove. 🍳

The image stays read-only and you can reuse it as many times as you want. The container, on the other hand, gets its own writable layer and runs as an isolated process. Here's the fun bit interviewers love: delete the image while the container is already running, and the container just... keeps going. It doesn't care, because the image already lives in memory.

But stop that container and try to start it back up? Now Docker goes looking for the image, can't find it, and the restart fails. Womp.

🚀 Pro Tip:

Tag your images properly (my-app:latest, my-app:v1.2) and regularly prune unused ones — but avoid deleting images used by running containers.

Question 2: What actually happens when you run docker run?

When I run docker run, the first thing Docker does is check whether the image is sitting on my machine already.

Nope? Then it pulls the image down from a registry like Docker Hub. After that it spins up a container, which is basically an isolated process with its very own filesystem, networking, and slice of resources.

The isolation itself comes from Linux namespaces and cgroups. That's the secret sauce.

Then, last step, it fires off whatever default command the image was built to run.

📌 Example:

Running docker run nginx pulls the nginx image (if it's not local), creates a container, and starts the Nginx server inside that isolated environment.

🚀 Pro Tip:

Use --rm with docker run to automatically clean up the container after it exits — so your system doesn't get cluttered with stopped containers.

Question 3: COPY vs ADD — what's the difference, and when would you use each?

Both COPY and ADD move files into your image. So far, twins.

COPY simply copies files and folders — no surprises.
ADD does more: it can unpack compressed files like .tar.gz and download files from URLs.

That "extra" behavior from ADD is exactly why I keep my distance. It does things you didn't always ask for, which makes Dockerfiles harder to read. I reach for COPY by default, and only bring in ADD when I genuinely need one of those tricks.

📌 Example:

# Preferred
COPY ./app /app

# Only if needed (auto-extracts)
ADD archive.tar.gz /app/

🚀 Pro Tip:

Simplicity is security — prefer COPY unless you have a very good reason.

Question 4: What's a multi-stage build, and when would you use it?

A multi-stage build just means you've got more than one FROM in your Dockerfile. Sounds fancy. It's not, I promise.

The first stage does heavy work — installing dependencies, building code.
The final stage copies only the necessary artifacts into a clean, minimal base image.

The payoff is a lean image. All those build tools and temp files that production never needed? Gone. Left behind in the first stage where they belong.

📌 Example:

# Stage 1 — build
FROM node:20 AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

# Stage 2 — production
FROM node:20-slim
WORKDIR /app
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/node_modules ./node_modules
COPY --from=builder /app/package.json ./
CMD ["node", "dist/index.js"]

🚀 Pro Tip:

Smaller images = faster deployments + fewer vulnerabilities.

Question 5: CMD vs ENTRYPOINT — how do they work together?

ENTRYPOINT is the thing that runs. Your main executable. The star of the show.

CMD hands it the default arguments.

Now the part people trip on. When you call docker run and pass your own arguments, those override CMD. ENTRYPOINT stays put.

Put them together and you've got a sensible default that you can still bend at runtime. Best of both, honestly.

📌 Example:

FROM nginx:1.28.0-alpine-slim

ENTRYPOINT ["nginx"]
CMD ["-g", "daemon off;"]

🚀 Pro Tip:

Want full control at runtime? Use only CMD — and leave out ENTRYPOINT.

Question 6: Volumes vs Bind Mounts — which would you use in production, and why?

For production, I go with Docker-managed volumes every time. They stay tucked away from the host OS, they're easy to back up, and they hold up nicely over the long haul.

Bind mounts lean on specific host paths. That makes them brittle, and very tied to one machine's setup. They shine for local dev, though. Just keep them out of production, sis.

📌 Example:

services:
  db:
    image: postgres
    volumes:
      - pg-data:/var/lib/postgresql/data

volumes:
  pg-data:

🚀 Pro Tip:

Volumes are portable, reliable, and more future-proof across hosts and clusters.

Question 7: How does networking between containers work?

Out of the box, Docker drops your containers onto a bridge network and hands each one a private IP.

Catch is, on that default network they can only find each other by IP. Not great. The fix is a user-defined bridge network.

On a user-defined bridge, containers can talk to each other by name. Suddenly service discovery just works, and your life gets so much easier. 💕

📌 Example:

services:
  app:
    image: my-app
    environment:
      DB_HOST: db
      DB_USER: appuser
      DB_PASSWORD: secret
    networks:
      - app-net

  db:
    image: postgres
    environment:
      POSTGRES_DB: mydb
      POSTGRES_USER: appuser
      POSTGRES_PASSWORD: secret
    networks:
      - app-net

networks:
  app-net:

🚀 Pro Tip:

Always use user-defined networks — the default bridge network doesn't support automatic name-based discovery and can lead to frustrating connection issues.

Question 8: How do you reduce Docker image size, and why should you care?

Smaller images build faster, deploy faster, and give attackers way less to chew on. Win, win, win.

I start with a minimal base image — like alpine:3.21.3, python:3.12-slim-bookworm, or node:20.13.1-alpine.
I combine RUN instructions to reduce layers, and clean up any temp files or caches.
I always use a .dockerignore file to exclude things like .git, node_modules, and test data.

And when a build gets gnarly, multi-stage is my go-to. It keeps the build tools out of the final runtime, which is exactly where the bloat usually hides.

📌 Example:

A Node.js app image can shrink from 1.2 GB to under 200 MB by switching to node:20.13.1-alpine and cleaning up properly.

🚀 Pro Tip:

Smaller images = faster pipelines, quicker deploys, and fewer security issues.

Question 9: What is BuildKit, and why use it?

BuildKit is Docker's modern build engine, and it's a serious step up for performance, security, and flexibility.

It runs independent build steps in parallel, caches way more cleverly, and handles secrets safely while building. It'll also do multi-platform builds and manage storage efficiently. Lots packed in there.

Good news for most of us: on recent Docker versions BuildKit is already on by default, so there's nothing to set up. Stuck on something older? You can still switch it on with DOCKER_BUILDKIT=1, or by tweaking the Docker daemon config.

📌 Example:

With BuildKit, multi-stage builds can run steps in parallel, reducing build times significantly.

🚀 Pro Tip:

Lean on BuildKit for builds that are faster, safer, and a whole lot more efficient.

Question 10: How do you handle sensitive data (like secrets) in Docker?

Hardcoding secrets into Dockerfiles or images? Never. Not once. Don't do it, darling.

For local runs I pass secrets in as environment variables, either inline or through a .env file. And if I use a .env file, it goes straight into .dockerignore so it never sneaks into the image by accident.

In production it's a different game. I lean on proper secret managers, HashiCorp Vault, AWS Secrets Manager, or Kubernetes Secrets, and let them inject the secrets at runtime.

The rule is simple. Secrets live outside the image, never baked inside it.

📌 Example:

Pass database passwords using environment variables in staging, and HashiCorp Vault in production.

🚀 Pro Tip:

Good secret management = safer deployments and easier key rotations.

Thanks for reading! Be sure to watch the video version for extra insights and helpful visuals.

Helm in Kubernetes - What It Is and Why You Need It

Tatiana Mikhaleva (devops.pink) — Tue, 20 May 2025 00:00:00 GMT

Hey, tech queens!

Let's talk Helm — my go-to tool for working with Kubernetes. If you've ever suffered through manually crafting YAML files for every single service, you're about to breathe a huge sigh of relief.

I used to drown in those manifests and think, “Is it always going to be this painful?” Nope. Because Helm exists.

Helm in Plain English

Imagine you buy a dresser from IKEA. Instead of guessing where each screw goes, you grab the instructions and have it assembled in 20 minutes - latte in hand.

Helm is that same kind of instruction manual - for Kubernetes.

Normally, deploying an app means creating a bunch of objects: Pods, Services, Ingresses, ConfigMaps — each with its own YAML file. It's tedious.

Helm saves you:

Bundles everything into one structure: a chart
Spins up apps with a single command
Simplifies upgrades, customization, and rollbacks
Makes deployments predictable and repeatable

What's a Helm Chart (and Why It's Not Scary)

The word “chart” might sound intimidating, but it's really just a folder with organized files. No magic, just structure.

Think of it as your deployment organizer:

Chart.yaml — the chart's business card: name, version, description
values.yaml — default settings (ports, replicas, DB names, etc.)
templates/ — YAML blueprints Helm renders into actual Kubernetes objects
_helpers.tpl — reusable functions to keep templates DRY
charts/ — dependencies like databases or message queues

Why It's Handy

A chart is like a capsule — it holds everything: instructions, configs, and dependencies.

Same chart, different environments:

Dev: myblog-dev, 1 replica, test DB
Prod: myblog, 3 replicas, production DB

Just tweak values.yaml — no need to touch anything else.

It's like one dress styled with different accessories.

Why Helm Is My Must-Have

Reasons I love Helm:

Scalability: no more 30+ YAML files
Flexibility: same chart, different setups
Transparency: preview what's actually going to be installed (helm template)
Security: Helm 3 removed Tiller (and that's a good thing)
Control: rollbacks are built-in (helm rollback is magic)

Helm 2 vs Helm 3 — Short & Sweet

Helm 2 relied on a separate component called Tiller, which had elevated cluster privileges — a big security headache.

Helm 3 fixed it:

No Tiller
Uses your existing kubectl credentials
Easier to install and great for CI/CD

What's Next? Helm v4 Is in the Works

Helm v4 is currently in planning (see HIP-0012) — with focus on a new API and architectural improvements.

No official release date yet — the devs meet weekly and are actively shaping the roadmap.

Installing Helm — Fast & Painless

You'll Need:

A Kubernetes cluster (Minikube, GKE, etc.)
kubectl installed

Most Universal Way

curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3
chmod 700 get_helm.sh
./get_helm.sh

Always use the official script from GitHub. Trust but verify.

Alternatives

macOS:

brew install helm

Homebrew now provides the latest release — v3.18.0

Linux (Snap):

sudo snap install helm --classic

Snap can sometimes lag behind — prefer the install script for CI.

Debian / Ubuntu (APT):

curl https://baltocdn.com/helm/signing.asc | gpg --dearmor | \
sudo tee /usr/share/keyrings/helm.gpg > /dev/null

echo "deb [signed-by=/usr/share/keyrings/helm.gpg] https://baltocdn.com/helm/stable/debian/ all main" | \
sudo tee /etc/apt/sources.list.d/helm-stable-debian.list

sudo apt-get update
sudo apt-get install helm

Verify the Install

helm version

Sample output:

version.BuildInfo{Version:"v3.18.0", GitCommit:"...", GoVersion:"go1.22.2", ...}

As of May 20, 2025, this is the latest stable release.

v3.18.1 is expected on June 11, and v3.19.0 is coming in September.

First Helm Run — Let's Go!

Install something fun — like Nginx:

helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo update
helm install nginx bitnami/nginx

Customize settings:

helm install my-app ./my-chart \
 --set image.tag=2.0.1 --set replicaCount=3

Or use a YAML config:

helm install my-app ./my-chart -f values-prod.yaml

Something went wrong?

helm rollback my-app 1

Uninstall it:

helm uninstall my-app

Security & Best Practices

Always Inspect a Chart Before Installing

Think of it like trying on a dress before the party - just because it looks cute doesn't mean it fits.

helm lint — checks the structure and versioning of the chart
helm template — renders the final YAML (preview before install)
helm test — runs built-in tests (if defined)
helm diff — compares installed vs new version

Install the diff plugin:

helm plugin install https://github.com/databus23/helm-diff

Sign and Verify Your Charts

Use helm package --sign to digitally sign your charts
Run helm verify to confirm integrity
For advanced signing, try Cosign + the helm-sigstore plugin

Store Charts Like Images (OCI FTW)

Helm now supports pushing/pulling from OCI registries:

helm push mychart.tgz oci://registry.example.com/charts
helm pull oci://registry.example.com/charts/mychart --version 1.2.3

If you're using older tools like ChartMuseum, clarify that separately.

Mind Your Versions

Watch for version skew between Helm and Kubernetes
Don't upgrade Helm right before a production deploy — stability first!

Takeaway

Helm is my DevOps bestie. It brings:

Organization
Repeatable configuration
And a lot less Kubernetes chaos

If you're working with Kubernetes, get familiar with Helm.

It 100% deserves a spot in your toolkit.

Your First Git Commit - A Beginner-Friendly Guide to Version Control

Tatiana Mikhaleva (devops.pink) — Mon, 12 May 2025 00:00:00 GMT

Hey, tech queens! 👩‍💻✨

If you've ever seen the word Git and thought:

“Okay, this sounds important… but also kind of intimidating?”

You're not alone.

But here's the good news: Git isn't scary — it's an essential tool that'll make your coding life much easier.

Let's walk through your first Git setup and commit, step by step — no jargon, no stress.

What Is Git, Really?

Think of your code like a project notebook. You want to:

save versions as you go,
undo mistakes,
and maybe work on it with other people — without chaos.

Git is the version control system that makes all of that possible.

It helps you:

snapshot your work at any time,
roll back if something breaks,
and collaborate smoothly with others.

Installing Git (No Stress, Just Steps)

On macOS

Open Terminal and run:

brew install git

:::note Homebrew must be installed beforehand. :::

If your Mac prompts you to install Xcode Command Line Tools, accept it — that's normal.

On Windows

Simplest method: download Git from git-scm.com. It includes Git Bash, which gives you a helpful command-line interface.

Prefer using the terminal?

winget install --id Git.Git

(Works on Windows 10 1809+ and Windows 11.)

On Linux

For Debian/Ubuntu:

sudo apt-get install git

For Fedora:

sudo dnf install git

For Arch-based systems:

sudo pacman -S git

Check the Installation

Make sure Git is installed with:

git --version

If you see a version number, you're all set.

Configure Git (Just Once)

Git tags your work with your name and email so you can track who made which changes — even if it's just you.

git config --global user.name "Your Name"
git config --global user.email "you@example.com"

Set main as the default branch name (instead of the older master):

git config --global init.defaultBranch main

Optional: avoid using Vim by default (it can be confusing for beginners). Use something simpler like nano:

git config --global core.editor "nano"

Prefer VS Code? Use:

git config --global core.editor "code --wait"

Creating Your First Repository

Create a new folder for your project and initialize Git inside it:

mkdir my-first-repo && cd my-first-repo
git init

You now have a Git repository — a versioned folder ready to track changes.

Add a File and Make Your First Commit

Let's create a basic file:

echo "Hello, Git!" > README.md

:::note File names like README.md and readme.md are treated the same on macOS and Windows, but they're different on Linux — case matters. :::

Check Git's status:

git status

It will show the new file but mark it as untracked.

Tell Git to track it:

git add README.md

Now make your first commit:

git commit -m "Add README"

Done — your first snapshot is saved in Git history!

Bonus: Use `.gitignore` to Keep Things Clean

You might have folders or files you don't want to track — like node_modules, log files, or build output.

Create a .gitignore file:

echo "node_modules/" > .gitignore

Want help generating one for your tech stack? Check out gitignore.io.

Optional (But Handy) - Windows Line Ending Fix

If you're on Windows and see warnings like “LF will be replaced by CRLF,” run:

git config --global core.autocrlf true

This helps avoid annoying line ending issues between systems.

Make Things Faster with Aliases

Tired of typing full commands? Set up aliases:

git config --global alias.st status
git config --global alias.co checkout
git config --global alias.br branch

Now you can use git st instead of git status. Shortcuts = efficiency.

Prefer GUIs Over Command Line?

If the terminal isn't your thing (yet), try a visual interface:

GitHub Desktop — beginner-friendly and intuitive
Sourcetree — more advanced but still beginner-usable

You can always switch to the terminal when you feel ready.

Quick Cheat Sheet

Command	Description
`git init`	Creates a Git repo
`git status`	Shows changes and file states
`git add`	Stages files for commit
`git commit -m ""`	Saves a snapshot with a message
`git config`	Sets global Git settings (name, editor, etc.)

You Did It

You installed Git, configured it, created a repo, and made your first commit.

That's a big step in your dev journey — version control is a core skill for any developer.

Now you've got the tools and confidence to take control of your projects.

Best CI/CD Tool in 2025? GitHub Actions vs GitLab CI vs Argo Workflows

Tatiana Mikhaleva (devops.pink) — Sun, 11 May 2025 00:00:00 GMT

So you're knee-deep in CI/CD, wrangling cloud platforms, or just praying your pipelines stop being a hot mess. Welcome, darling, you found the right corner of the internet. There's one question that trips up basically everyone:

Which CI/CD tool actually makes sense in 2025?

Not in theory — in real life.

All three are genuinely good tools. The real question is which one fits your team, your chaos, your Tuesdays.

So here's how they stack up. 💅

import VideoPlayer from "@components/VideoPlayer.astro";

First, let's set the stage

CI/CD stopped being “run tests and deploy” a long time ago, sis.

These days the job covers way more:

security,
rollbacks,
environments,
infrastructure as code,
and observability.

Pipelines aren't throwaway scripts anymore. They've crept into the core of how your whole system runs, and honestly that shift snuck up on a lot of teams.

And the tool you land on? It quietly shapes how your people build, ship, and patch things up every single day. No pressure, queen.

GitHub Actions

It lives right inside GitHub.

Drop in a .yml file, pull a couple of Marketplace actions, and boom, you've got a pipeline running before your coffee's cold.

Small projects love it. Truly:

frontend apps
Docker builds
deployments to S3, ECS, or Lambda

It's quick. It's friendly. You can get something working in an afternoon, which feels amazing when you're just starting out.

It's lovely until your project gets big and a little complicated

Then the project grows, as projects always do. And things shift:

you pile on more steps
jobs start triggering other jobs
secrets multiply like rabbits
and debugging becomes pure trial and error

Suddenly the whole thing feels brittle, like one tiny tweak could bring the house down. We've all felt that knot in the stomach.

That's the moment teams usually go hunting for something sturdier. Something like GitLab CI.

GitLab CI

GitLab CI won't dazzle you. But it's rock-solid, and that counts for a lot.

Everything lives in one file, .gitlab-ci.yml. Jobs, stages, environments, approvals: all of it sits in one tidy spot, which your future self will thank you for.

What you get out of it:

consistency
built-in security checks
preview environments
full visibility from commit to production

Once you've wired it up, it fades into the background and just does its job. No drama. No 2 AM surprises.

It's a dream for teams that ship constantly and care more about predictability than about flashy little features.

Argo Workflows

But what if predictability isn't enough for you, code cuties?

What if your pipeline isn't just shipping deployments, but is actually a piece of the product itself?

Enter Argo Workflows.

Argo isn't really a CI/CD tool in the usual sense. Think of it as a full-blown pipeline engine that lives on Kubernetes.

You describe your workflows as DAGs, short for Directed Acyclic Graphs. Every step gets its own pod. Dependencies are crystal clear. And the whole thing is observable, top to bottom.

Where it absolutely shines:

ML training
ETL pipelines
staged microservice deploys
or anything that reacts to events

Argo hands you serious control and visibility, all of it right inside the cluster. It's a power move.

But let's be honest, it is not beginner-friendly

You're going to need a few things first:

Helm
RBAC
persistent storage
ingress setup
and a team that can actually babysit all of the above

This is not a tool you “just try” on a lazy Sunday, darling.

Argo is for teams that treat their pipelines as genuine infrastructure. Because, well, that's exactly what they've become.

They All Have Their Place

Every one of them earns its spot. GitHub Actions, GitLab CI, Argo. Each one has its place.

So how do these tools actually behave when the stakes are real? Not a tidy side project. Actual production, with actual humans depending on it.

Let's get into the lived-in version, the good parts and the genuinely painful ones.

GitHub Actions:

Perfect for small, fast-moving projects
Under 10 jobs? Buttery smooth
Push past that and it can spiral fast
Debugging slides into guesswork

GitLab CI:

Thrives with teams that have structure
Handles approvals, environments, and clean release flows
Quiet, dependable, stays out of your way
Which is precisely what you crave at scale

Argo Workflows:

Built for when delivery is the product
For pipelines that aren't support tools but load-bearing pieces of your platform
Complex, yes. But if your team is ready for it, the power is wild.

The Real Test: When Something Breaks

Not in a polished demo. Not on some sunny-day deploy where everything behaves.

It's Friday, 4 PM, and someone just merged to main.

You've already shut the laptop and slung your bag over your shoulder. Then Slack buzzes: “deployment failed.”

And that, my friend, is the exact moment your CI/CD setup shows you who it really is. 😅

Choose What Fits Your Team

So yeah. The tools you pick really, truly do matter.

We've poked at the trade-offs, the patterns, the little pain points that show up at the worst times.

Now the call is yours. Pick what actually suits your team and your day-to-day reality, not some imaginary perfect setup.

What's going to keep your pipelines healthy and your Fridays gloriously peaceful?

Thanks for reading! Be sure to watch the video version for extra insights and helpful visuals.

What Actually Runs the Internet? A No-Stress Guide to Containers & Kubernetes

Tatiana Mikhaleva (devops.pink) — Mon, 05 May 2025 00:00:00 GMT

Hey, brilliant tech minds (and future ones too)! 👩‍💻✨

So you've heard the words. Docker. Kubernetes. ContainerD. They float around in tech convos, and honestly in half the LinkedIn posts you scroll right past 😅. But what actually are they? And do you really need to know?

Short answer: YES. Especially if you want to sound like that girl in tech and truly get what makes apps like Netflix, Zoom, and Spotify tick. No jargon here, darling. Just good vibes and examples you'll actually remember. 💁‍♀️✨

Imagine You're Baking Cookies

Stay with me. This one clicks, I promise.

You've got the perfect cookie recipe. So good that you want people all over the world to bake the exact same batch. But what if someone forgets the sugar? Or cranks the oven to the wrong temp?

So genius you packs everything into a cute little cookie kit. Ingredients, step-by-step instructions, even the timer. Now anyone, anywhere, can pull off the same perfect batch. 💅

That's basically what containers are in tech. Little kits that wrap up everything an app needs to run, from the code to the tools to the settings, so it behaves exactly the same no matter where it lives. Your laptop. The cloud. Wherever.

Meet Docker — the Container Queen

Docker is the tool that builds those little cookie kits (a.k.a. containers). It lets devs bundle up an app so it can run anywhere, no fuss.

Think of Docker as your fave meal-prep delivery service. Packing and shipping your app, fast and smooth. One command and boom, it's wrapped up and ready to go. 💨

But what happens when you've got a lot of containers? Like, dozens of them, all at once? Yeah. That's where it gets spicy.

Kubernetes: Your App's Event Planner

Kubernetes is the logistics queen. She makes sure the whole show runs: containers launching on time, bouncing back when they crash, multiplying when demand spikes.

Here's what Kubernetes does:

Keeps your app running if something breaks
Spins up more containers when things get busy
Updates stuff behind the scenes without breaking the app
Basically? It's the ultimate control freak — in a good way

Picture a wildly organized girlboss project manager who never misses a beat. 👩‍💼💅

And Then There's ContainerD — the Quiet One

ContainerD sounds like the awkward cousin at the tech party. Don't underestimate it.

Back in the day, Docker did everything. Packaging. Running. Managing all of it. And that got messy fast, so the smart folks decided to split the jobs up.

These days ContainerD is the lightweight tool with one job: running containers. No drama, no distractions.

And here's the tea: Kubernetes now uses ContainerD directly instead of Docker.
(Because Docker isn't just a runtime — it's a full suite of tools. Kubernetes only needs the “engine” part to do its job.)

Psst. If you ever hear the word CRI floating around, here's the scoop:
CRI (Container Runtime Interface) is just how Kubernetes talks to runtimes like ContainerD. That's it. Nothing scary, sis.

TL;DR? Docker's still fab for development. But in the big leagues, like real production apps, Kubernetes + ContainerD = power duo. 💪

So Why Should You Even Care?

You don't have to write a single line of code. Knowing how modern apps actually run is like knowing how your iPhone or your Wi-Fi works. It's just part of being tech-savvy in 2025.

Let's recap:

Containers = app-in-a-box
Docker = the packer/delivery girl
Kubernetes = the event planner/project manager
ContainerD = the lowkey engine that runs the whole show

This is the invisible magic humming behind every platform you love. And now? You're officially smarter than 90% of the internet. ✨📲

How Generative AI Actually Understands You

Tatiana Mikhaleva (devops.pink) — Mon, 28 Apr 2025 00:00:00 GMT

Hey, lovely tech queens! 👩‍💻✨

By now you've watched AI write blog posts, paint epic art, narrate stories, and even stitch together short films. Honestly, it's everywhere.

But how does it actually know what you're asking for?

Spoiler: it's not magic. Just smart logic, sliced into pieces. Like digital LEGO bricks.

Here's the whole thing, simple and fun and drama-free.

1. What Are Tokens?

Words, but chopped into snackable bites

AI doesn't “read” the way you and I do. Whatever you type, it shatters into tiny pieces called tokens. A token could be:

a full word (“coffee”)
part of a word (“pro” + “duct”)
or even a symbol (“!”)

Example:

You type: “Make me a text about cats”

The AI sees: [“Make”, “me”, “a”, “text”, “about”, “cat”, “s”]

Why bother? Because tokens are easy to turn into numbers. And numbers are AI's love language, sis.

2. What's Chunking?

Think: "Don't overwhelm the poor bot"

Even the biggest models have a token limit. There's only so much they can hold at once.

So when your input runs long, AI splits it into chunks.

Like slicing a pizza. Same flavor, way easier to handle.

3. What Are Embeddings?

Turning words into vibes (aka numbers)

Here's the wild part. AI doesn't “know” that pizza is tasty. What it does instead is convert every token into a set of numbers, called an embedding, that captures what the word means and how it relates to everything around it.

Example:

“pizza”, “cheese” and “pepperoni” end up with embeddings that sit close together.
“pizza” and “printer”? Worlds apart.

Picture every word having an address on a map. Similar vibes move into the same neighborhood.

But wait. What about images and videos?!

Oh girl. This is where it gets spicy. Watch this:

4. How AI Creates Images

Tools like DALL·E, Midjourney and Stable Diffusion turn plain words into gorgeous visuals.

You type:

“A cat wearing a hoodie drinking latte on a Tokyo rooftop”

Here's what happens:

The prompt turns into tokens
Tokens → embeddings
AI pulls what it knows about cats, hoodies, lattes & Tokyo
Then it generates a whole new image — pixel by pixel

It's not copying anything. It's imagining.

Think of a creative bestie who happens to have studied billions of Pinterest boards.

5. How AI Makes Videos

Now it gets cinematic, darling.

Models like Runway Gen-2 and Pika Labs are building entire videos out of nothing but text prompts.

You type:

“A goldfish flying through space”

Boom. Short movie.

So how? Like this:

It creates the first frame like a still image
Then builds more, one by one
Adds smooth transitions, motion, and vibe
Glues it all together as a video

Basically, AI is your personal animation studio. No render farm required.

6. How AI Understands Sound

With tools like ElevenLabs, Suno, or MusicLM, AI can:

Read your text out loud (like, perfectly)
Create music from a vibe
Analyze your voice for emotion or tone

Example:

You write: “Say it like you're a TED speaker hyping the crowd”

And it delivers, with energy and sparkle to spare.

Why Should You Even Care?

Because the moment you get how AI thinks, everything shifts. You:

Write 10x better prompts
Stop being scared of words like “token” and “embedding”
Use AI like a pro, not a guessing game
Can explain it to your boss, your bestie, or your future investor

So Here's the Takeaway

AI doesn't read minds. Sorry, queen.

But it does:

Break your words into tokens
Turn them into numbers (embeddings)
Use patterns it learned to predict what you want

And then? Boom.

Text, image, video, sound. Whatever your imagination ordered, it serves.

So no, AI isn't magic. It's just freakishly good at spotting patterns.

And now that you speak its language, well. You're basically unstoppable.

How AI Models Are Really Trained - From Idea to Reality

Tatiana Mikhaleva (devops.pink) — Sun, 20 Apr 2025 00:00:00 GMT

Hey girls! And you, smart tech kings, too!

AI is everywhere. Your phone, your feed, that suspiciously perfect shopping cart. But what's actually happening back there, behind the curtain?

That's the question I want to answer today.

How does an AI model get built, trained, and shipped out into the real world? Spoiler: it's not magic, and it's definitely not sci-fi. It's a process. A real, step-by-step one. And I'm walking you through every part of it, beginner-style, queen.

1. Start With a Real Problem, Not “Let's Just Do AI”

Before anyone writes a line of code or builds a single fancy model, there has to be a reason. An actual one.

Companies don't build AI “just because.” That's an expensive hobby. They start by asking real questions:

Can we reduce product returns?
Spot fake reviews faster?
Recommend better stuff to users?
Predict when a machine will break?

First step: know exactly what you're solving.

Skip this part and you might end up with a model that's genuinely impressive and completely useless. Cute, sure. But pointless.

2. Collect and Clean the Data (aka Your Model's Food)

Say you want to predict which customers might leave your app.

You'll need data. Stuff like:

When they joined
How often they log in
What they clicked
If they stayed or left

Here's the thing nobody warns you about, though: data never shows up cute and clean. Never. It arrives a hot mess.

So you clean it first:

Remove typos, duplicates, and empty cells
Format everything consistently
Spot the weirdness (someone logging in 300 times a day, hello, are you a bot?)

Think of this as skincare for your model:

Skip the cleansing step and nothing downstream is going to work right. Trust me on that one.

3. Split the Data: Train, Validate, Test

Okay, your data's clean. Don't just dump all of it into the model at once, please.

Split it three ways:

Training set: where your model learns
Validation set: to check progress while it learns
Test set: to see if it actually works in real life

Imagine baking cookies:

Training = practicing the recipe
Validation = taste-testing as you go
Testing = sharing with friends to see if they love them (or not)

A common split is 80/10/10. But honestly? It depends on your project.

4. Train the Model (Finally!)

Now the fun starts. Your model begins to “learn.”

But how does that even work?

Let's say you hand it a pile of emails, each one labeled “spam” or “not spam.” Here's what the model does with them:

Makes a guess
Checks the answer
Adjusts if it's wrong
Tries again

Over and over. Thousands of times, until it gets sharper at spotting the patterns.

It's not memorizing. It's learning how to generalize.

Like, “If the subject line screams FREE MONEY!!!... hmm, sis, that might be spam.”

5. Tune the Model, Like Tweaking a Recipe

Even after all that training, your model might still need some fine-tuning.

This is called hyperparameter tuning. Sounds scary. It's really not, I promise.

Picture adjusting a cookie recipe:

Add more vanilla?
Bake longer?
Lower the oven temp?

In model terms, that's stuff like:

Learning rate
Number of layers
Batch size

And guess what, darling? Tools like Amazon SageMaker can tune all of this for you, automatically. Less manual fiddling. More coffee breaks.

6. Evaluate the Model — Is It Actually Good?

Before launch, you test the model on data it has never seen. Brand new stuff.

A few metrics help us here:

Accuracy: How often is it right?
Precision: When it says “yes,” is it correct?
Recall: Did it find all the real “yeses”?
F1 Score: A balance of precision and recall

Example:

If your model says “this customer will leave” —
Precision = how often it's right.
Recall = how many of the leaving customers it actually found.

7. Deploy the Model — Send It Into the World

Trained? Tested? Beautiful. Time to let your model out into the wild and actually do its job.

Two common ways to put it to work:

Real-time — for instant decisions (like chatbots or spam filters)
Batch — for scheduled jobs (like weekly reports or daily analysis)

Cloud tools usually make this happen, and yes, you'll likely reach for something from Amazon here (SageMaker, for example).

Don't panic if these names sound unfamiliar. You really don't need to be an engineer to follow the process. Picture them as the behind-the-scenes crew, the ones quietly helping your model go live.

8. Monitor and Update — Your Model Still Needs You

Deployed does not mean done. Far from it.

The world shifts. People change their habits. So the model has to keep up, or it goes stale.

Here's what you (or your tools) keep an eye on:

Track weird predictions
Notice when performance drops
Retrain the model with new data if needed

Think of it like skincare touch-ups. Even the most flawless routine needs a tweak now and then.

Quick Recap — 8 Steps to Train a Model:

Step	What's Happening
1	Define a real business problem
2	Collect and clean the data
3	Split data into train / val / test
4	Train the model
5	Tune it (aka adjust the settings)
6	Test it with unseen data
7	Deploy it to do real work
8	Monitor and retrain when needed

Final Thoughts (From a Girl Who Gets It)

If you walked in thinking training a model meant pressing one shiny button... well, now you know better.

But here's the good news. It's totally doable.

Break it into small steps and the whole thing just starts to click. One piece at a time.

Maybe you want to build models someday. Maybe you want to manage AI teams, or maybe you just want to sound confident the next time someone drops the word “pipeline” in a meeting. Either way, code cuties: you've got this.

Stay curious. Keep learning.

And remember: great models run on clean data and smart decisions. Just like you.

Is Kubernetes Overkill? Why You Probably Don't Need It

Tatiana Mikhaleva (devops.pink) — Sat, 19 Apr 2025 00:00:00 GMT

More and more teams keep circling back to the same question, darling.

Is Kubernetes overkill? And honestly, the bigger one: why do we keep spinning up clusters for things that never needed them?

Here's where I stand.

Kubernetes is powerful. A lot of us live in it daily, and it solves very real problems. But let's not pretend it's always the answer.

Because sometimes it adds way more complexity than it takes away.

So let's be honest with each other about when Kubernetes fits, and when it really, truly doesn't. 💅

import VideoPlayer from "@components/VideoPlayer.astro";

When Kubernetes Is the Wrong Tool

You've seen it. We all have.

Teams reaching for Kubernetes when it's absolutely the wrong tool for the job. It's like lighting a birthday candle with a flamethrower, queen.

Let me show you a few that I've actually run into.

Example One: The Static Site

A little marketing page. No backend. No database. Just HTML and maybe a sprinkle of JavaScript. And somehow it's living in Kubernetes, with Ingress, autoscaling, Prometheus, the whole circus. That's renting a crane to hang a poster, sis.

You don't need a cluster for that. Toss it on Netlify or S3 and you're done. No cluster. No crying. They're fast, they're cheap, they're reliable, and they ask you for exactly zero YAML therapy.

Example Two: The Monthly Monolith

One app. Updated once a month. Nothing to scale, no rollout drama. It just sits there and runs. But somehow there's a Helm chart, a cluster, and half a dozen manifests babysitting it.

Why though?

A basic VPC and a docker run would have handled it. (docker run, if you want the receipts.) Fewer moving parts. Nothing to babysit at 2am.

Example Three: The Small Team with a Big Cluster

Two devs. Maybe three. No platform engineer. Nobody actually watching the metrics. But the cluster? Oh, the cluster is there.

So pods crash. Argo drifts out of sync. PVCs break quietly in a corner. And nobody notices, because nobody's looking. Is this platform engineering, or just chaos with cuter branding? Genuine question.

When Kubernetes Does Make Sense

Okay, fair is fair. Kubernetes has its place, and I'm not here to drag it.

When it fits, it's gorgeous. Here are the moments where reaching for it is the right call.

1. Complex Service Architectures

You're running a bunch of services, each one carrying its own configs, secrets, health checks, and deploy flows.
You need real orchestration, service discovery, and scheduling.

This is literally what Kubernetes was born to do.

2. Dynamic Scaling and Resilience

Traffic spikes are part of your life.
You want self-healing.
You want the system to patch itself up before you've even noticed something broke.

That's Kubernetes showing off, and it earns it.

3. Platform Engineering

You're past "just deploying apps." You're building an internal platform for other people to build on.

GitOps, Argo, Helm, policy-as-code, and a team that genuinely gets all of it. That's the dream setup.

Here, Kubernetes hands you standardization, control, governance, and scale. Worth it.

The Real Catch: Kubernetes Doesn't Fix Your Problems

It spreads them around. Sorry.

No observability before? Cute. Now your blind spots are smeared across every node.
Fragile CI/CD pipeline before? Now it's fragile and containerized. Lucky you.
Nobody could debug a crash before? Now that crash is buried under five layers of abstraction.

Kubernetes is powerful, code cuties. But power cuts both ways. It amplifies whatever's already in your system, the good stuff and the messy stuff alike.

Ask Yourself, and Be Honest:

Do you have a DevOps or platform team to actually keep this cluster alive?
Are you running 5+ services that genuinely need orchestration?
Do you really require auto-scaling, self-healing, and the fancy rollout strategies?
Are you using tools like Helm, Argo CD, and Prometheus with confidence, and using them well?
Can your team debug pod crashes, PVC issues, and those cursed little networking glitches?

If most of those land on "not really," then maybe a cluster isn't your next move.

And that is completely fine. Truly.

There's No Shame in Choosing Simpler Tools

Especially when the simpler thing just works better.

There are some lovely options waiting for you:

Docker Compose + systemd
ECS Fargate
Cloud Run
Render
Heroku
A good old VPC instance with some solid CI/CD

The best tool isn't always the fanciest one. Most of the time it's the one your team actually understands and can keep alive for the long haul.

Let Me Be Real With You

Kubernetes is not a badge of honor. It's not a maturity checklist you tick off to prove you've made it. It's a complex, powerful tool, and it only earns its keep when the problem genuinely asks for it.

If it helps you, amazing. If it doesn't? Skip the cluster. Skip the chaos. Go with whatever actually fits. Don't build a space shuttle when, sweetie, all you needed was a bicycle. 🚲

Thanks for reading! Be sure to watch the video version for extra insights and helpful visuals.

What Kind of Data Does AI Use

Tatiana Mikhaleva (devops.pink) — Mon, 14 Apr 2025 00:00:00 GMT

Hey, you brilliant tech babes (and kings — I see you too 👀)!

You already know how AI learns. You know where it shows up in your day. There's one last piece, though, and honestly it's the big one:

It's all about the data, darling.
Like, literally. No data = no AI.

So here's the plan. We'll walk through the types of data, why each one matters, and the kind of mess that happens when your data is a disaster (spoiler: everything goes sideways).

Grab your iced latte. Let's talk dirty. Data dirty.

Structured vs. Unstructured — What's the Tea?

Structured Data = Neat girl energy

Think spreadsheets, columns, drop-down menus. Basically, info that fits in tidy rows and is super easy to organize.

Real-life example:
Your online store tracks shoppers by name, age, and how much they spent last month.

Name: Emma
Age: 28
Purchase: $89.99
VIP status: Yes

AI eats this right up. Easy to analyze, easy to love. This is the go-to for supervised learning, because it's simple, it's predictable, and models just get it.

Unstructured Data = Total chaos... but gold

Now the messy stuff. The pile AI has to decode:

Tweets
DMs
Selfies
Voice notes
TikToks
Review texts
Screenshots of what your friend sent you at 2am

Way harder to process. But this is where the juicy, human stuff lives.
Give AI the right tools (NLP, computer vision) and suddenly it can feel what people are saying, seeing, and reacting to. Wild, right?

The Data Types AI Actually Works With

Here's what shows up in real-world projects, laid out like a cute cheat sheet:

Data Type	Looks Like…	Example	What AI Does With It
Numerical	Numbers, prices, scores	5, 29.99, 90%	Normalize, scale, compare
Categorical	Labels, options, categories	"Beginner", "NY", "Tote bag"	Convert to machine-friendly codes
Text	Reviews, messages, bios	“Ugh, I loved it so much!”	Understand mood, topic, emotion
Image	Selfies, product pics, screenshots	Photo of a red dress	Detect shapes, colors, objects
Audio	Voice memos, customer calls	Voice note: “Sooo... mad or just tired?”	Turn into text or audio features
Video	Insta Reels, tutorials, dashcams	Makeup GRWM TikTok	Analyze image + sound together

⚙️ What Makes Data “Model-Ready”?

You can't just toss raw data into a model and pray. That's like showing up to a glam shoot with bed hair and mismatched socks, sis.

Your data needs a serious prep routine first:

Cleaning — remove duplicates, typos, missing stuff
Formatting — make sure prices are numbers, dates are dates, and text is readable
Labeling — if your model needs answers, you have to tell it what's what (e.g. “This is a cat. That's a croissant.”)
Balancing — avoid over-representing one side (like 90% apples and 10% oranges — we're not doing fruit bias today)

Why Bad Data = Bad AI

Real talk. The smartest AI on earth won't save your butt if the data is a mess.
Skip the prep and here's your reward:

Your model makes wrong predictions
It becomes biased (like recommending only men's products if it's seen mostly male data)
It just... breaks. And blames you silently.

Example:

Say you want your AI to clock whether a voice note sounds angry or chill. But almost all your training data is people being excited. So someone calmly says “I'm fine,” and the model decides they're thrilled. Or worse, lying.

Not AI's fault, queen. That's ✨data drama✨.

So... What Should You Know as a Beginner?

You might not be building models yet. Doesn't matter. Just knowing this puts you ahead:

Data is the fuel AI runs on
Clean, balanced data = accurate, smart AI
Unstructured data is harder, but so much more real and emotional
You can totally start working with it — one TikTok caption or product review at a time

Final Thoughts from a Data-Loving IT Girl

People think AI is all about code and algorithms. But girl, no.
AI is 80% data, 20% logic — and 100% what you feed it.

Learning AI? Working in tech? Just curious how Netflix knows you want K-dramas at 2am? It always traces back to the data.

Clean it. Understand it. Respect it.

Because even your future AI model needs a solid skincare routine before it glows.

DevSecOps Explained - Security for DevOps in 2025

Tatiana Mikhaleva (devops.pink) — Fri, 11 Apr 2025 00:00:00 GMT

Okay so this one sounds kind of technical at first. It really isn't. DevSecOps is one of the most practical things you'll pick up this year.

Here's the deal. If you're in DevOps already, or you're trying to break into it, you can't shrug security off anymore. Those days are gone. And relax, code cuties, there's barely any code in here and zero scary theory.

It's just a plain-English walkthrough so you can start thinking like a secure DevOps engineer in 2025. Let's get into it.

import VideoPlayer from "@components/VideoPlayer.astro";

What exactly is DevSecOps?

Short version? Security isn't a thing you bolt on at the very end. It's baked into the process from day one.

Rewind a few years. Developers wrote the code. DevOps shipped it. And then, only then, the security team wandered in and went, “Hold up — is any of this actually safe?”

DevSecOps flips that around. We're thinking about security from the very start. Picture buckling your seatbelt before the car even moves instead of reaching for it mid-crash.

Now, this does not mean you have to morph into some cybersecurity wizard overnight. But are you touching infrastructure, automation, or CI/CD? Then yeah, sis. Security is part of your job.

Why does this matter so much right now?

Because everything moves fast. It's all automated. You're shipping through pipelines, conjuring cloud infrastructure in seconds, juggling services across a dozen environments.

And attackers? They've kept up.

Websites aren't the only prize anymore. They're coming for your pipelines, your cloud configs, your secrets, your state files.

One exposed API key. One public S3 bucket. One sloppy permission. That's genuinely all it takes to put your whole system on the line.

Layer on the compliance demands, the customer expectations, and that constant pressure to ship yesterday, and treating security as an afterthought just stops being an option.

So how do you actually start thinking like a DevSecOps engineer?

Let me show you a handful of small moves. They're simple. They also punch way above their weight, and you can start today.

You don't have to fix everything at once. Just start here:

1. Don't hardcode secrets.

I get it, it's so tempting. But passwords, tokens, keys? They do not belong in your code. Not ever.

Tuck them away somewhere safe. Reach for Vault, AWS Secrets Manager, or even your CI/CD platform's built-in secrets.

Quick gut check, darling: would you tape your house key to your front door? Didn't think so. So leave the credentials out of your Git repo.

2. Treat your infrastructure as code like real code, because it is.

Terraform files, Kubernetes configs, Ansible playbooks. Every one of them can sneak in a risk.

Point tools like tfsec, Checkov, or Snyk at them to sniff out misconfigurations. They catch the stuff your tired eyes glide right over.

3. Lock down your pipelines.

Your CI/CD holds serious power. It deploys apps. It spins up servers. It can rewrite production on a whim.

Not exactly something you hand to just anybody.

Keep it controlled.
Use approvals.
Don't give out admin access freely.

4. Be intentional with permissions.

Live by the principle of least privilege.

People and systems get exactly the access they need to do the job. Nothing extra. Full stop.

5. Don't forget observability.

Turn on logging.
Monitor who's doing what.
Set up alerts for strange behavior.

You can't respond to what you can't see. Simple as that.

Now let me be honest with you...

Here's the thing nobody tells you. The scariest security messes I've run into weren't slick, movie-style hacks at all.
They were little things somebody just missed:

Leaving an S3 bucket open “just for testing” and forgetting to close it
Accidentally pushing secrets to a public Git repo
Letting the whole team share a single admin account
Storing sensitive Terraform state files locally, unencrypted
Skipping proper environments and pushing straight to production because staging was down

In the moment, each one feels harmless. Tiny. And then it quietly cracks the door open for something much uglier down the line.

New to all of this? Where do you even begin without spiraling?

Take a breath, queen. Here's a gentle place to plant your feet:

✅ Move your secrets out of your codebase
✅ Store your Terraform state in a secure, remote backend with locking
✅ Add one security scanner to your workflow — just one is already progress
✅ Review infrastructure changes like you review application code
✅ Enable basic logging and alerting
✅ And start asking the question: “What could go wrong if this fails or leaks?”

That little shift in how you think? Honestly massive.

Security isn't about being paranoid. It's about being prepared.

To wrap this up:

DevSecOps isn't some shiny new tool or framework. It's a way of working. You're not just building systems that run. You're building systems that hold up under pressure, stay secure, and grow without falling over.

Thanks for reading! Be sure to watch the video version for extra insights and helpful visuals.

How AI Learns — and Where It's Actually Used

Tatiana Mikhaleva (devops.pink) — Mon, 07 Apr 2025 00:00:00 GMT

Hey, tech queens! And kings, don't act shy. I know you're here. 😉✨

Ever wondered how AI models actually “learn”? You go looking online and every explanation reads like it was written by a robot, for robots. Annoying. So I'm doing this the human way instead.

The headline: AI learning isn't magic. It's logic plus data plus the right kind of training, that's it. Machines learn in three main ways. And honestly, sis, they're kinda relatable.

So grab a matcha. Or an espresso, I don't judge. ☕👩‍💻

1. Supervised Learning — Like AI School With a Teacher

Picture the classic classroom.

You're showing someone photos of fruit and going:

“This one's an apple. This one's an orange. Got it?”
After a while, they start spotting apples and oranges all on their own.

That's supervised learning in a nutshell. You hand the AI a pile of examples, each one labeled with the right answer, and it picks up the pattern.

💡 Example:

Say you're building an app to recognize different bags. Because yes, I genuinely need AI to help me sort my closet.
You feed it photos labeled: tote, backpack, clutch.
One day a brand-new photo shows up and the model goes, “Oh, that's a clutch.” Boom.

🧠 It learns from: examples with answers
📦 Use cases: spam filters, price predictions, mood detection in texts
💅 Vibe: “Tell me what's what, and I'll learn it.”

2. Unsupervised Learning — The “I'll Figure It Out Myself” Energy

This one is different. It's more like dropping someone in a room full of fruit and saying:

“Here's a bunch of stuff. Sort it however makes sense.”
No labels. No clues. Just vibes. 😌

And somehow? They pull it off.

They start grouping things. By color, by shape, by size, whatever patterns they happen to notice. AI does the exact same thing.

💡 Example:

You've got hundreds of customers and zero info on who's who. Total mystery.
So your AI studies behavior, how often they buy, what they buy, when they shop, and clusters them into groups. Suddenly you know who your VIP is and who only shows up for the flash sales.

🧠 It learns from: raw, unlabeled data
📦 Use cases: customer segmentation, finding weird behavior (hello, fraud), organizing messy info
💅 Vibe: “I'm independent and intuitive, thanks.”

3. Reinforcement Learning — Learn by Doing (and Failing) 🎮

Okay. Now picture training your cat to stay off your laptop. Been there.

Stays on the floor? Treat.

Struts across your keyboard mid-Zoom call? No treat.

Eventually she figures it out.

That's the whole idea behind reinforcement learning. The AI tries something, gets feedback, adjusts, and gets a little better each round.

It learns through experience. Kind of like how the rest of us learn to never, ever trust hotel Wi-Fi again.

💡 Example:

Your robot vacuum smacks into your desk chair.
Ouch.
It backs up and tries a different route. Round after round, it maps the best paths for your space specifically, and becomes your tiny clean-freak buddy.

🧠 It learns from: trial + error + rewards
📦 Use cases: robots, game AI, delivery route optimization
💅 Vibe: “Let me try, fail fabulously, and come back stronger.”

Quick Recap — Because We Love a Cute Table

Type of Learning	Learns From	Main Goal	Vibe
Supervised	Examples + right answers	Make accurate predictions	“Teach me & I'll deliver.”
Unsupervised	Just data	Find patterns or clusters	“Let me figure it out.”
Reinforcement	Actions + feedback	Learn best strategy	“Trial, error, glow-up.”

Final Thoughts From Your Favorite Tech Girl

AI doesn't have to be confusing. Once the way it learns clicks for you, girl, it really clicks.

And honestly? It's not all that different from how we learn:

Supervised: like school.
Unsupervised: like figuring out a new city without a map.
Reinforcement: like finally learning not to text your ex, the hard way.

So next time someone drops “machine learning” into conversation, you'll just smile and think: “Oh, supervised? Cute. Classic.” 😌

Now that the learning part is locked in, let's go see where AI is actually slaying out in the wild.

Where is AI actually used?

And no, I don't mean some far-off sci-fi robot world. I mean right here, right now. In the stuff you already use, buy, click on, and even wear.

Let's drag this out of the textbook and into real life, shall we?

1. Healthcare — Dr. AI Is In

AI isn't replacing doctors. But it does help them. Think of it as a hyper-focused assistant that never blinks.

It can read medical images, compare test results across thousands of cases, and catch signs of a problem faster than the human eye ever could.

No, it's not diagnosing your cold. It might, though, flag the early signs of something serious before you even feel a thing.

Girl-coded example:

You get a chest scan. The AI pipes up: “Hey, this tiny area right here? Worth a closer look.”
The doctor reviews it, confirms it, and just like that you've got a life-saving second opinion. Yas.

2. Retail — AI Is Your (Low-Key) Shopping BFF

Ever wonder how your fave online store somehow knows you're obsessed with oversized hoodies and anything beige?

Yeah. That's AI.

It clocks what you click, what you buy, what you almost buy, and quietly builds a little vibe profile on you. Then it serves up stuff you're actually into, instead of random glitter crop tops. Unless that's your thing, no judgment.

Bonus:

AI helps brands manage stock too. So when the data screams iced coffee season and everyone's about to panic-buy reusable cups, AI nudges them to order extra before the shelves go bare.

3. Manufacturing — AI as Quality Control Queen

Forget waiting around for something to break. AI now predicts when a machine will break, before it actually does. It picks up on tiny signs of wear, watches equipment in real time, and keeps everything running smooth.

In other words:

Instead of “Oops, the machine died,” you get “Heads up, this part might fail in 3 days, wanna fix it now?”
A proactive moment. We love it.

4. Transportation — Not Just Self-Driving Cars

Self-driving cars hog the spotlight. But AI is everywhere in transportation these days.

Traffic light systems that trim your wait. Delivery apps that sniff out the fastest route even when your street is under construction again. AI's quietly behind the wheel on all of it.

Also:

It can plan bus routes, head off train delays, and basically keep your “I'll be there in 10” from quietly becoming 30.

5. Farming — Yes, Farming Got Smart Too

Think AI is strictly a techy big-city thing? Nope.

Farmers lean on it to nail the best time to plant, how much water each field actually needs, and the right moment to harvest for the biggest yield.

Pair drones with sensors and data analysis, and AI can literally tell you:
“Hey, that row of strawberries looks a little off, might be a pest problem.”

It's basically a skincare routine, but for plants.

6. Warehousing & Logistics — Organized Girl Energy

Ever stop to wonder how your next-day delivery actually happens? AI, babe.

It keeps tabs on where every single item is, routes packages in real time, and reshuffles on the fly the second something goes sideways.

(And yes, it almost certainly had a hand in picking your delivery slot too.)

Fun fact:
Some warehouses run almost entirely on AI. As in, your leggings got packed by a robot. Wild.

7. Customer Service — Not Your Basic Chatbot

The era of clunky bots that just hit you with “I didn't get that”? Over.

Today's AI assistants can actually parse your messy, typo-riddled question and hand you a real solution. At 3am. With zero attitude.

Real example:

You message a beauty brand: “Hey my order is late and I think I put the wrong zip code??”
The AI pulls up your order, fixes the address, updates the delivery, and never once parks you on hold for 47 minutes. Iconic.

So… Should You Use AI?

Here's the quick gut-check:

Ask yourself…	If yes, AI might help
Do you have data?	✅
Do patterns repeat in that data?	✅
Would you love to automate tasks?	✅

Nodded three times? Then guess what.
AI is not too much for you. You're ready.

Final Final Thoughts — Now You Really Get It

You don't have to build a neural network from scratch to get AI. You just need three things down:

How it learns
Where it works
What it needs to succeed

And now? You've got all three.

From fashion to farming, playlists to packages, AI is humming away behind so much of what we touch every day.

This isn't science fiction. It's the quiet genius in the background. And you, babe, are officially in the know.

Let's keep learning, keep building, and keep leading this smart-girl revolution.

10 Terraform Interview Questions You Must Know in 2025

Tatiana Mikhaleva (devops.pink) — Tue, 01 Apr 2025 00:00:00 GMT

So you've got a Cloud Engineer or DevOps Engineer interview lined up in 2025. Darling, you must know Terraform. It's one of the most in-demand tools out there for managing cloud infrastructure, and interviewers love asking about it.

Here are 10 must-know Terraform interview questions to help you land your next DevOps job! Real tips, real-world examples, the good stuff. 💪

import VideoPlayer from "@components/VideoPlayer.astro";

Question 1: What is Terraform and why should you care?

Terraform is a free tool made by HashiCorp. It lets you manage your cloud infrastructure (servers, databases, networks) using code instead of clicking around in a user interface like the AWS console.

You write some config files. Terraform reads them and builds all your resources for you. That's the whole idea.

Why it's useful:

You stop doing things manually. No more clicking the same buttons forever.
Your environments stay consistent across dev, test, and prod.
It works with multiple cloud providers like AWS, Azure, and Google Cloud Platform.

Example: Need 5 EC2 instances in AWS? Setting them up one by one is a pain. Write a Terraform script instead, and it spins everything up in one go.

🚀 Pro Tip: Someone might ask how Terraform differs from tools like Ansible or CloudFormation. Easy answer, sis: Terraform describes the end goal, meaning what you want things to look like, while Ansible focuses more on the step-by-step process of getting there.

Question 2: What are the main parts of Terraform?

Three pieces. Know them cold.

Providers connect Terraform to cloud platforms like AWS, Azure, GCP, and so on.
Modules are chunks of reusable code that keep you from repeating yourself everywhere.
State is a file that tracks what Terraform has already created.

Example: Say you're spinning up a server on AWS. The provider tells Terraform, "Hey, we're using AWS," and then a module can handle the networking, storage, and the rest of it for you.

Question 3: What is Terraform State and why is it important?

Terraform State is just a file. It remembers everything Terraform has built.

Why does it matter so much? A few reasons.

It keeps track of what already exists in your infrastructure.
It works out the relationships, or dependencies, between your resources.
It lets your whole team collaborate, especially when the state file lives remotely. That part is huge for team setups.

Here's where people mess up, queen: they save state on their laptop. One spilled coffee and your entire Terraform tracking is gone. Don't be that person.

🚀 Pro Tip: Store state in S3 and use DynamoDB for locking, or just go with Terraform Cloud to make life easier. And if someone drops the phrase "state locking" on you, it's basically just a way to stop multiple people from making changes at the same time.

Question 4: What's the difference between Terraform Plan and Apply?

Honestly? Simple.

terraform plan shows you what changes Terraform is going to make.
terraform apply actually makes those changes.

Example: Say you change an EC2 instance type from t2.micro to t3.micro. terraform plan will say, "Hey, this is the difference," and terraform apply will go ahead and make it happen.

🚀 Pro Tip: Before you apply anything, run terraform plan and save the output to a file. Now you can double-check what's about to happen. No nasty surprises.

Question 5: How does Terraform handle dependencies?

Most of the time, Terraform figures out dependencies on its own. It just reads how your resources connect to each other.

But sometimes you need to be explicit. That's where depends_on comes in. It tells Terraform, "Hey, make sure this thing is done first."

Example: You're creating an EC2 instance that needs a VPC. Terraform already knows to build the VPC first.

🚀 Pro Tip: Try not to lean on depends_on too much. Terraform is smart, code cuties. It usually handles this without any extra hand-holding.

Question 6: What is Terraform Drift and how do you find it?

Drift is when something in your cloud setup changes outside of Terraform. Maybe a coworker made a manual tweak in the AWS Console. Now your code doesn't match what's actually running, and that's a problem.

How do you catch it? Run terraform plan. It'll flag anything that changed when Terraform wasn't looking.

🚀 Pro Tip: Want to stay organized and current? Set up automatic drift checks in Terraform Cloud, or add a simple step to your automation setup to check for changes from time to time.

Question 7: How do you handle sensitive data in Terraform?

Secrets need care. Here's how to keep them safe.

Use variables and set sensitive = true.
Store the secrets somewhere actually secure, like AWS Secrets Manager or Vault.
Make sure your remote state is encrypted.

🚨 And seriously, never put passwords directly in your code or state files. Ever.

Question 8: What are Terraform Workspaces?

Workspaces let you use the same Terraform config across different environments like dev, staging, and prod.

🔹 You can run commands like:

terraform workspace new dev
terraform workspace select dev

🚀 Pro Tip: Workspaces are fine for small projects. But once your system gets bigger, separate state files are usually the smarter call.

Question 9: What are Terraform Modules and why use them?

Modules are reusable bits of code that make your Terraform setup way easier to manage.

So why bother with them?

They stop you from copy-pasting the same code into every project.
They keep your files nice and organized.
They help your infrastructure stay consistent everywhere.

📌 Example: Build a module for a VPC once, then reuse it in a bunch of places. No rewriting that code over and over.

🚀 Pro Tip: Before you write your own module, check out the Terraform Registry. Someone else may have already built exactly what you need. Work smarter, not harder.

Question 10: How do you use Terraform in an automated deployment process?

You can plug Terraform into your CI/CD setup using tools like:

GitHub Actions
GitLab CI
Terraform Cloud

🛠 Here's a basic workflow:

Run terraform fmt and terraform validate to check formatting and syntax.
Use terraform plan to preview the changes.
Only run terraform apply after someone gives the green light. Especially in production.

🚀 Pro Tip: Some teams also use Open Policy Agent to apply security rules before changes go live.

🔥 Alright, that's a wrap! These 10 Terraform questions should give you a solid foundation for your next DevOps interview.

Thanks for reading! Be sure to watch the video version for extra insights and helpful visuals.

AI for Beginners - How It Works, Learns, and Makes Decisions

Tatiana Mikhaleva (devops.pink) — Mon, 31 Mar 2025 00:00:00 GMT

Hey, lovely tech queens! 👩‍💻✨

Honestly? Tech terms like AI, machine learning, and deep learning get thrown around constantly. And unless you've spent your nights reading research papers (I haven't either), they can sound like a black box.

But they're not.
So let me break them down for you. Clearly, with real-life examples, and yes, that includes oranges and smart thermostats.

Part 1: What is AI — and why does everyone talk about it?

AI stands for Artificial Intelligence. And no, it's not about robots with feelings. It's about teaching machines to do things that usually need a human brain:
understanding language, recognizing images, predicting what happens next, making decisions.

AI shows up in your everyday life way more than you'd think:

Your phone suggests the next word before you finish typing.
Your bank detects suspicious activity before you even notice.
Your email knows how to separate spam from real messages.

None of that is magic, sis. It's data, models, and a bit of logic, all working together.

Part 2: How AI learns — and what ML and Deep Learning have to do with it.

Here's the thing. To make a machine smart, you don't sit there writing instructions line by line. You let it learn from examples instead, and that right there is Machine Learning (ML).

Then you've got Deep Learning. It's a fancier method that lets machines tackle the hard stuff, like recognizing speech, picking apart images, or making sense of natural language.

Want a clear example?

Picture this. You live in a smart home with a smart thermostat.

The thermostat uses AI to decide whether to heat the room.
It uses ML to learn that you usually come home around 7 p.m., so it starts warming up at 6:30.
It uses Deep Learning to go even further: it checks your location, your calendar, even the way you message friends, and figures out that today you'll be home early. So it heats the room ahead of time, and you didn't lift a finger.

That's how it works. Step by step. Smarter every time.

Part 3: What happens after learning — the role of inference.

Once the model is trained, the learning phase wraps up. Now comes the fun part. It's time to actually use what it knows.

We call this inference. It's the moment the AI makes a decision based on everything it already learned.

Here's a simple one:

Say you trained a model to tell oranges from apples.
Now you show it a brand new fruit photo.
It takes a look and goes: “That's an orange.”
Queen, that's inference. The model in action, making predictions or sorting things into buckets based on what it picked up earlier.

Part 4: Two types of inference — real-time vs batch.

Not every AI decision happens the same way. Sometimes you need an answer this second. Other times you've got a mountain of data to chew through quietly in the background.

Let me lay it out:

1. Real-time inference

This is the AI reacting immediately the moment new input lands.

Examples:

A smart fridge notifies you that milk is low the second you open the door.
A navigation app recalculates your route as soon as you take the wrong turn.
An e-commerce site recommends similar items the moment you click on a product.

Speed is everything here. The response has to be fast and smooth, no lag.

2. Batch inference

This one kicks in when the system crunches large amounts of data at once, usually on a set schedule.

Examples:

Your sales data is analyzed overnight to generate a report by morning.
A bank reviews all transactions at the end of the day to assess risk levels.
A job platform scans thousands of resumes every weekend to find top matches.

Nothing about this needs to be instant. It's a depth-and-scale kind of job.

When to use what? Here's the cheat sheet:

You need	Use this type
Instant feedback or decision-making	Real-time inference
Large-scale analysis without time pressure	Batch inference

A note from one IT girl to another

AI isn't some far-off futuristic fantasy, darling. It's already here, quietly making your day smoother and your tools sharper. And you really don't need a degree in algorithms to get how it works.

If this clicks for you:

AI = the system that acts smart,
ML = how the system learns from data,
Deep Learning = how it handles complex patterns,
Inference = how it applies what it learned to make decisions,

then congrats, code cutie. You're already ahead of most people.

Keep learning. Stay curious. And please don't let a few scary tech terms intimidate you.
You're more than smart enough to master this.

Docker Run, Swarm & Kubernetes - Scaling Made Simple

Tatiana Mikhaleva (devops.pink) — Tue, 25 Mar 2025 00:00:00 GMT

Hey, tech queens! 👩‍💻✨

Scaling, decoded. Docker Run, Swarm, and Kubernetes, explained the easy way 🍭🚀

So you've nailed docker run. You spun up your first container. You're feeling like a total tech queen, and honestly? You should.

Then your app gets popular. Yas! You need more power. And out of nowhere it hits you:

“Wait… how do I run multiple containers? On multiple servers? Without chaos?”

Breathe, darling. You're about to level up your container game. We'll talk through Docker Swarm vs Kubernetes, what each one actually does, and how they help you scale with style.

Docker Run: Your First Crush

You type this:

docker run my-app

Boom. Your container is alive, it's running, and you feel unstoppable.

Here's the catch, though:

It only launches one container
If it crashes, you have to fix it yourself
Scaling? Load balancing? Not happening

For learning and testing, it's perfect. But the moment you want to go big, you'll need to call in reinforcements.

Docker Swarm: Your First Automation Sidekick

Swarm is Docker's built-in orchestration tool. Think of it as your first step into scaling smart.

One command. That's all it takes to launch a bunch of containers across different servers, and Swarm quietly handles the rest.

docker service create --name my-app --replicas 3 my-image

Swarm will:

Distribute containers across machines
Restart them if they crash
Balance traffic between them

Basically: you build, Swarm keeps the whole thing running.

Why I love it:

Easy to use
No extra tools needed
Perfect for small projects or learning orchestration

Kubernetes: The Boss of Container Management

If Swarm is your sidekick, then Kubernetes (K8s) is the full-blown operations manager. She's powerful. She's reliable. Companies like Google, Netflix, and Spotify trust her to keep their apps alive.

Kubernetes can:

Auto-scale your apps based on resource usage
Roll out updates with zero downtime
Heal itself when something breaks
Run across clouds and data centers

And it starts with one little line:

kubectl create deployment my-app --image=my-image

Just like that, you've deployed an app that can scale to the moon and patch itself up along the way.

Kubernetes doesn't just run containers. It runs your whole platform.

Swarm vs Kubernetes — What's the Difference?

Feature	Docker Swarm	Kubernetes
Setup	Simple & fast	Advanced, more setup
Scaling	Basic replicas	Full auto-scaling
Healing	Restarts containers	Smart health checks + recovery
Best For	Learning & light apps	Serious production systems
Vibes	Chill side project	Cloud-native powerhouse

DevOps Pink Girl Tips

Start with Docker + Swarm to get the basics down
Move to Kubernetes when you're ready for pro-level control
Use Minikube to run Kubernetes locally
Learn kubectl commands like get pods, describe, and apply — they're gold
Don't panic — it all makes sense with practice!

Final Thoughts: You've Got This

Running a tiny app or babysitting whole cloud setups like a queen? Either way, orchestration is your next big step.

Docker Run is where we all start.

Swarm helps us grow.

Kubernetes? That's where the real magic happens.

You're not just launching containers anymore, sis. You're building systems, scaling apps, and stacking up some serious DevOps vibes.

So if you're stepping into Swarm or K8s life, go flex those tech muscles. I'm always here for your container wins!

Got a favorite kubectl command or a Swarm tip you swear by? Drop it in the comments. Let's geek out together!

How Docker Works Under the Hood - A Girly Tech Deep Dive

Tatiana Mikhaleva (devops.pink) — Fri, 21 Mar 2025 00:00:00 GMT

Hey, tech queens (and kings, if you're here too)! 👩‍💻✨

So here's the plan. We're going under the hood of Docker to see what actually happens when we run those magical docker run commands. Are you the curious, IT-obsessed type who can't rest until you know how stuff actually works? Same, sis. You're in for a treat! 🍭🚀

So, What Even Is Docker?

Honestly? Docker makes life so much easier. No more installing a million dependencies. No more “it works on my machine” drama (ugh, been there!). We just throw everything into a container and let Docker do its thing.

But what's actually happening behind the scenes? Let me spill. ☕

Docker Is Not a Virtual Machine (And That's Important!)

Okay, first things first. If you think Docker is like VirtualBox or VMWare, girl, we need to talk! 🙅‍♀️

Virtual Machines (VMs) spin up a whole new OS inside another OS. So they're slow. They eat resources for breakfast. Basically each one acts like a separate computer living in your computer.

Docker doesn't do that at all. Instead it runs containers on the same OS kernel as your host machine. Picture all the apps open on your phone right now. Each one is its own little thing, but they're all sharing one iOS or Android underneath. That's the vibe.

🚀 Result: Docker containers boot in seconds, sip way less memory, and stay super lightweight next to a VM.

What Happens When You Run `docker run`?

You type docker run nginx and boom, your container is up and running. But what actually fires off behind that one little command? Here's the tea ☕:

1️⃣ Docker CLI talks to Docker Daemon 💬

The CLI (Command-Line Interface) sends a request to the Docker Daemon (a background process that does all the hard work). Think of the daemon as Docker's fairy godmother 🧚‍♀️—it grants your wish to run containers!

2️⃣ Docker Daemon checks for the image 🔍

No Nginx image sitting on your machine? Docker goes and pulls it from Docker Hub (kind of like an app store for containers).

3️⃣ Docker creates a container 📦

It sets up namespaces (more on that below!), allocates resources, and makes sure the container is walled off from your main system.

4️⃣ Docker starts the container's main process 🚀

Containers are really just Linux processes running in their own isolated bubble. They don't boot a full OS the way a VM does. Just the app you asked for, nothing extra.

5️⃣ You now have an active container! 🎉

Run docker ps and you'll see it in action!

How Docker Keeps Containers Separate

So if every container shares the same OS kernel, how on earth do they stay out of each other's business? Two words: Linux namespaces and cgroups. This is where the magic actually lives.

💎 Namespaces = "You do you, I do me!"

Namespaces give each container its own private world: its own file system, its own network, its own process tree, the whole apartment.
That's the reason you can run ls inside a container and not see a single one of your host's files!

💎 Cgroups = "You get this much CPU, you get this much RAM!"

Containers share resources, sure. But cgroups make sure one greedy little container doesn't hog all the CPU or memory for itself.
Think of a Netflix account with multiple users. Everyone gets their fair share!

Why This Matters (And Why You Should Care)

So now you know Docker isn't actually magic. (Though, real talk, it sure feels like it sometimes ✨.) And once you get how it really works under there, you debug faster, you tune your performance, you start wielding the thing like a total pro.

👩‍💻 Next Steps:

Try running docker stats to see how much CPU/memory your containers use.
Experiment with docker inspect to peek inside a container's metadata.
Play with docker network ls to check out how containers communicate!

Final Thoughts

Docker is a total power-up. But the girls who know what's happening underneath? Unstoppable. Now go flex your new knowledge, container queen! 👑💻🔥

Tag me if you try any of these tips.

I'd love to hear about your Docker adventures! 🚀💬

Docker Compose Explained - Imagine Running Your Own Cafe

Tatiana Mikhaleva (devops.pink) — Tue, 18 Mar 2025 00:00:00 GMT

Hey, tech queens! 👩‍💻✨

So you've heard people throw around Docker and containers a hundred times and your eyes glaze over. Been there. Don't worry, I got you. We're going to make this click. No dusty textbook definitions here, sis. Just real-life vibes and practical IT girl wisdom.

Picture this for a sec. You're the head chef of your dream restaurant. You've got a baking station, a coffee station, a smoothie station, the works. And your goal is simple: run a kitchen so smooth that every single plate comes out chef's kiss perfect. Now here's the twist. You decide to open the exact same restaurant in another city. How do you guarantee everything works the same way over there?

That's the whole reason Docker exists. Let me show you.

What Even is Docker?

Okay. Think of Docker as a way to pack each of your kitchen stations into a perfectly organized "to-go" box. Inside the box? Everything that station needs to run. Ingredients, tools, instructions, the whole vibe. You ship that box off to another restaurant (read: another server), and all they do is unbox it and BOOM, instant setup. No fuss.

In IT terms:

Instead of manually installing software, databases, and dependencies on different servers, Docker packs them into containers that can run anywhere.
No more “It worked on my machine but not yours” drama—it runs the same way, every time.

Running a Single Container = Turning On One Kitchen Appliance

Say you just want to make coffee. Simple. You press a button, the coffee machine turns on, and magic happens.

In Docker, the equivalent is:

docker run coffee-maker

Translation? “Turn on my coffee machine container and start brewing.”

Here's the catch, though. Nobody walks in and orders JUST coffee. People want the full experience. Pastries. Fresh juice. That cozy little corner-table feeling. So yeah, running one Docker container is great for one job. But what happens when you need a whole team of containers working together?

Docker Compose = Running Your Entire Kitchen Like a Boss

Picture a kitchen with zero coordination:

The barista starts making coffee but there's no milk.
The baker finishes a croissant, but there's nowhere to put it because the plates haven't arrived yet.
The smoothie blender starts running... but no one put fruit in it.

Total chaos, right? That's exactly what happens when you've got multiple containers and none of them know how to work together.

So in walks Docker Compose, aka the kitchen manager of your IT dreams. No more flipping every appliance on by hand, one at a time. Instead, you write a simple file (compose.yml) that tells all the stations when and how to start working. Then, with one command, your entire system boots up, perfectly in sync:

docker compose up

Translation? "Wake up, kitchen! Let's do this!" 🚀

How Does Docker Compose Keep Your Kitchen in Order?

Let's say your restaurant serves a signature breakfast set:

A fresh croissant (baked in the oven 🥐)
A cappuccino (made in the espresso machine ☕)
A smoothie (blended to perfection 🍓)

Here's how Docker Compose keeps it all running like a dream.

1 It Starts the Right Appliances First

You can't make a cappuccino before heating the milk, queen. Tech works the same way. Your databases must start before your app, otherwise it crashes the second it goes looking for data that isn't there yet.

So in Docker Compose, we define dependencies. That way containers know who needs to start first.

2 It Connects Everything Automatically

Your barista has to talk to the baker to keep orders moving. Services are no different. Your app needs to communicate with the database, payment system, and notification service.

Docker Compose links all containers together, so they can "chat" without extra setup. No wiring required.

3 It Scales Up When Needed

Your cafe blows up overnight (hello, influencer magic ✨). What do you do? You hire more baristas to keep the line moving. Docker does the same trick. More traffic hitting your site? You easily add more containers without breaking a sweat.

docker compose scale coffee=3

Boom. Three baristas, no waiting in line.

Why Should an IT Girl Care About Docker?

Real talk. If you're serious about tech, Docker is a must-have skill. Doesn't matter if you're a developer, DevOps babe, or cloud queen. Docker saves you time and cuts down on errors, and best of all it frees you up to do actual coding instead of fixing messy setups.

With Docker, you can:

✔ Run the same setup on ANY computer - no more “but it works on my laptop” drama. ✔ Test new features in seconds - spin up a new environment with one command. ✔ Easily switch between projects - each app gets its own contained world. ✔ Deploy apps like a pro - your code runs the same on any server, anywhere.

Final Thoughts: Own Your Tech Kitchen!

I won't lie, Docker can look intimidating on day one. But trust me, it's basically Tupperware for your code. Once you start thinking in containers, running your apps gets as easy as running your favorite cafe.

💡 IT Girl Tip: Want to practice? Start by containerizing something simple—like a personal website or a tiny database. Once you get the hang of it, scaling up will be a breeze!

So next time someone starts talking Docker at you, just picture your dream cafe running smoothly with a single command. And remember: you, my tech queen, are the one running the kitchen. 🍽✨

Let's go build something amazing! 🚀

DNS for IT Girls - How the Internet Works Like Magic

Tatiana Mikhaleva (devops.pink) — Sat, 15 Mar 2025 00:00:00 GMT

Hey, tech queens! 👩‍💻💖

So let's talk DNS. It's the secret behind why you get to type google.com instead of some long, impossible-to-remember number. DNS is what makes the internet easy and user-friendly. And once it clicks for you? You'll feel like a total networking goddess. 👑💡

What is DNS?

DNS (Domain Name System) is basically the translator of the internet. It takes human-friendly domain names (web.yourcompany.net) and turns them into machine-readable IP addresses.

Think of your phone contacts. You don't memorize numbers, you just tap a name. DNS pulls the same trick, except for websites.

Without it? You'd be typing 10.0.0.25 every time you wanted facebook.com. Not cute. 😅

The Hosts File: The Old-School Hack

Way back before DNS, people mapped names to IPs by hand, in the /etc/hosts file. Yeah, ancient times. 😂 But here's the fun part. That trick still works today, and you can use it to override your machine's DNS settings whenever you feel like it.

Pro Tip: Manually Map Names to IPs

Say you've got a database server sitting at 10.0.0.5, and you'd rather reach it by typing database. Drop this single line into your /etc/hosts file:

10.0.0.5 database

Done. Now every ping database you run connects straight to 10.0.0.5, and DNS doesn't even get a vote. #HackTheNetwork 😏💻

Enter the DNS Server!

Managing hostnames by hand gets messy, fast. That's the whole reason DNS servers exist. They keep everything in one place, so instead of babysitting a giant hosts file, your system just asks a DNS server for the right IP.

Picture your company's internal DNS server living at 10.10.10.1. Your laptop pings it any time it needs to resolve a hostname. And if that server has no clue? It forwards the request up the chain until somebody knows the right IP.

Pro Tip: Set a Custom DNS Server

Want to tell your system exactly where to look? Update the /etc/resolv.conf file like so:

nameserver 10.10.10.1

And just like that, all DNS requests head to 10.10.10.1 first. 🎯

Subdomains: The DNS Name Tree

Ever notice we have maps.yourcompany.net, mail.yourcompany.net, and drive.yourcompany.net? Those are subdomains, darling. They keep all the different services inside a company or website neat and organized. 🌍✨

Here's what a company setup might look like:

web.yourcompany.net → Main website
db.yourcompany.net → Database server
mail.yourcompany.net → Email services

When someone types one of those names, DNS makes sure they land on the correct servers. It's the road sign system of the internet! 🚦

DNS Caching: How the Internet Gets Faster

Every time you load a website, your system tucks away the DNS result, so it never has to ask twice. That's caching. It makes everything snappier 🚄. The catch? It can trip you up when an IP changes underneath you.

How to Clear Your DNS Cache

Website acting weird and refusing to load? Flushing the DNS cache often fixes it.

🖥️ On Windows:

ipconfig /flushdns

💻 On Mac/Linux:

sudo systemd-resolve --flush-caches

Now your system goes and grabs fresh DNS info instead of clinging to stale data. 🔥

Public vs Private DNS: Who Controls the Internet?

When your DNS server doesn't know the answer, it passes the question along to public DNS servers. The big ones:

✅ Google DNS → 8.8.8.8
✅ Cloudflare DNS → 1.1.1.1
✅ OpenDNS → 208.67.222.222

But inside company networks? Private DNS servers run the show, and they keep things locked down. Because if you work at yourcompany.net, the last thing you want is random strangers resolving your internal servers. 🚨

Recap: DNS is the GPS of the Internet!

So now you've got it. DNS is the backbone of the web. It translates names into IPs, sorts out your subdomains, caches results so everything flies, and lets you override settings when needed.

Quick Cheat Sheet:

✅ /etc/hosts → Manually map names to IPs
✅ /etc/resolv.conf → Set your preferred DNS server
✅ ping, nslookup, dig → DNS troubleshooting tools
✅ ipconfig /flushdns → Clear DNS cache (Windows)
✅ systemd-resolve --flush-caches → Clear DNS cache (Linux/Mac)

And that makes you an official DNS queen. 👑💻 So tell me, sis, have you ever messed around with your own DNS settings? Let's chat in the comments! 💬✨

Linux for Beginners - Essential Commands Every IT Girl Must Know

Tatiana Mikhaleva (devops.pink) — Mon, 10 Mar 2025 00:00:00 GMT

Hey, lovely tech queens! 👩‍💻✨

If you're stepping into the world of Linux, welcome to the coolest club ever! I know, the command line can look super intimidating at first (been there, freaked out 🙈), but trust me—once you get the hang of it, you'll feel like a total hacker goddess.

Here's my ultimate Linux cheat sheet—the basic commands every IT girl needs to master. These will help you navigate, manage files, and work like a pro. Let's go! 🚀

First Things First: Why Even Bother with Linux?

So, why are we talking about Linux when macOS and Windows exist? Because real IT girls know that:

✔️ Most servers run on Linux, so if you dream of a tech career, you NEED this.
✔️ Developers and cybersecurity pros swear by it—like, ethical hacking? Linux is your BFF.
✔️ It's free, open-source, and powerful—total boss babe energy.

And honestly—nothing screams I know my sht* like typing commands in a black terminal.

Getting Started: Open That Terminal!

Before we slay the Linux game, let's open the terminal:

On Linux: Ctrl + Alt + T
On Mac: Use "Terminal" from Spotlight (Cmd + Space, then type “Terminal”).
On Windows: Install WSL (Windows Subsystem for Linux) or use Git Bash.

Alright, let's get into the commands that will make you feel like a total IT girl! 💅

Navigating Like a Pro: Moving Around Folders

💡 The first thing you need to learn is how to navigate your system. Forget clicking around—let's move like a boss in the terminal.

1 Where Am I? (Check Current Directory)

pwd

📌 This tells you which folder you're in. Super useful if you ever feel lost.

2 What's Inside This Folder? (List Files)

ls

📌 This shows all files and folders in the current directory.

💖 Pro tip:

Use ls -l for more details (file size, date, owner).
Use ls -a to see hidden files (yes, Linux hides stuff from you).

3 Moving Between Folders (Change Directory)

cd foldername

📌 Moves you into a folder.

Want to go back?

cd ..

📌 Moves up one level.

Or just type:

cd ~

📌 Takes you straight to your home directory.

✨ Think of these commands as teleporting through your files. No more aimless clicking!

File & Folder Magic: Creating, Moving & Deleting

Alright, now that we can move around, let's start making things happen!

4 Create a New Folder (mkdir)

mkdir myfolder

📌 Boom! A new folder is born.

💖 Pro tip:

Want to create multiple nested folders? Use mkdir -p parent/child/grandchild.

5 Create a New File (touch)

touch myfile.txt

📌 Creates an empty file. Perfect for testing.

6 Move or Rename a File (mv)

mv oldname.txt newname.txt

📌 Works for renaming files AND moving them.

💖 Example: Move a file into a folder:

mv myfile.txt myfolder/

Now it's inside myfolder. So neat!

7 Copy a File (cp)

cp myfile.txt copyfile.txt

📌 Now you have a duplicate!

Want to copy a whole folder?

cp -r myfolder newfolder

📌 The -r flag copies everything inside too!

8 Delete a File (rm)

rm myfile.txt

📌 Bye-bye, file!

Be super careful! If you use:

rm -r myfolder

📌 It deletes the entire folder + its contents. No undo! 😱

Reading & Editing Files

Alright, let's check what's inside our files.

9 Read a File (cat)

cat myfile.txt

📌 Shows the contents of a file instantly.

💖 Pro tip:

If the file is too long, use:
```
less myfile.txt
```
📌 This lets you scroll through it. Press q to exit.

10 Edit a File (nano)

nano myfile.txt

📌 Opens a simple text editor inside the terminal.

Running Programs & Managing Processes

Check Running Processes

ps aux

📌 Shows all running programs.

Kill a Stuck Program

kill PID

📌 Or use:

pkill -f process_name

📌 This kills the process by name (super handy!).

Bonus IT Girl Tricks!

Redirecting Output: > vs >>

echo "Hello" > file.txt overwrites the file.
echo "Hello" >> file.txt adds text to the file without deleting old content.

View Command History

history

📌 Lists all commands you've used—no more "What was that command again?" moments!

Find Any File

find / -name "filename"

📌 Searches for a file anywhere on your system.

Want something faster?

locate filename

📌 But first, run:

sudo updatedb

📌 This updates the file database for locate.

Final Thoughts: Own That Terminal, Queen!

So, my fellow IT girl, this is your Linux survival kit. These commands will help you navigate like a pro, manage files, and even kill frozen programs like a boss.

💡 Your next steps:

✅ Practice these commands daily.
✅ Start using Linux as your main OS (if possible).
✅ Experiment & break things—just don't delete your whole system! 😆

And remember, every tech queen starts somewhere—the key is to keep learning. 💕

💬 Got questions? Comment below, and let's geek out together! 🚀

Docker for Girls - Understanding docker ps Once and For All

Tatiana Mikhaleva (devops.pink) — Fri, 07 Mar 2025 00:00:00 GMT

Hey girls! 💖

If you're as passionate about IT and Docker as I am but sometimes find it a bit complicated, don't worry! Today, I'll explain the super-important docker ps command in a way that anyone can understand! 😉

What is `docker ps`?

This command shows all the containers on your computer. It tells you which ones are running, which ones are stopped, and what their settings are. Think of docker ps as your list of all containers—just like a list of open tabs in your browser. 🖥️

When Should You Use `docker ps`?

You use docker ps when you want to:

See which containers are currently running.
Find out which containers have stopped.
Get the ID or name of a container.
Check which ports are open.
View the size of a container.
Check if a container is healthy (yes, containers can have bad days too!).

How to Use `docker ps` (Examples)

The Simplest Command:

docker ps

Shows only running containers.

Want to See All Containers, Even Stopped Ones?

docker ps -a

Now you can see both running and stopped containers. The STATUS column will show why a container stopped (e.g., due to an error or just being turned off).

How to View the Last Created Container?

docker ps --latest

Great for checking if the most recently created container is working properly.

How to Check How Much Space a Container is Using?

docker ps -s

This helps when your disk space is running low. 🧹

How to See Only Container IDs?

docker ps -q

Useful when you need container IDs without extra details.

Filtering `docker ps`

To quickly find the container you need, use filters:

🔍 Find a container with a specific label:

docker ps --filter label=app=my-app

🔍 Show containers created before a specific one:

docker ps --filter before=my-app-container

🔍 Find containers using a specific volume:

docker ps --filter volume=my-volume

🔍 See containers in a specific network:

docker ps --filter network=my-network

How to Change `docker ps` Output?

By default, docker ps outputs a table, but you can customize what is displayed:

docker ps --format 'table {{.ID}}\t{{.Image}}\t{{.Status}}'

This will show only the container ID, image, and status.

Want JSON format? Easy:

docker ps --format json

Pro Tips!

✨ Don't forget about -a: If a container stops, docker ps won't show it by default, so use docker ps -a.
✨ Set up your favorite commands: For convenience, create aliases for frequently used commands.
✨ Monitor container sizes: Keep only the necessary containers to avoid wasting disk space.

Conclusion

The docker ps command is your go-to tool for managing containers. Now you know how to check which containers are running, which have stopped, and how to filter them. Easy, right? 😉

I hope this guide helped! If you have any questions, feel free to ask—I'm always happy to chat about Docker. 💻💖

See you soon, IT girl! 🚀

Mastering Terraform Tags Like a True IT Queen

Tatiana Mikhaleva (devops.pink) — Tue, 04 Mar 2025 00:00:00 GMT

Hey girls!

If you're as obsessed with Infrastructure as Code (IaC) as I am, then you know that Terraform is THE tool to have in your IT arsenal. And if you're working with cloud resources, you've probably heard about tags - those little key-value labels that help you organize, track expenses, and automate processes.

But let's be honest: tags can sometimes feel like a necessary evil, especially when you're managing multiple cloud environments.

Don't worry, darling! Here's the rundown on Terraform tags: why you need them, how to use them, and the best practices to follow. So grab your favorite coffee ☕ and let's go!

What Are Terraform Tags?

Think of Terraform tags as little stickers you can attach to cloud resources to keep things organized and manageable. They are key-value pairs that allow you to classify resources by purpose, environment, or owner.

📌 Example:

tags = {
  Environment = "Production"
  Owner       = "IT Girl Dev Team"
  Project     = "CoolNewApp"
}

💡 Why do you need this? Because proper tagging makes resource management easier, helps automate processes, and controls access. Plus, it keeps your infrastructure structured and aesthetic - and we don't want a messy cloud, do we? ❌

Tags vs. tags_all: What's the Difference?

Terraform has two types of tags: tags and tags_all. They sound similar but serve different purposes:

tags - The tags you define in your Terraform code.
tags_all - A read-only attribute that Terraform pulls from the resource itself.

📌 Example (referencing tags in Azure):

azurerm_virtual_network.example.tags_all

Why Should You Use Tags?

Tags aren't just for aesthetics (although we love that too 💅). Here are some key reasons why tagging is essential:

Organization

Imagine having thousands of resources in your AWS account without tags. Total chaos, right? Tags help group resources by environment, project, or team.

📌 Example:

tags = {
  env     = "staging"
  owner   = "DevOps Team"
  purpose = "testing"
}

Cost Management

Cloud bills can be terrifying 😱, but Terraform tags help you track where your money is going.

📌 Example:

tags = {
  cost_center = "Marketing Analytics"
}

Automation

You know how much I love automation! Tags allow you to manage deployments, shut down unnecessary resources, and set up backups.

📌 Example:

tags = {
  auto_shutdown = "true"
  deploy        = "true"
}

Access Control

You can configure tags to restrict access to resources using AWS IAM policies.

📌 Example:

tags = {
  Environment = "Development"
}

How to Add Tags to Terraform Resources

It's super simple! Just use the tags attribute inside the resource block.

📌 Example:

resource "aws_instance" "my_instance" {
  tags = {
    Environment = "Production"
  }
}

Want to Add Multiple Tags? Easy!

tags = {
  Environment = "Development"
  Owner       = "Leia Organa"
  Department  = "Rebel Alliance"
}

What Are Terraform Default Tags?

Default Tags are automatic tags applied to ALL resources without having to duplicate them in every block.

📌 Example:

variable "common_tags" {
  type = map(string)
  default = {
    Environment = "Development"
  }
}

Then, just use them like this:

tags = var.common_tags

How to Override Default Tags?

Use the merge() function to combine default and custom tags.

📌 Example:

resource "aws_instance" "my_instance" {
  tags = merge(
    var.common_tags,
    {
      Name = "MyAwesomeServer"
    }
  )
}

How to Ignore Tag Changes in Terraform?

If external systems modify your tags (Azure Databricks, I see you 👀), tell Terraform to ignore them!

📌 Example:

resource "aws_instance" "my_instance" {
  lifecycle {
    ignore_changes = [tags]
  }
}

Or ignore them at the provider level:

provider "aws" {
  ignore_tags = ["CostCenter"]
}

Best Practices for Terraform Tags

💡 Tips to keep your cloud tagging strategy clean and effective:

✔ Be consistent 👑 - Use the same key names across resources.
✔ Document your tags 📚 - Define what each tag means.
✔ Automate tagging ⚙️ - Use Terraform modules.
✔ Use Default Tags ✅ - Follow the DRY (Don't Repeat Yourself) principle.

Level Up Your Terraform with Spacelift

Want a flawless GitOps process? Try Spacelift! It makes Terraform even better with:

✨ Security policies (OPA) 🔐
✨ Multi-IaC support (Terraform + Kubernetes + Ansible) 🔄
✨ Self-service infrastructure 💁‍♀️

Conclusion

Terraform tags may seem small, but they make a huge difference in cloud resource management. Start using them correctly, and your future IT-self will thank you!

Share your favorite Terraform hacks in the comments or on Twitter! 💬💻

Until next time, keep slaying the IT world! 🚀💖

AWS AI/ML - The Ultimate Guide for IT Girls

Tatiana Mikhaleva (devops.pink) — Fri, 28 Feb 2025 00:00:00 GMT

Hey, my tech-savvy girls!

💕👩‍💻 So here's the thing. If you're anything like me and obsessed with IT and machine learning, you're going to love AWS AI/ML services. They help companies (and honestly, even solo girlies like us) put artificial intelligence to work without all the headache.

⚡ Think of AWS as Netflix for IT. Except instead of movies, you get a giant ecosystem of tools that automate processes, analyze data, create chatbots, and even turn text into lifelike speech. Wild, right?

By the time you finish this article, I want you to feel like an expert. So I'm going through everything, slowly, in plain language. 🚀💡

AWS: The Magical Toolbox for IT Girls

AWS is Amazon's global cloud platform. It lets businesses and developers tap into a huge range of technologies on a subscription basis, no own data centers required. None. You just rent what you need.

How does it actually work?

1️⃣ You log into AWS, pick the service you need, and start using it.
2️⃣ Everything runs in the cloud, so you don't need to worry about managing servers.
3️⃣ AWS automates all processes and gives you ready-made AI/ML solutions.

There are a TON of services in here. Let me walk you through the ones I find most interesting and useful, queen.

AWS AI/ML Is Like an Amusement Park: Hop On

1. Amazon SageMaker - The Queen of Machine Learning

💡 What is it?

Amazon SageMaker is the most powerful AWS tool for machine learning. It lets you build, train, and deploy ML models without needing deep programming knowledge. That last part? Huge.

💖 How does it work?

✔️ You choose an ML model (or use a prebuilt one).
✔️ Upload data (e.g., last year's sales for an online store).
✔️ SageMaker trains the model and makes predictions.

📌 Where is it used in real life?

✅ Finance - predicts stock price movements.
✅ Weather forecasting - analyzes temperature trends.
✅ E-commerce - recommends products to customers.
✅ Fraud detection - identifies suspicious bank transactions.

💡 IT Girl Tip:

New to ML? Don't stress. SageMaker automates everything. You upload data, and it does the magic for you. ✨

2. Amazon Lex - Smart Chatbots & Virtual Assistants

💡 What is it?

Amazon Lex is an AI service for creating smart chatbots and virtual assistants like Alexa or Siri.

💖 How does it work?

✔️ Uses Natural Language Processing (NLP) to understand what users are saying.
✔️ Processes both text and voice commands.
✔️ Works based on intents—you set up sample phrases, and the bot learns to respond.

📌 Where is it used in real life?

✅ Customer service chatbots - answer FAQs without human agents.
✅ Virtual assistants - Alexa-style bots for businesses.
✅ Data search bots - find information quickly based on user queries.

💡 IT Girl Tip:

Always wanted to build your own chatbot? Lex gets you there without the complex coding, sis.

3. Amazon Polly - The AI Voice Generator (Talking Robot)

💡 What is it?

Amazon Polly is an AI tool that turns text into lifelike speech! This one is genuinely fun to play with.

💖 How does it work?

✔️ You type in a text.
✔️ Polly reads it in a natural-sounding voice (male, female, child, and even with accents!).
✔️ You can adjust tone, speed, and emotions.

📌 Where is it used in real life?

✅ Audiobooks & articles 📚
✅ Voiceovers for videos & ads 🎬
✅ Accessibility for visually impaired users 👀
✅ Smart voice assistants 💁‍♀️

💡 IT Girl Tip:

Got a YouTube channel or TikTok? Polly can voiceover your scripts automatically. Total time-saver. 🔥

4. Amazon Rekognition - AI for Facial & Object Detection

💡 What is it?

Amazon Rekognition is an AI system that analyzes images and videos to detect people, objects, and even emotions!

💖 How does it work?

✔️ Recognizes faces and objects.
✔️ Detects human emotions.
✔️ Can analyze live video streams.

📌 Where is it used in real life?

✅ Security - surveillance cameras automatically recognize faces.
✅ Content moderation - filters out inappropriate images.
✅ Marketing analytics - studies customer reactions to ads.

💡 IT Girl Tip:

Working in cybersecurity or UX design, darling? Rekognition can automate your visual content analysis for you.

5. Amazon Textract - AI-Powered Document Scanning

💡 What is it?

Amazon Textract extracts text, tables, and forms from scanned documents and images.

📌 Where is it used in real life?

✅ Finance - analyzing invoices & receipts.
✅ Healthcare - digitizing medical records.
✅ Legal - automating document review.

💡 IT Girl Tip:

Drowning in a pile of paperwork? Textract turns the whole stack into searchable digital data. Bless.

6. Amazon Translate - AI-Powered Language Translator

💡 What is it?

Amazon Translate is AWS's AI-powered translation tool that translates text in real time.

📌 Where is it used in real life?

✅ Website & app localization.
✅ Business document translation.
✅ Social media & comment analysis.

💡 IT Girl Tip:

Need to quickly translate a big chunk of text? Amazon Translate handles it in seconds. Not minutes. Seconds.

7. Amazon Transcribe - Automatic Speech-to-Text

💡 What is it?

Amazon Transcribe turns spoken words into text automatically!

📌 Where is it used in real life?

✅ Subtitles for videos 🎬
✅ Lecture & interview transcriptions 🎤

💡 IT Girl Tip:

If you're a blogger, journalist, or student, this one is a must-have. Trust me.

8. Amazon Kendra - The AI-Powered Search Engine

💡 What is it?

Picture Google, but pointed at your company's internal files. That's Amazon Kendra. It helps businesses quickly find documents, reports, and emails.

📌 Where is it used in real life?

✅ Corporate search - fast retrieval of policies, reports, and knowledge base articles.
✅ Customer support - quickly pulls up relevant FAQs.

💡 IT Girl Tip:

Buried under a lot of PDFs & reports? Kendra automates searching & organizing so you don't have to.

9. Amazon Comprehend - AI-Powered Text Analysis

💡 What is it?

Amazon Comprehend reads and understands text like a human. It picks up on emotions, key topics, and the relationships between words.

📌 Where is it used in real life?

✅ Customer sentiment analysis - understand what users feel about a product.
✅ Social media monitoring - track trends & user reactions.

💡 IT Girl Tip:

This one's perfect if you live in customer reviews, social media comments, or support tickets. 🚀

💖 And that's the tour! You now know everything about AWS AI/ML.

💕 So which service are you most excited to try? 🤩💻

Mastering archive_file in Terraform Like a Pro

Tatiana Mikhaleva (devops.pink) — Thu, 27 Feb 2025 00:00:00 GMT

Hey friends! 💅 So if you're as obsessed with Terraform as I am (because who doesn't love automating infrastructure the chic way?!), you NEED to meet the archive_file data source. Think of it as your bestie for packaging files into ZIP or TAR. Deployments get effortless. No more manual zipping, sis—Terraform handles it. 😍

Below: what archive_file actually is, how to build archives from one file or a whole pile of them, and the troubleshooting bits. Because tech gets moody sometimes. 🙄

What is `archive_file` in Terraform?

Picture archive_file as the glam squad for your code. It grabs your files and bundles them into tidy little ZIP or TAR packages. Super handy for:

✨ Deploying AWS Lambda functions (which require zipped code!) ✨ Packaging Kubernetes manifests or Helm charts ✨ Bundling files before uploading to S3, Azure Storage, or Google Cloud Storage

Setup looks like this:

data "archive_file" "example" {
  type        = "zip"              # Options: zip, tar, tgz
  source_dir  = "path/to/source"   # Directory to compress
  output_path = "path/to/output.zip" # Destination of the archive
}

Working with just one file? Then:

data "archive_file" "example_file" {
  type        = "zip"
  source_file = "path/to/file.txt"
  output_path = "path/to/output.zip"
}

💡 Pro Tip: Use source_dir for entire folders and source_file for single files—but NOT both in the same block. Terraform's picky like that. 😉

Creating an Archive from a Single File

Say you need to ZIP up one file. Hello, AWS Lambda deployments! Honestly, it could not be easier:

data "archive_file" "example" {
  type        = "zip"
  source_file = "example.txt"
  output_path = "example.zip"
}

output "archive_checksum" {
  value = data.archive_file.example.output_base64sha256
}

That output_base64sha256 is a SHA-256 checksum, so you know your file stayed intact. You don't need it. But it's a cute little sanity check. ✅

Example: Zipping a Python Script for AWS Lambda

Picture this: you've got lambda_function.py and it needs to land on AWS Lambda.

data "archive_file" "lambda_zip" {
  type        = "zip"
  source_file = "lambda_function.py"
  output_path = "lambda_function.zip"
}

Then wire it into your Lambda function:

resource "aws_lambda_function" "my_lambda" {
  function_name    = "my_lambda_function"
  role             = aws_iam_role.lambda_role.arn
  runtime          = "python3.8"
  handler          = "lambda_function.lambda_handler"

  filename         = data.archive_file.lambda_zip.output_path
  source_code_hash = data.archive_file.lambda_zip.output_base64sha256
}

✨ Heads up! Got dependencies? Then zip the whole folder, not just the script.

Creating Archives from Multiple Files

Okay so, I really wish Terraform let us list multiple files outright. It won't. Total diva. 👀 The workaround is to gather everything into a temp folder first:

resource "terraform_data" "prepare_files" {
  provisioner "local-exec" {
    command = <<EOT
mkdir -p temp_folder
cp ${path.module}/file1.txt temp_folder/
cp ${path.module}/file2.txt temp_folder/
cp ${path.module}/file3.txt temp_folder/
EOT
  }
}

data "archive_file" "multiple_files" {
  type        = "zip"
  source_dir  = "${path.module}/temp_folder"
  output_path = "${path.module}/multiple_files.zip"
  depends_on  = [terraform_data.prepare_files]
}

Just want a whole directory archived? Easy:

data "archive_file" "example" {
  type        = "zip"
  source_dir  = "${path.module}/my_folder"
  output_path = "${path.module}/example.zip"
}

Uploading an Archive to Azure Storage

For my Azure girls 💙, here's how to squish a folder and drop it into an Azure Storage Blob:

data "archive_file" "app_package" {
  type        = "zip"
  source_dir  = "${path.module}/my_app_folder"
  output_path = "${path.module}/app_package.zip"
}

Then spin up a storage account and push it:

resource "azurerm_storage_blob" "example" {
  name                   = "app_package.zip"
  storage_account_name   = azurerm_storage_account.example.name
  storage_container_name = azurerm_storage_container.example.name
  type                   = "Block"
  source                 = data.archive_file.app_package.output_path

  depends_on = [data.archive_file.app_package]
}

Troubleshooting archive_file Issues

Terraform acting up? Queen, take a breath. Here's how to fix the usual archive_file headaches:

1️⃣ Incorrect Source Path → Check your file paths! Use ${path.module} to avoid mistakes.
2️⃣ Missing zip Utility → Terraform needs zip installed. Fix it with:

Linux: sudo apt install zip
macOS: brew install zip
Windows: Ensure zip.exe is in your PATH.

3️⃣ Files Not Updating? → Terraform won't detect changes inside source_dir. Use filemd5() like this:

output "archive_hash" {
  value = filemd5(data.archive_file.example.output_path)
}

4️⃣ Permission Issues → If AWS Lambda or Docker throws permission errors, chmod your files before zipping:

chmod +x my_script.sh

5️⃣ Wrong Paths in Modules → Always use ${path.module}, not ${path.root}!

Key Takeaways

💖 archive_file is a Terraform essential for packaging files before deployment.
💖 Use source_file for one file and source_dir for entire folders.
💖 Troubleshoot common issues with paths, permissions, and missing utilities.

Terraform is fun (and powerful), so go forth and automate like the IT queen you are! 👩‍💻✨

DevOps for IT Girls - Deploying Like a Queen

Tatiana Mikhaleva (devops.pink) — Thu, 09 Jan 2025 00:00:00 GMT

Hey, tech beauties! 💖

DevOps gets a bad rap. People hear the word and picture something dry and complicated, and honestly? You've never had it explained the right way! I like to think of it as the ultimate self-care routine for your code. You write it, you ship it, and you keep it glowing once it's out there in the world.

So that's what we're doing today. The whole DevOps cycle, start to finish, in a way that's easy, fun, and totally girl-coded. And our example is one we all get: skincare & beauty!

Step 1: You Have an Idea, Now What?

Picture this. You want to build a smart skincare recommendation app. You punch in your skin type, your age, the season, and boom: it hands you the perfect routine. Genius, right?

So you open VS Code. A few hours later (we don't sleep, we debug 🛠️), it works! 🎉

But here's the thing. Only you can see it right now. How do we get it out to the world?

Step 2: Packaging It Up (Docker)

First DevOps rule, and it's a big one: Just because it works on your laptop doesn't mean it'll work anywhere else.

Think of your code like skincare products. When you travel, you don't just toss your creams and serums and SPF loose into a suitcase. You'd never. You pack them neatly in a travel bag so nothing leaks and everything's easy to find.

That's Docker, basically. It does the same thing for your app:

✅ Packs your code and all dependencies together
✅ Ensures it runs the same way anywhere—your laptop, a server, or the cloud
✅ Eliminates the “but it works on my machine!” excuse

Wherever your app goes now, it's ready to glow ✨.

Step 3: Setting Up the Right Space (Terraform)

Your app is tucked into its cute little Docker container. Lovely. But where does it actually run? You need a server.

Enter Terraform. If Docker was your travel bag, then Terraform is your perfectly organized vanity shelf, set up exactly the way you like it.

Here's what it handles:

✨ Creating servers automatically (no manual clicking in cloud dashboards)
✨ Ensuring they always have the right settings (memory, CPU, storage)
✨ Making it easy to scale when traffic grows

No more building a server by hand every single time. Terraform does it for you, perfectly, every time.

Step 4: Organizing Everything (Ansible)

So you've got a server. Except it's completely empty. No software, no setup, nothing on it at all. Imagine a brand-new vanity table with not a single product on it.

That's where Ansible struts in.

You know how you've got a list of must-have skincare products? Cleanser, moisturizer, SPF, serum. And you arrange them in the same order every time so everything's right where you expect it.

Ansible does that for your server:

✅ Installs all the software it needs (Docker, libraries, tools)
✅ Configures everything automatically
✅ Makes sure every new server is set up exactly the same way

Step 5: Automating Updates (CI/CD)

Say you want to add a feature. Your app now suggests skincare based on the weather, because come on, your winter routine and your summer routine are not the same thing.

But updating the app by hand every time you tweak something? Girl, no.

This is the whole point of CI/CD (Continuous Integration / Continuous Deployment):

✅ You push your new code to GitHub
✅ CI/CD tools (GitHub Actions, GitLab CI/CD, Jenkins) automatically test, build, and deploy it
✅ Your app updates without you lifting a finger

It's a beauty subscription box for your code. New products land at your door every month and you never have to reorder.

Step 6: Monitoring Performance (Prometheus & Grafana)

Your app is live! But is it actually running smoothly? How would you even know?

Say hi to Prometheus & Grafana, your app's skincare tracker.

💖 Prometheus collects data (server health, errors, traffic, performance)
💖 Grafana turns it into beautiful dashboards & alerts

Tracking your skincare tells you when to hydrate more or swap a product. Monitoring works the same way. It helps prevent app crashes before users even notice a thing.

The Full DevOps Cycle, Beauty Edition

Okay, let's pull it all together:

1️⃣ Write the code 🖥️ (find your perfect skincare routine)
2️⃣ Package it in Docker 👜 (store products in a beauty bag for easy travel)
3️⃣ Deploy infrastructure with Terraform 📦 (set up a perfectly organized vanity shelf)
4️⃣ Set up servers with Ansible 🔧 (arrange your skincare in the right order)
5️⃣ Automate updates with CI/CD 🚀 (subscribe to beauty boxes so you always get the latest products)
6️⃣ Monitor everything with Prometheus & Grafana 📊 (track your skincare results and adjust as needed)

And just like that, your app deploys automatically, scales smoothly, and never crashes unexpectedly. That, my loves, is glow-up engineering! ✨

Final DevOps Girl Tips

📌 Learn step by step: Start with Docker. Then CI/CD. Then Kubernetes. You don't have to learn it all in one day, I promise.

⚡ Automate everything: Less manual work means more time for innovation (or coffee & skincare 💅).

🔥 Stay updated: DevOps never sits still, so follow IT girl bloggers, Twitter devs, and tech conferences to stay ahead.

And the big one? Don't be afraid! DevOps isn't scary. It's just a well-organized self-care routine for your apps. 😉

Now go out there and deploy like a queen! 👑💻✨

Top Machine Learning YouTube Courses to Fuel Your Tech Passion

Tatiana Mikhaleva (devops.pink) — Sun, 05 May 2024 00:00:00 GMT

Hey there, code cuties! 🌟 Okay, this post is close to my heart. It's my running list of the Machine Learning and Deep Learning courses on YouTube that I actually keep coming back to. 🌟 Total newbie? Seasoned pro who wants to shake up the skill set? Either way, I picked playlists that'll keep your tech game on point. Let's go! ✨

Foundational Machine Learning Courses

Starting Strong: Kick off your journey with the Introduction to Machine Learning (Tübingen). Think of it as the beginner's bible. Regression, classification, and a whole lot of aha! moments. 🤓
Go Deep on Data: Now get cozy with Statistical Machine Learning (Tübingen). This one cracks open the secrets behind algorithms and learning paradigms. 🔍
Master the Basics: Machine Learning Lecture (Stefan Harmeling) takes you from Bayes' rule all the way to Gaussian Processes. Absolute gold, sis! 🌟
Full Spectrum Learning: The Caltech CS156: Learning from Data course is a gem. It runs the gamut, basics through support vector machines, and you'll be amazed. 📚
Hands-On Hero: Love getting your hands dirty? Applied Machine Learning digs into the nitty-gritty of optimization and regularization. Practical magic. ✨

Deep Learning Exploration

Beginner's Luck: Start your deep learning quest with Introduction to Deep Learning (MIT). It's perfect for babes just stepping into the scene. 🚀
Technique Treasure Trove: The Deep Learning: CS 182 course has you mastering everything from error analysis to imitation learning. Go unlock that potential. 🔑
Nerd Out with Neural: Dive deep with Neural Networks: Zero to Hero by Andrej Karpathy. Honestly, it's your backstage pass to the whole neural network show. 🎬
Creativity Meets AI: Want to see how AI reshapes art? MIT: Deep Learning for Art, Aesthetics, and Creativity is where your inner artist and your inner coder finally meet. 🎨
Unsupervised Learning Adventures: Curious what hides behind the data? Deep Unsupervised Learning will pull you right into the mystery. 🕵️‍♀️

Specialized Courses in Machine Learning

Healing with AI: MIT 6.S897: Machine Learning for Healthcare (2019) blends ML with medicine. Tech meets tender loving care, basically. 💉
Graph Gurus: Feeling graph-tastic? Machine Learning with Graphs (Stanford) walks from PageRank to graph neural networks. A must for data divas. 📈
Talk the AI Talk: Jump into CS224N: Natural Language Processing with Deep Learning. You'll learn to teach machines to actually understand us. Finally, a tech that gets you. 💬

Practical and Real-World Applications

Language Model Love: Build something real with LLMOps: Building Real-World Applications With Large Language Models. Bring your code to life, queen. 🌐
From Lab to Fab: Full Stack Deep Learning carries you from model training all the way to deployment. Let's get those models runway-ready. 💻

Exploring Computer Vision and Reinforcement Learning

See the Vision: Stanford's CS231N: Convolutional Neural Networks for Visual Recognition is your spot for reading trends and tech in visual data. 👁️
Decision Day: Want to know how AI makes up its mind? Reinforcement Learning (Polytechnique Montreal, Fall 2021) is all about making smart choices. 🎲

So there it is, darling. Your dream guide to going full tech queen. Just starting out or leveling up, these courses are your golden tickets in. Let's own this, one algorithm at a time! 💖