JFrog’s New Artifactory 4.0 Competes with Docker Trusted Registry, CoreOS and Google

JFrog’s Artifactory 4.0 puts the company squarely in the container ecosystem, competing against the Docker Trusted Registry and other services such as those from CoreOS and Google.  The new version of Artifactory keeps copies of containers between registries, meaning that a team can have a dedicated registry where their developers can push and compile new code, along with a QA reg with copies of the container that the development team is working on. This is designed for those who are pushing multiple changes a day, or addressing changes from a recent product patch or client update which may have resulted in a variety of code-breaking bugs.

The new service gives development teams working in a container-based environment with the capability to offer a binary repository management service that builds on JFrog’s longtime place in the market. These include the ability to attach metadata to a registry automatically, a multi-platform system of record, and an API to attach a project’s registry metadata within the Artifactory UI.

Working Smarter, Not Harder

Artifactory improves upon the once tedious and time-consuming process of compiling code cross-platform by reusing as much code as possible. When working in CI, developers need to remember what version of a service they used, and where it was placed within a project. When faced with creating a product that has to run in the same way across multiple platforms, recompiling code quickly becomes an issue when it must be re-written to address a multitude of systems that may be running on the bleeding edge of technology, or far behind the industry standard.

This is a way to re-use IP to some extent. It’s avoiding rebuilds. You go from the source code and then you re-use the component in different environments. Drivers need to be deployed and tested in hundreds of different environments and exact same binary — to go back to source code and recompile it is not an option.

A common pain point when using Docker is the size of Docker images. Some can be over 1 GB in size, which often throttles system performance on VMs or multiple clusters running the same application. Artifactory 4.0 offers developers the opportunity to distribute their application images to data centers based in other regions.

A screenshot of the Artifactory 4.0 UI with Docker

JFrog VP of Marketing Adam Frankl and its co-founder and Chief Architect Fred Simon offered insight as to how Artifactory 4.0 shapes the future of working in containers: Artifactory takes the guesswork out of replicating binaries, offering the ability to compile metadata and tag it for easy searching. Secure access and provisioning of large Docker images were also crucial to the team at JFrog when developing Artifactory 4.0.

As changes are addressed by the development team and compiled within the dedicated developer registry, copies of these containers are created within Artifactory 4.0 to be tested by the QA team to ensure that applied changes are working as intended. These changes are done from within Artifactory, meaning that there is no need to re-image the container — saving valuable resources. Artifactory also can control who can deploy to production, meaning that teams can ensure that all code is secure and verified as working as intended before being pushed live.

The Past, Present and Future of Containers

Before artifact repositories, developers were sticking them in source control, which doesn’t really work. This is because source control does not offer the tools needed to manage multiple registries across platforms. Another precursor to artifact repositories was version controls, which are useful for maintaining source code, but aren’t designed for addressing the needs of those with large binaries to work with. Version control offers limited functionality for managing repositories, especially in regards to the handling of metadata. Without the ability to clearly and quickly determine what a project was built on, its source code, and where it came from, the process of using version controls quickly breaks down as an option for managing binary repositories.

Selecting a package type in Artifactory 4.0

“Version controls don’t scale. They work for one or two files, but not for 1,000 or 10,000. Another option is s3, which still doesn’t allow attaching metadata, binding or security control. S3 also can’t guarantee everyone is seeing the same version at same time,” said Simon.

Moving forward in a container-based workflow means that developers have to be able to access the tools they need when they need them. This includes components from across the developer ecosystem, comprised of both internal and external sources. Artifactory 4.0 will offer users a virtual artifact registry, enabling them to interact with more than just the Docker Hub.

With Artifactory 4.0’s new centralized registry, images are aggregated from across a developer’s community. This means not only will they be able to access the Docker Hub from within Artifactory but will also be able to pull registries from their local environment,  the open source community, their company registry, Google Cloud or Amazon. This streamlines configuration of a new workflow, eliminating the need to cobble together registry sources from different locations.

Launching an application or developing a service for a startup requires developers and QA teams to share, compile, and debug code in environments that may change multiple times a day. Artifactory has been in use since 2009, offering those working on the fringe of container-based workflows to come together and work efficiently cross-platform.

As more developers have begun to learn the role of DevOps and have taken on these skill sets in addition to their own, this has required a more demanding tool for managing repositories, debugging containers, and managing who can access vital pieces of company information.

Artifactory and Docker are designed to compliment one another, to be used in conjunction with other tools in a development workflow. No tool can exist in a vacuum, and Artifactory 4.0 takes working in Docker and improves upon the already streamlined and efficient workflow. Containers are quickly becoming a standard in enterprise-level development, comprised of their own unique sets of risks, challenges and pain points.

There are very few private Docker registries available to address the needs of enterprise-level developers. Those include Quay.io, acquired by CoreOS in 2014; and up until 2013 also included Google. Google’s  2013 announcement changing how it handled binary hosting allowed JFrog a unique opportunity to capitalize on the future of binary repositories. Artifactory registrations rose as a result of Google’s change in terms, paving the way for Artifactory 4.0 to capitalize on a missing piece in a developer’s daily workflow.

With the rise of container-based technology, the needs of a development team to be able to piece together the components that will work for them is crucial to determining the production timeline of an application or service. JFrog looks uniquely positioned to serve the container world’s growing ecosystem.

CoreOS and Docker are sponsors of The New Stack.

Feature image: “Brainstorming” by Fabrizio Cornalba. Licensed under CC BY 2.0.