|
|
|
|
|
|
by eastbound
1180 days ago
|
|
|
> I shudder to think how much of the dev ecosystem would yet again depend on Microsoft's good graces to shoulder the burden of storage and data transfer costs for building products Does that hint that the model of sending around megabytes-to-multigigabytes of VMs is inherently too expensive to maintain as a backbone for an awesome tool? For the same reason, I wonder why provides Maven Central and NPM repositories, whether they will do it for free, but at least those are billions of small jars, not hundreds of thousands of gigabyte-sized VMs. |
|
|
Yes. I think automated build pipelines running 24x7 that could request even for the oldest version of a sizable image without caching at their end is part of the issue. There was no limit that I'm aware of on the no. of tags/versions per image or per OSS account on DockerHub, so just like package repositories, effectively every image had to be available forever and each image was of significant size. I don't believe storage and network tx costs have reduced at the same rate as increase in adoption of build pipelines and automation.
Same issue exists for apt, NPM, Maven, PyPi, or any other repository, but yes, the storage requirement should be significantly smaller.
Aside: Because Java has been around for so long in enterprises, many have learned over time to set up registries internally - a combination of wanting to host private packages securely on prem and protecting from downtime, supply-chain attacks. JFrog Artifactory is pretty commonly seen. However, IIRC npm registry was not easy to self-host on prem in the early days, and many enterprises had their private packages hosted on npm.