7 ms·

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 har

by orf 7y ago

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.

hansvm 7y ago
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.
- adgud 7y ago
  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.
jcagalawan 7y ago
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.
rumanator 7y ago
> 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.

by orf 7y ago

hansvm 7y ago

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.

adgud 7y ago
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.

jcagalawan 7y ago

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.

rumanator 7y ago

> 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.