Leadership
Best practice has an expiry date
Microservices were mandatory in 2016 and apologized for by 2023. An essay on why engineering wisdom decays, and how to date a practice before adopting it.
Code, Noted3 min readLeadership
In 2016, proposing a monolith at a conference was a provocation. By 2023, one of the most-shared engineering posts of the year was a streaming team explaining that consolidating their microservices cut costs by 90 percent, and the ovation was general. Nothing about distributed systems changed in those seven years. What changed is the thing this essay is about: best practices have half-lives, and the industry persistently mistakes them for laws.

Begin by being fair to the practice, because the decay story is usually told as farce and it was not. When the microservices essay codified the pattern in 2014, it described real firms solving a real problem: organizations of thousands of engineers whose monoliths had become deployment bottlenecks, whose teams tripped over each other in one codebase, and whose scale justified the overhead the pattern demands. For them, the trade was sound. The context was the load-bearing part. The context did not fit in a conference talk.
This is the general mechanism of decay, and it is worth stating precisely. A practice is a solution plus its context. The solution travels: it fits in a blog post, a talk, a consultant's deck. The context does not travel; it stays home with the organization that had the problem. So the practice arrives at its adopters as an answer with the question removed, and each adoption further from the original context degrades it, until a five-person startup is running forty services because Netflix, who had the problem, told a conference, who did not, how they solved it. The practice did not fail. It was applied to a question nobody had asked it.

The decay has a second driver, less discussed because it is about incentives. A practice at its peak is a hiring signal, a promotion narrative and a vendor market, and all three constituencies profit from extending its dominion past its context. Résumés said "microservices" because job posts did; job posts did because architects did; architects did, in some part, because a migration is a legible achievement and "we left it alone, correctly" is not. None of this is dishonest. It is drift, applied by a thousand small career gradients, and it is why practices overshoot their applicability by years rather than months.
So the pendulum swings, and the industry narrates each swing as enlightenment. Distribution to consolidation, NoSQL to Postgres, the datacenter to the cloud and, in the repatriation discourse of recent years, some measured distance back. The swings are real information badly encoded: each one marks the boundary where a practice's context ran out, discovered empirically, expensively, by the adopters furthest from the original problem.
Can an organization do better than riding the pendulum? Three habits help, and none requires genius.
Date the practice. Ask, of any recommended pattern: whose problem did this solve, in what year, at what scale? If the answer is "a 2014 problem at a thousand-engineer company", and you are neither, the practice is not wrong but it is foreign, and foreign practices pay an import duty of proof. The question takes five minutes and would have saved the industry a decade of distributed-systems tuition.
Look for the boring cohort. Every hype cycle has a quiet population that evaluated the practice and declined, and their reasons are the cheapest research available. They rarely publish, which is itself the lesson: absence of blog posts is not absence of wisdom. Find them at the unfashionable conferences, running the systems that never page anyone.
And retire practices deliberately. Adoption gets ceremonies: pilots, platforms, announcements. Retirement happens by embarrassment, silently, leaving half-migrated estates as sediment. An architecture group that reviews its standing recommendations annually, asking "does our context still match this practice's context", converts the pendulum into a dial, which is the entire ambition of engineering management stated in one clause.
The half-life, to be clear, never reaches zero. Monoliths were never bad; microservices were never bad; each is a fit between a solution and a situation, and the fit is the practice. The industry's actual best practice, the only one observed to survive every cycle intact, is the unglamorous sentence at the bottom of the 2014 essay that nobody tweeted: it depends, and knowing on what is the job.