Why is build size such a concern?

I often hear (from people, but also from informative CLIs) that the "build/slug size is large". This is particularly so when the build is 0.5 - 2 GB in size

Why (or under what circumstances) is build size such a concern?

Note: the reason I ask is because I see resources like storage and compute as being relatively cheap compared to in the past, so, if anything, I would expect build size to be less of an issue now than in the past

When I raise build size issue as a concern, it usually doesn't come from "it is so big, it will be expensive to store it".

The main problems with large builds are the following -

• increased shipping time. moving big bits from place to place frequently is time consuming.

• frequent changes to big artifacts plus a large enoug retention period make storing such artifacts become costly, less so with layered artifacts like docker images.

• creating such big artifacts usually is time consuming, more so than creating much smaller artifacts. automating the process to create smaller artifacts might take time, but the automation that is repeatable should be as short as possible to allow for fast feedback.

• recovering from failure (depending on configuration) might take more time with larger artifacts, especially when an older artifact needs to be reapplied instead of a faulty new-er one.

I subscribe to the four devops metrics:

• Lead time for changes - shorten it

• Deployment frequency - increase the frequency

• Time to restore service - shorten it

• Change failure rate - reduce it to never

Large artifacts usually create a problem in each of these metrics, and none of these metrics are really concerned with the cost of storage really - because that is cheap, time is expensive.

StackExchange DevOps Q#6398, answer score: 11