Should the developer in you care about Unified Platform?
By: Prasanna Raghavendra
Tags: DevOps, Platform

There has been a lot of buzz around unification of services, to provide a single window for end users to work with. But how does this work for a developer, what does this single window look like for the developer? We asked this ourselves when we were building a Unified platform, and these are the services which we believed need to be unified and provided to ensure developers and administrators can optimize their work.

1. Unified UI: As a developer, One of the most important uses of a binary store is to be able to search the repo to pick the right package to be used. Introducing global search, which can help you search across any package, to get details on the downloads, license information, the security issues, and the versions available in the package. The developer friendliness really comes in the keyword based search where you can use keyword based search to dive right into the package you are looking for. Consider a query below:

find all the packages that was uploaded after Feb 1st, and having violation severity high, and having cve: CVE-2019–12 translates to after:2020–02–01 cve:CVE-2019–12 severity: high

2. Unified Configuration: Artifactory by itself came with a lot of configurations to be done. With the unification process, one would expect that the configuration of such a platform will be complex by an order of magnitude. But the reality is that, it is made even more simplified. The secret behind this is consistency, we took one system.yaml which is of the same common structure across all the products in the platform, allowing consistency and re-usability of configuration snippets helping automation of configuration changes. A detailed look a the new and shining system.yaml here

3. Unified Installation: We attempted to make all JFrog products installed similarly to aid developers to automate installations and upgrade across all products, as if it were one product. Of Course there are specific nuances of each product, but the key is that this has led to a lot of commonality across installers leading to more consistency and faster turnaround of fixes. A discuss around this is done very well by Vivek, here

4. Unified Folder structure: Extending the principle of common configuration via system.yaml, we also considered creating a common folder structure for all our products, mainly to allow a clear segregation of immutables and mutables. Very well discussed by eldad here

5. Unified Communication: We also streamlined all the communication across our products and service to allow net-native architecture to be used even in a standard VM based installation, while allowing cloud native services to leverage net-nativeness of the overall architecture. Introducing router service in the new platform helped us to remove redundant code across all products to handle communication, service registrations, SSL services, routing logic, health-check services and meshing of services. More details about this bundled service is here

5. Unified Naming: We took this opportunity to also streamline the names of all the different packages to allow a simplified continuous upgrade to be performed by watching out assets in Bintray. Here is a nice table that may come in handy.

Unified Naming

We at JFrog hope you will love these features as much as we did working on them. Keep those feedback coming!