From Familiarity to Innovation: Navigating Our Artifactory Dilemma

Approximately four years ago, we, the Infrastructure team at <a href="https://www.prodigygame.com/main-en/" rel="noopener ugc nofollow" target="_blank">Prodigy Education</a>, moved from <a href="https://aws.amazon.com/ecr/" rel="noopener ugc nofollow" target="_blank">Amazon ECR</a> to <a href="https://jfrog.com/artifactory/" rel="noopener ugc nofollow" target="_blank">JFrog Artifactory</a>. This move was made not only for our <a href="https://docs.docker.com/registry/" rel="noopener ugc nofollow" target="_blank">Docker registry</a> at the time but also for <a href="https://www.npmjs.com/" rel="noopener ugc nofollow" target="_blank">npm</a>, as it only made sense to consolidate the registries on one host. Today, we are looking at possibly moving off of JFrog for reasons I’ll mention later, and one of the options we considered for our Docker container images, and helm charts was returning to Amazon ECR. <h1>A Little Bit of History</h1> Five years ago, we were a development and engineering team that was growing fast. We relied on hosted npm for our managed packages, but it was configured there in a way that was not sustainable for the growth we were experiencing. At the time, we used Amazon ECR for our container registry, and like npm, we had a sub-optimal setup. For one, we had a registry in each of our AWS accounts (Development, Pre-Production, and Production) with a build pipeline in each account, so there was no guarantee of consistency between images between accounts. Our solution would be to consolidate our Docker registries into a centralized registry. At the time, ECR did not provide a cross-account mechanism that was easy to manage. <a href="https://medium.com/prodigy-engineering/why-we-have-decided-not-to-migrate-back-to-ecr-6224f30dced4">Visit Now</a>