The point I was making is why the following snippet doesn't make your image smaller _is the basics_:

> RUN echo something > some_file

> RUN rm some_file

Neglecting to even mention it leads to issues down the line because people don't get the fundamentals. There are a lot more confusing things than this when working with Docker.

Small images is one component of optimizing a container. I disagree that a small image is fundamental. In fact I’d say it’s largely a small optimization detail that has very little real world impact.

Really nobody really cares about container sizes except for their own efficiency. We run thousands of containers. Many of them tens of GB. They could all be optimized to a small size but it really doesn’t matter and is not worth the engineering time most of the time.

It's not necessary about the size, and nor is it always a premature/useless optimization. It's about knowing how layers interact which is important. And not hard to teach either.

And yes, if you're adding 5+ GB to each image build through something silly like a 'RUN chown' it's worth fixing. Maybe not complex refactoring, sure, but we are talking about the basics here.

I think their point is that for most use cases, large images don't have a sizeable real world impact. They're more expensive to move around, and you can only fit so many large, distinct layers on a single machine, but a moderately sized organization will barely notice the cost.

They do have a sizeable real world impact. Moderately sized organizations usually build and store the images in a public cloud, which in turn do not provide any straightforward registry cleaning capabilities (at least I didn't find any in AWS or GCP). This leads to hundreds and thousands of gigabytes being wasted and money being flushed down the drain. Not to mention that network traffic in public clouds can quickly rack up the bill as well.

This Docker and Kubernetes hype and the fact that few people understand and care to implement these technologies correctly fills Amazon's and Google's pockets with money that could be spent elsewhere.

> It's not necessary about the size, and nor is it always a premature/useless optimization. It's about knowing how layers interact which is important. And not hard to teach either.

Learning layers is not critical to get up and running with Docker. You can learn it easily afterwards, but on the very first introduction it's just unnecessary cruft that distracts you from your goal.

More importantly, you can actually use Docker in daily practical applications your whole life not caring about layers. Think about it: why should you care about layers if you don't care about build size or build time?

At this stage, caring for layers is just premature optimization.

It’s like having a “What is sorting?” article with bubblesort as the algorithm of focus. It’s easy to explain and answers the question. Yes, time complexity is fundamental to designing algorithms but it’s not something necessary for an introductory article.