The Container You Cannot Configure
A product whose entire interface is a YAML document, shipped in an image that document cannot enter - plus the resilience inventory of a gateway with retries and nothing else.
Newest first, grouped by year. Search or filter by topic.
A product whose entire interface is a YAML document, shipped in an image that document cannot enter - plus the resilience inventory of a gateway with retries and nothing else.
Running Trill as microservices takes eighteen containers and twenty-two published ports; running the same product as a monolith takes mongo, redis and dotnet run - and only the monolith still starts from a clean clone.
Pacco's umbrella repository contains no code, yet it decides everything about how the estate actually runs - seven compose files in deliberate layers, two PM2 manifests that quietly forget the saga service, a 460-line docker run-book, and a .rest file that is the best onboarding document in the system.
Thirteen repositories, one umbrella that runs twelve of them, two interchangeable API gateways and a service that watches everything - the Pacco estate read as a system of systems, and the fifteen-part series it earns.
DShop.Api ships three Dockerfiles - plain, multistage, and multistage.advanced - as a teaching ladder. The top rung is broken, and all three share an ENTRYPOINT that quietly defeats graceful shutdown.
DShop puts all its authorization at the gateway and none in the services behind it - then publishes every service port to the host. The compose file quietly defeats the entire security model.
DevMentors built the same e-commerce shop twice - once as a monolith, once as nine services - with two gateways and two frontends. This series reads the whole estate as one artefact.
Nine DShop services share one skeleton stamped out by hand - and the places they quietly disagree teach more than the places they match. A drift catalogue read from the real source. Part 2 of Nine Services and a Message Bus.
Three toy services, ten infrastructure containers. Reading Convey's docker-compose stack as the honest bill of the chassis: what each container is for, which volumes actually persist, the per-OS variants, and what I would cut in 2026.
KC Star's dev stack stands up PostgreSQL and SQL Server with the schema auto-loaded through V4, pgAdmin pre-wired to the servers, and one command to a working warehouse. Here is how the compose file, the init scripts, and the pgAdmin auto-registration fit together.
FeedR ships three ways to run its six services - pm2, Project Tye, and a deliberately split pair of docker compose files - plus per-service Dockerfiles and an environment-keyed configuration layer that lets the same build run on localhost and inside a compose network. Part 10 of the FeedR deep dive.