Two hundred and seventy services, and not one of them interesting
Nothing in the catalogue is worth showing at a conference. That is the goal: infrastructure should be made of solved problems.
Walk through the catalogue from top to bottom and the impression is even: monitoring, wikis, an issue tracker, a status page, secrets management, file storage, process automation, queues, databases, reverse proxies.
Not one entry you would want to talk about. That is not a complaint about the catalogue. It is its purpose.
What “boring” means here
An application with no open questions. It is known what it is for, what can replace it, what happens to it in operation, and there is someone to maintain it.
Such applications are not discussed. They are installed and forgotten, and being forgettable is the most valuable property an infrastructure component can have.
Why new and interesting things do not make the set
Because the selection criterion is predictability, not usefulness. An application reaches the status “verified” when its configuration in the catalogue matches the real requirements for running it and when its version is pinned and bundled.
In a young project, versions move, dependencies change, configuration gets renamed. It can beat a mature alternative on features and lose on the one parameter that decides here: reproducibility a year from now.
That does not mean such an application cannot be installed. It means it carries the status “candidate” and an explicit flag at install time.
What boring gives you in practice
Replacement without rewriting. If a service from a mature category has to be swapped, an alternative exists and the move is understood. A unique solution has nothing to be replaced with.
Answers on the internet. A problem that tens of thousands of installations run into is already described. A problem with a unique configuration is described only by you.
Hiring. An engineer joining the project recognises half the set by name.
Where interesting still belongs
In your application. The catalogue covers the supporting layer so that attention and originality go where they create value.
Infrastructure in which every component is an interesting choice consumes that attention entirely. And it consumes it not once, at adoption, but constantly: every non-standard component demands its own knowledge during every incident.
The other side
A catalogue of boring services does not look impressive in a presentation. It should not: what you buy is not a list of names but the fact that the list comes up with one command, reproducibly and with pinned versions.
The only interesting part of such a design is what it lacks: manual steps, links to external repositories at install time, applications with floating versions, and state that is not in the description.