Why is build size such a concern?

Question

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

Answer 1

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.

Answer 2

Complementing Evgeny's answer with a few more examples.

What you mean by build size may matter a bit:

• if it is the size of the artifact(s) being built (each one individually or their combined size) - that could matter in artifact storing or use/deployment operations if those operations have size limits and they are exceeded. For example Google App Engine apps has such deployment limits, if reached deployments would fail, see Error when deploying to Google App Engine.

• if it is the size of the workspace in which you perform the build it may matter from the workspace management perspective. Even 2G may be significant - for example if you're building in a RAM filesystem on a machine with not a lot of RAM. But some builds could a lot bigger - I had to deal with 500G+ workspaces (when most of my server disks were below 1T).

If the build is part of your CI/CD pipeline then the larger the build size the longer will the pipeline execution time be (performing the actual build and, if applicable, archiving, deploying for testing, analyzing in case of failure, cleaning up, etc.) - the slower/riskier/costlier your overall development may be.

If you hit a hard limit you'll have to get creative to work around it (not always simple/possible). If it's just a performance/cost hit you also have the option of accepting and living with it and/or addressing it partially/gradually.

It may be worthy to distinguish between:

• bloated builds - when size is unnecessarily increased - fixing the problem is usually possible by dropping unnecessary parts
• the cases in which the content of the build itself is what's really needed - the size doesn't matter as much - it is needed, the only way to address may be by sacrificing some functionality

Answer 3

I'll add a very concrete issue that we actually run into. It's a sideeffect of bad architecture that we're suffering currently:

Since our build is large and we need to load a lot of dependencies simply putting it all together takes a very long time. We should have long since divided the build up into numerous small builds as an approach to a microservice architecture instead of one large monolith.

Running all tests for the monolith takes around 45 minutes and blocks our CI environment for the time being.

Since it's so load intensive and takes such a long time it's currently impossible for us to run multiple builds parallel to each other.

So, as posters before me have already stated on a more theoretical level, this should showcase some potential (and likely) side-implications a large build usually has outside of needing more space on the harddrive.