The JFrog Enterprise+ platform we launched at swampUP last May really caused a stir in the industry heralding the liquid software revolution of continuous updates. The amount of interest and inquiries it generated shows that the platform truly addresses the pains that large enterprises are having in the end-to-end management of their binaries. But with all the capabilities and integration offered by JFrog Artifactory Enterprise (without the +), JFrog Xray, JFrog Mission Control and JFrog Bintray, you might ask yourself, why you need Enterprise+. Well, we already provided 10 good reasons, but sometimes, it can be hard to identify when you have reached that tipping point where you absolutely must upgrade from Enterprise to Enterprise+. After many sessions, both with our esteemed group of beta users, and F100 customers who have purchased Enterprise+, we managed to pinpoint five pains that our customers experienced that tipped the scales for them, and justified the budgeting needed to upgrade their installations to Enterprise+. Here are 5 signs you should look for that indicate you are ready for JFrog Enterprise+.
1. The number of locations to which you need to distribute your software is becoming unmanageable
Whether it’s retail stores, regional offices or remote manufacturing facilities, you need to keep them all updated with your software. Add the dimensions of software package formats and multiple worldwide locations, and you’ll find that collecting together all the different update packages, and delivering them to the right place at the right time becomes akin to managing a modern fulfillment house. What you need is JFrog Distribution.
Using Distribution’s UI and extensive REST API, you can fully automate setting up all the different release bundles you need for that multi-dimensional array of locations and have your software updates continuously and securely delivered to their targets.
2. Teams in different data centers need a secure way to share a grab-bag of binaries intermittently
When collaborating across data centers, teams need different ways of sharing artifacts. For repositories and artifacts that constantly need to be synchronized, Artifactory offers various modes of replication. However, sometimes, there’s a need to collect a set of disparate artifacts and builds from different repositories in Artifactory and share them with the remote team without having to synchronize complete repositories on an ongoing basis. For example, this could be a library that executes some of your business logic implemented in different package formats, along with documentation files stored in a generic repository. Release Bundles are the solution to this pain.
Release bundles give you the flexibility to collect any disparate set of artifacts and deliver them to another team, working on another Artifactory instance, anywhere in the world using JFrog Distribution. And since release bundles are both signed and immutable, you not only ensure that all the artifacts you want to share are successfully and securely synced to the target Artifactory, you also ensure that once received, none of the artifacts will get deleted, so any dependency between those artifacts is supported.
3. You want Artifactory closer to your edge services and devices, but don’t have the budget for it
So you’re using JFrog Distribution to create release bundles at your data centers, and now you want to get them to the services and devices that run your software. To avoid issues with connectivity and network latency, you need an Artifactory service in the vicinity of those consumers, however, the costs of setting up a full-blown Artifactory instance near all the places you need to deliver your software is waaaaaaaay out of your budget. Weeeeeeeell, have we got an Artifactory for you. It’s called Artifactory Edge.
While an Edge node is a fully-featured installation of Artifactory, its license only enables those features needed to host your software and provide those packages to the services and devices that consume them. You can think of an Edge node as a “read-only” instance of Artifactory. Anyone (service or device) can pull software, but only JFrog Distribution can upload software, in the form of release bundles, to an Edge node. Now, since an Edge node’s functionality is geared towards a very specific function, it costs only a fraction of what a full-blown Artifactory instance costs.
Poof! Your budget issues just evaporated.
You can now set up a multi-star topology distribution network in which each data center can be a hub from which to distribute your software to any number of local Edge nodes which are strategically placed near the point of consumption.
4. You need a global, cross-team setup in which users and CI/CD servers can access different Artifactory servers in multiple sites
As your company grows, and with it, the number of users and CI/CD servers accessing Artifactory, managing who has access to which artifacts and repositories can get pretty hairy. You need to balance segmentation of access, so teams know that nobody will inadvertently tamper with their artifacts, with an overlap of access, so that teams can collaborate as needed. After planning out and implementing a structure of users, groups, permissions and access tokens (all the security entities involved in accessing artifacts), you finally got your configuration right. But now, you want to provide access to a certain group of developers and CI/CD servers to the Artifactory service being used by developers in the next building. You would need to sync over the relevant part of your security configuration and maintain it every time there was a change. You might manage that with two Artifactory services, but what if you now also need to give your developers and their CI/CD servers access to the Artifactory used by your QA team on the other side of the country, and then hook them up to the QA team’s Artifactory in Russia and the support team’s Artifactory in India…Are you starting to see the nightmare unfold? Your Artifactory administrator would start getting calls from your users that they can access certain artifacts and repositories on “their” Artifactory server, but not on “the other one”. Or worse, builds would start failing, because a CI server could not access dependencies in one of those remote Artifactory services. JFrog Access solves this pain out-of-the-box.
Using Access Federation, you could define a circle-of-trust in which all those security entities would automatically be synchronized. Depending on the direction of synchronization, you could build a full-mesh structure in which a change made on any Artifactory service would automatically be synchronized to all the other Artifactory services in the circle of trust.
Whatever the topology that meets your needs, JFrog access has the flexibility to support it.
5. Your software updates aren’t succeeding due to a poor network connection or low bandwidth
As your enterprise has grown, so has the spread of your markets, and you may find yourself needing to provide software updates to places where your internet connection is always jittery and prone to disconnection. Think developing countries where ISDN or (gasp!) DSL is the standard, think remote locations or even think of ships out at sea with an internet connection available for a few hours a day at best. You may find that a software update may fail if the network goes down (again!) or may simply take many hours to complete, especially if you need to sync large files (Docker images can easily reach tens of GB in size). Artifactory’s Replicator was designed with these exact issues in mind.
The replicator is currently only available for use by JFrog Distribution when synchronizing the contents of a release bundle from a source Artifactory service to a target, and overcomes the problems of a poor network connection:
- Efficiency: The replicator breaks up the data it needs to synchronize into multiple streams to maximize its use of the network.
- Reliability: Since, by design, release bundles are immutable, it means that JFrog Distribution verifies that the target Artifactory service has received the release bundle in its entirety.
As an added bonus, since release bundles are signed at the source, you can also be sure that they arrive at their destination securely without any risk of tampering along the way.
The JFrog Enterprise+ Platform is not just a step up from “Enterprise”; it’s a quantum leap that opens up a whole range of new capabilities enabling you to automate fearless, continuous updates from code to production. As your enterprise grows, and with it, your JFrog infrastructure, serving more users, hosting more artifacts, across more teams spread across more global locations, and provisioning more and more services and devices on the compute edge, you will eventually see one of these five signs.
Are you there already?