Antonomasia

Antonomasia is a word derived from the Greek ἀντονομάζειν, which means, “to name differently.” It is a rhetoric figure of speech, or metonymy, in which a concept is named after another closely related. Classical examples are, for example “King” for Elvis Presley, or “Fab Four” for The Beatles. In technology, “Xerox” for photocopying, “Big Blue” for IBM, “Google” for searching, but (surprisingly enough) not “iPhone” for smartphone. In the software industry, a similar phenomenon happens: “C++” for object orientation; “Java” for web apps; “Jenkins” for CI/CD; “Python” for machine learning; “Scrum” for Agile; and Kubernetes for DevOps.

DevOps, as a word or as a concept, did not exist 10 years ago: it was born as part of a conference name in 2009. Back then, Android and iOS were still niche players in the mobile industry, Facebook had not yet been acknowledged as an effective threat to democracy, and the Marvel Cinematic Universe consisted of… two movies. A very different world, yet all too similar.

Avid readers of this magazine might remember that in the first issue, published in October 2018, the author of these lines wrote that “Hype spreads like cancer.” The thought is still valid, and DevOps should be studied to find whether it is just a temporary hype, or a fad. But if recent experience is to be believed, DevOps might be the strongest new trend in the software development industry, at least since Agile became a manifesto almost 20 years ago. Where other approaches have failed, DevOps has stayed and spread.

This is a fact. If you are doing DevOps between 2019 and 2020, you are most probably using Kubernetes.

The “container orchestration wars” are over, my general, and Kubernetes won. In any of its incarnations: K3s, OpenShift, Rancher, NetApp, you name it. They all won. Applications became small Docker containers, lightweight virtual machines that can start and stop in a heartbeat. The programming language does not matter anymore. The IDE does not matter anymore. The framework does not matter anymore. The build tool does not matter anymore.

And when I say Kubernetes won, I mean its whole ecosystem: Terraform. Prometheus. Helm. Do not worry if you have never heard these names before. They all come in the same bus as Kubernetes, only in the back seats. They might not be immediately visible. Like Knative back there, texting with Envoy and Fluentd who stayed at home watching TV.

The container matters, and as long as it is exposing an HTTP port, you are on the way to DevOps. It matters so much that IBM bought Red Hat for 34 billion USD.

Kubernetes (a word derived from the same Greek word that begat “Government” and “Cybernetics”) is a beautiful black box, working as a declarative engine; you want a load balancer and three instances of your application running? Kubernetes will watch the state of your system for you, and launch enough “pods” so that you have exactly what you described. Yes, “pods.” An abstraction layer on top of those Docker containers we talked about previously.

Speaking about a description, YAML went from being the humble configuration format used in Ruby on Rails applications, to be the configuration format of deployments, services, ports, storage, and anything composed thereof. Everything is defined in YAML, and that YAML is fed to a command line tool, usually written in Go, so that this everything defined in YAML is “deployed” to the “cloud.” And because Kubernetes is yet another layer of abstraction, it does not matter if you are in AWS, Azure, Google Cloud, or even in Alibaba’s own cloud. Your containers just run™®©. Kubernetes is watching.

Teams then can concentrate on the “descriptive” part of DevOps, and they push their code to a git repository, because who is using Subversion these days, anyway. Your commit wakes your CI/CD system up, who in turn clones the repo, builds the binaries, executes the unit tests, creates and pushes the Docker containers, and deploys a new version of your application to your staging environment a few minutes later. That CI/CD thingy might even send a message on Slack to someone in the testing team, because, who reads e-mails these days, anyway.

This is how, in 2017, DevOps became GitOps and everything was hype again.

Want to push a new version to production? If you are using something like Git Flow, just push to master and your CI/CD system will automatically execute the kubectl command and deploy your code to production. Or if you are using GitLab (who is not these days?) your .gitlab-ci.yml file can trigger a deploy simply after pushing a humble tag.

Deploy to production 20 or 30 times a day? No problem. Still using SFTP to deploy your PHP apps? Poor soul. I hope you are using Semantic Versioning for those tags, though.

Of course, not all developers can be as “DevOpsy” or “GitOpsy” or “DevSecOpsy” as they wish. Mobile developers, a group dear to the heart of this author, still has to juggle with manual deployments (usually via a pitifully broken web interface or IDE.) But if you have to wait for a human to approve your app, why would you want to automate your deployments, anyway?

The closest thing that mobile developers have to Kubernetes (sorry, DevOps) is Fastlane, but then again, one wonders endlessly about the level of automation that mobile apps could reach, if their respective vendors actually cared.

Cover photo by Taylor Vick on Unsplash.

Continue reading Play It Again, Sam or go back to Issue 016: DevOps. Did you like this article? Consider subscribing to our newsletter or contributing to the sustainability of this magazine. Thanks!