Session · Tegal Dev Tech Talk
DevOps Jargon Explained: A Clear and Concise Breakdown
DevOps has a vocabulary problem. Newcomers hit a wall of terms that all sound adjacent and mean specific things. This session took the jargon apart and put it back together in plain language.
Overview
Tegal Dev is an Indonesian developer community. This Tech Talk ran on their Discord server on Saturday 1 February 2025 at 20:00 WIB, co-presented with Wisnu Yumna Y from the Tegal Dev core team, with PurwokertoDev, Web Programming UNPAS and Meetap as media partners.
I opened with my own route in, because it makes the point better than a definition does: I started in IT support and actively disliked coding. A data-centre job suited me, I liked machines more than people. Then the first AWS event in Indonesia showed me cloud work could be done remotely, a previous boss offered a raise if I'd start coding, and DevOps turned out to be a field with far more demand than qualified engineers. Ops (2018 to 2022), DevOps (2022 to 2024), SRE from 2025. Nobody on that path starts by understanding the vocabulary.
Key Takeaway
- "DevOps Engineer" isn't really a job, DevOps is a culture.
The title exists because companies need something to put on a req, but what's being described is a way of working across Dev and Ops, not a separate role bolted between them. - The vocabulary is a barrier, not the substance.
Once containers, pipelines, IaC, and observability are explained in plain terms, what's left is a small set of ideas: automate the repetitive, shorten the feedback loop, make it reproducible. - A concrete starter pack beats a roadmap.
Pick one major cloud and go deep, learn Docker + Linux + Kubernetes, pick one high-level language, understand the CI/CD paradigm, learn Terraform, and default to automation first.
Summary
Three parts, moving from where the word came from, to the principles, to the terminology people actually trip over.
-
Where DevOps came from
The origin story, because it explains the gap DevOps exists to close. Patrick Debois noticed in 2007 that Agile still left Dev and Ops separated. In 2008 he turned up to an "Agile Infrastructure" session at the Agile Conference in Canada that Andrew Clay Shafer had proposed, and was the only attendee, Shafer himself not having shown. He tracked Shafer down anyway. In 2009, after watching Paul Hammond and John Allspaw's "10+ Deploys a Day: Dev and Ops Cooperation at Flickr", he organised the first DevOpsDays that October.
-
The Three Ways
From The DevOps Handbook. Systems Thinking: treat the system as one thing, not silos, the only goal is delivering to the customer, engineering ego doesn't matter, and CI/CD exists to make the process visible. Amplify Feedback Loops: fast feedback beats perfect feedback, fail fast to succeed faster, shift left, define compliance and test cases explicitly. Culture of Continual Learning: iteration is a prerequisite to mastery, tech debt has to be paid, and, the line that got the most reaction, don't wait for it to break before you touch it. Wrapped up with CALMS: Culture, Automation, Lean, Measurement, Sharing.
-
The terminology, unpacked
Containers via an analogy that sticks: the artifact is the goods, the container is the packaged goods, orchestration is the logistics company, and the artifact registry is the hub warehouse. Then automation (anything can be automated, everything should be, because machine error is predictable and human error isn't), CI/CD pipelines, Infrastructure as Code ("what you write is what you get"), and observability. Closed on what the job is actually measured by: DORA metrics, deployment frequency and lead time for change on the throughput side, change failure rate and MTTR on the stability side, plus the DevOps and Observability maturity models.