The click of a Friday night
Last Friday evening, I seriously got started on Kubernetes. A kubeadm lab on a bare metal server, docs, blog posts, including one that generated Factorio maps on the fly to follow a game on a server.
The kind of project that would have kept me awake until 4 a.m. thirty years ago. And yet, late the next afternoon, something obvious jumped out at me: this whole chain of configuration files and commands to type is no longer for me.
Thirty years of configuration files
I started in 1997. Since then, I have edited hundreds of configuration files on Linux, Solaris, OpenSolaris, FreeBSD and OpenBSD. I cobbled together Makefiles to compile all the programs I found left and right.
There was Apache, Nginx, Caddy, MySQL, PostgreSQL, RabbitMq, Kafka, ElasticSearch, CouchDB, Bind, Sendmail, BEA WebLogic, IBM WebSphere, Lotus Domino, Oracle RAC, Sun Cluster, … And so many others.
I devoured documentation, filled kilometers of notes and wrote just as many procedures. I am not complaining: I loved every minute. But at 48, my heart is no longer in it.
Saturation, not wear
My first reaction was to tell myself: “I have outgrown this.” Thinking it over, that is not quite it.
Kubernetes, for someone who has done Sun Cluster, Jumpstart and Oracle RAC, is not a discovery. It is yet another implementation of the same ideas: declarative, reconciliation, high availability, orchestration. With a new syntax, and much more YAML.
At 18, the pleasure came from understanding how things work. Today, I already know. Only the mechanical part remains, and that is what bores me. It is not wear, it is accumulated experience: I have seen three cycles of this kind of tool go by.
AI did not light the fire, it revealed it
I liked to believe that it was the arrival of AI in our daily lives that had lit this fire of anxiety and uncertainty. It is not innocent, but it is not the cause.
What AI automates is precisely the part that no longer interests me: writing the manifests, the playbooks, the configurations. What it does not automate is judgment. Knowing when a technology is a bad idea, what an architecture will really cost in two years, how a cluster will behave during a network incident at 3 a.m.
My discomfort and my value ultimately point in the same direction.
Becoming techno-pragmatic
While looking for how to put all this into words, I came across a term I like a lot: “techno-pragmatic”. I am making it my own.
In concrete terms, it is the end of the wars between camps. I am not letting go of mastery of the technologies I practice, but I forbid myself from locking myself into one camp. One day, I will recommend a managed Kubernetes provider to run models and AI tools. Another day, I will choose serverless at Cloudflare interfaced with a conversational agent like Grok Bot.
The criterion is no longer the tool I like, but the problem to solve, its cost and the person who will have to operate it after me.
Digital sovereignty remains a subject close to my heart. But I no longer want it to be an exclusive lens that decides in my place.
What now?
Knowing where you come from is essential to chart your path. Looking behind you all the time, on the other hand, is a waste of time and energy. So I am turning this page without regret.
The next one, I want to write it around what thirty years in the field have really taught me: arbitrate, simplify, and own the consequences of a choice in production. I want this experience to be recognized, including financially, in the years to come.
I have not outgrown the job. I have only outgrown YAML.