The Frog and the Whale

Bintray and Artifactory have now welcomed Docker containers on board, but JFrog co-founder tells us Bintray will remain open to other container solutions that might overcome Docker’s “childhood problems”.

In yet another item of microservice-related news today, the software build and distribution company JFrog announced support for Docker local repositories in JFrog’s DaaS platform, Bintray. Co-founder and CTO Yoav Landman tells about JFrog’s new end-to-end solution for Docker users.

Google, Mirantis, VMware, Microsoft… Tech companies are lining up to collaborate with Docker. Would you agree it has now become a absolute necessity for enterprises to officially engage with Docker?

I agree that looking into containers as a way to provision services in a lightweight manner is an absolute necessity today. Having said that, Docker is definitely a path maker that is leading the market, but I expect other container solutions to surface, perhaps also more mature ones that overcome Docker’s childhood problems. This is only natural and JFrog will support other container image formats.

Given this rapidly growing Docker ecosystem, what potential is there for Bintray’s Docker support that will help it stand out of the crowd?

Docker’s own Docker Hub is limited compared to Bintray. Bintray offers unlimited number of private repositories (limited in Docker Hub), advanced usage stats, strong GitHub integration, guaranteed CDN, including the ability to use Akamai (really important for Docker gigabyte images, and not committed to by Docker’s own hub), and the ability to use your own domain host name and SSL certificate, which is important for establishing customer’s trust.

On top of that, Bintray provide a single platform to automate and manage the distribution of not just Docker, but other ecosystem packages, under the same account.

Can you perhaps give us a sense of how companies like Google, Pivotal, Apache and Netflix have been using Bintray and how they might stand to gain from Docker support?

Sure. These companies use Bintray to track and distribute software to end users, who are mostly developer. They leverage the native packaging support in Bintray to set up repositories such as Debian, Yum (RPM) and Maven repositories, use statistics to analyze the popularity of different software version across different geographical regions, download and analyze the logs, communicate new software releases to users through notifications, etc.

Open source projects like Apache Cassandra, HomeBrew for mac, Android studio dependencies, and more also require a huge amount of bandwidth and a solid, cross data-center, clustered infrastructure to sustain the incredible number of download requests and this is provided by Bintray. For private, non-OSS packages these organizations define secure downloads using repository permissions and use the ability to create signed, expirable URLs that are given to users for download tracking.

The REST API of Bintray also allows building a download center on top of it, which is done by companies like Gradleware, etc.

Artifactory will also get an end-to-end solution for Docker. Can you tell us about this?

Yes. Artifactory offers Docker support for the development phase and for provisioning docker images for local deployments. Setting up a local registry using Artifactory is incredibly straight forward compared with using Docker’s own Docker Registry.

Docker support in Artifactory is on par with the Bintray’s Docker support with the exception that in Bintray, dedicated host names for Docker repos are pre-configured automatically with zero efforts.

Security has long been a big question mark over Docker. Will this be an issue for JFrog users that will now also work with Docker?

Docker security issues are mostly around the Docker engine itself, which is a separate concern to where Docker images are being managed.

SEE ALSO: 5 Docker misconceptions Java developers should consider

Still, with Bintray and Artifactory, the ability to have your own domain and SSL for you Docker cloud repo or to run a local, behind-the-firewall enterprise Docker repo, brings a new degree of security.

Docker critic Cal Leeming recently commented that Docker “adds an intrusive layer of complexity which makes development, troubleshooting and debugging frustratingly difficult”. Would you say Docker makes development more complex, or simpler, or both?

Docker makes it very easy and quick to build, version and manage service runtimes. The speed and agility in which Docker images are launched and destroyed is unmatched. But on the other hand, using these service runtime in production brings a slew of new problems. Many of these problems are related to the fact that a container is an isolated process rather than a full VM images, and the fact that there is not enough common practice for how to deal with process debugging, log sharing, inter process communication, resource monitoring etc.

We experienced some of these problems first hand, and they are real show stoppers. The market awaits for production level solutions to appear to resolve these problems. Today they are addressed by tools ecosystem forming around Docker that is still immature and will be probably be also addressed by competitive solutions to Docker.