I feel like he jumped into “hard” optimisation too fast.

I would say when you find code running slow, first you do:

• only do nessesarry work, if we only need to look up a persons name we do not need to load all and everything and their image for that person from a DB, File or alike (fewer calls)

• dont do the same work twice, if you already calculated something you might not need to calculate it twice (example: caching)

then if perfromance is still an issue, do what he suggests in the article :)

For me(programmer) it usually depends on the upgrade.

The system I am working on contains like 5-10 containers (depending on customer needs).

In generel I try to have as few connections between services as possible, Low Coupling, High Cohesion. No 2 containers share a database scheme, because that makea database updates way more difficult. The 2 services have to talk to each other through a welldefined API which can be versioned.

1. Application bugfix Sending out a bugfix usually only effects the actions of a single container. Then we upload the new docker image to the server, shuts down the old instance and start the new container, but reuses all the settings of the old container. This does result in like 10-20 seconds downtime, which is completly acceptable in my case.

2. Application feature When we implement a big new feature we usually also needs to update the database (new tables/columns). First take a backup of the database before the upgrade. Then like with the bugfix upload and start the new container. In our case we have the application push out the database update (C# dotnet EF core). If it is an even bigger update we may have multiple docker containers that is upgraded at the same time.

3. Database version upgrade We check the release note for the specific database on how to upgrade it, and follow those steps.

4. Other utility containers (Nginx, Elastic search, …) Same as database, check the release note for breaking changes to make sure the upgrade goes well.

Always always always make sure to test the update in a controlled environment that resembles the production environemnt as closely as possible. (maybe even a copy of production if I am lucky)