Yevgeniy
Brikman

The Man Who Wrote the Book on Infrastructure - Three Times

There is a moment in every organization's life when someone looks at the server setup and says: "How did it get like this?" Servers configured by hand. State stored in someone's brain. Deployments that feel like dismantling a bomb. Yevgeniy Brikman - known to most of the internet simply as "Jim" - decided that moment should stop repeating itself. He has spent fifteen years building the tools, writing the books, and founding the company to make it stop.

Brikman is the co-founder of Gruntwork, the Phoenix-based DevOps infrastructure company that built an opinionated library of Terraform modules so every startup doesn't have to reinvent AWS from scratch. He is the author of Terraform: Up & Running - now in its third edition and widely regarded as the definitive guide to infrastructure-as-code - plus Hello, Startup (for engineers considering the entrepreneurial leap) and his most ambitious work yet, Fundamentals of DevOps and Software Delivery, published in June 2025.

That fear, Brikman argues, is not irrational - it's a systems problem. And systems problems have solutions. His career has been dedicated to finding them.

From Cornell Webmaster to Infrastructure Philosopher

The story starts at Cornell University, where a kid from Marblehead, Massachusetts arrived in 2002 to study computer science and ended up maintaining the campus website as a student webmaster. That detail is funnier in retrospect than it sounds: the man who would later help define how global-scale infrastructure should be built started by keeping a college homepage running. Foundations first.

He earned his BS in 2005 and a Master of Engineering in 2006, then spent the next decade burning through the playbook at Thomson Financial, Cisco Systems, TripAdvisor, and - most crucially - LinkedIn. That last stop changed everything.

That experience shaped everything that followed. When Brikman left LinkedIn and founded Atomic Squirrel, his first consulting company, he started noticing a pattern: every client needed the same infrastructure. Every engagement began with the same problems. He and his future co-founder Josh Padnick - running his own company called Phoenix DevOps - were solving identical puzzles for different customers, billing hourly for work that was fundamentally the same work.

In 2016, they merged the two companies into Gruntwork. The insight was simple. The execution took years. Today, Gruntwork's library of battle-tested Terraform modules means that a startup can get a world-class AWS setup without spending six months figuring out VPCs.

Three Books. One Argument: Infrastructure Should Work Like Software.

Every book Brikman has written is a different angle on the same thesis: complex technical systems can be reasoned about, tested, and automated - if you treat them like software. Not like black boxes. Not like art. Like software.

The Terraform book deserves special attention. It started as a blog post, became a bestseller, and then did something rare for technical writing: it aged well enough to earn a third edition, each version expanding as the ecosystem expanded around it. Writing a book about an evolving open-source tool and staying authoritative across a decade is harder than it sounds.

The Tools That Outlived the Talks

Books and talks are good. Tools are better. Brikman's GitHub footprint tells a story of someone who builds things because he's frustrated with what exists, not because he's building a portfolio.

The Tension: Pragmatist or Idealist?

Here is the contradiction that makes Brikman interesting: he is simultaneously a rigorous pragmatist and a genuine idealist. The pragmatist writes code, builds tools, packages solutions that actually work in production. The idealist keeps writing about why the whole thing matters - why how you deliver software shapes what you can build, why infrastructure done badly limits every team above it.

His 2022 Medium essay "The Future of Terraform Must Be Open" is Exhibit A. When HashiCorp moved Terraform away from a pure open-source license, Brikman wrote publicly and specifically about what was at stake. He didn't shrug it off as someone else's business problem. He engaged with it as a matter of principle, because he'd built enough on top of that foundation to know what the foundation meant.

That quote tells you more about how Brikman thinks than any biography. He is a connector. He reads widely - not just engineering blogs but product design, hiring practices, startup theory, DevOps research. The DORA metrics he cites in his 2025 book - elite performers deploy 182 times more frequently and recover from failures 2,293 times faster than low performers - aren't cherry-picked data points. They're load-bearing pillars of a coherent argument about what engineering excellence actually looks like at scale.

The fitness analogy he uses in Fundamentals of DevOps is revealing. DevOps mastery, he writes, is like weightlifting: you need the theory, but without reps, the theory means nothing. He is, by his own admission, someone who loves "lifting heavy things." There is something very on-brand about comparing infrastructure automation to progressive overload. Load. Test. Adapt. Repeat.

Two Decades of Building Things That Scale

What He's Actually Building

Gruntwork's stated mission is to make it "10x easier to understand, develop, and deploy software." That's not a marketing line; it's a constraint. Brikman's whole body of work is an attempt to find and remove the friction that slows teams down before they even write their first feature.

The newsletter. The books. The talks at HashiConf and QCon. The Terragrunt tool. The Terratest framework. The blog posts on Medium with 12,400 followers. The open-source GitHub repos that teams fork on day one of a new project. All of it is the same argument, expressed in different media: you shouldn't have to re-solve infrastructure. You should be able to stand on what came before and build something new.

Brikman is not famous in the way that startup founders who raise $200M are famous. He's famous in the way that the engineer whose tool is in your stack is famous - you might not know their name, but you've used their work. The pattern is there in his career: build the thing that removes the problem, share it openly, write the book that explains why, repeat.

He wrote that in Hello, Startup, and it applies to Gruntwork as much as any company. The company is small by design. The output is disproportionate to the headcount. That is, by now, very much on brand.

Ask Jim Brikman what he's working on and he'll tell you about his latest book, his newest Terragrunt feature, or the DORA research he's been citing in talks. He probably won't mention that the tools he's built are in production for hundreds of companies right now, silently handling deployments while those companies' engineers work on the parts that actually matter to their customers.

That's the point. That's always been the point.