The days of software packages are coming to an end. Say hello to what JFrog co-founder and chief architect Fred Simon calls “liquid software.”
“Once the number of applications and libraries and pieces of the software that needed to be managed reached a certain point, we started to see an exponential increase in the amount of software modules, and the frequency of updates and versions, all the way to the end user,” he began.
“What we used to consider as software packages to manage with tagging and versioning, and a destination, address number, type, barcode and then you ship it away in any kind of format – all these concepts of actually creating a package and delivering software in the form of a package, little by little has disappeared due to the fact that we are making more and more of those and releasing them more and more frequently.
“We shifted our approach to software updates, not out of packages, but out of the concept of continuous flow of software. You start to think in terms of piping, and then you start to connect the different software factories and the different departments and the different vendors and the different teams by connecting them with pipes, not by connecting them by physically delivering or on the cloud delivering the files from one place to another, but continuously providing the latest version of whatever software is available to the next destination.”
This is what Simon says (couldn’t help it!) is the liquification of software systems. “Little by little, we are seeing any kind of software in any kind of environment moving to this liquid delivery mechanism, where you plug yourself to a client that you trust to deliver clear water which is unpolluted and secure, and by the way you’ll get all security updates and the latest versions of whatever you want,” he explained.
If this sounds like the DevOps revolution, it’s because Simon said it is. “There is another catch phrase we use quite a bit to reflect this; it’s release fast or die. The ones that are not even trying to do that are probably companies we won’t see in the next decade.
At JFrog, Simon said they want to make sure the tools they are creating can be used by the “plumber, who creates the piping and lets the liquid software flow. “The replication and the pipes that are created between the different repositories, which can be located all over the world, need to continuously deliver the right things to the right destination,” he said. “All the synchronization is a critical piece of our tooling. So of course the ability to see and to transparently view the actual flow of the software. Before, when it was actual trucks, the way to control it was to control the timing of the delivery of the package. When you go to liquid software, you need visibility and transparency, but need to change the control mechanism for frequency, quality and flow of delivery.”
Liquification is a strong force in the market, but for organizations with existing processes, the move to a continuous flow of software has many challenges. “To be frank, the full liquification of software is contradicting a lot of the processes many companies set in place. There are a lot of companies who have a six-month block time before the vendor has a new version and the new version gets inside the company. It’s not rare to have such a strong mechanism of compliance and any kind of test that companies and processes set in place, where they only accept a very few releases per year. Those processes are the ones that are suffering today.
“When you have a monolith, you start with a version in your version control system and you build everything and test everything and deliver everything,” he continued. “It’s a very sequential process that for really big software could actually take weeks. Once you start in microservices, each of the microservices has its own lifecycle, so you can make your own single build and test locally and have a new version automatically created. The ability to aggregate all those microservices and to tag a specific version at a specific time and create another application out of those microservices and those different versions rapidly and efficiently is critical for the next step.”