Controlled operating environments
Ubuntu-based images cut down to what the product actually needs, and the product decisions that follow from that.
Shipping a product on a general-purpose distribution means shipping several hundred packages nobody chose, each with its own update cadence, its own maintainer and its own vulnerability history.
Reducing that image is usually filed under housekeeping. It is not. It is a product decision about robustness, reproducibility, attack surface and how deterministically the thing boots in the field.
Removing things is a design activity
Every service left in the image is a service that can start, fail, consume memory, open a port or need patching. Every package is a dependency you have implicitly accepted. Removing them is not about a smaller number: it is about being able to enumerate what is running and say why.
The bar is that a boot in the field produces the same state every time. An image that mostly boots the same way is an image that will eventually surprise somebody at a customer site.
Reproducibility over convenience
The build has to be reproducible from a definition rather than from a machine somebody configured once. That is slower to set up and it is the difference between a product you can support for years and an artefact you can only rebuild by hand.
It also makes the security story tractable. When the image is a definition, answering what changed between two releases is a diff rather than an investigation.
What I will not publish
The package set, the build definition, the hardware, or the product. Described at a high level under NDA.
Work carried out under NDA. This page describes the engineering, not the employer. No employer names, internal architectures, client details or proprietary systems appear anywhere on this site, and none will be added.