A Vision of Liquid Software

Release Fast or Die

Modern industry has evolved to the point where a company’s survival depends, amongst other things, on how quickly it can release software and keep it updated on the compute edge. While this may be more intuitive in technology companies, it is less obvious for companies that, on the face of it, are in other verticals. So first, let’s remove that distinction and blur the lines. Maintaining complex websites, mobile apps, assembly lines, sales funnels, distribution chains and many other functions requires software, and much of this software is developed within the company. Therefore, in practise, every modern company is (or at least has) a software development organization and must have the capability to release software fast. Here are just a few reasons why.

Maintaining a Competitive Edge

In any marketplace, a company must be able to constantly improve its offering in order to differentiate itself from the competition. As soon as one company adds a new feature that is in demand, others scramble to add it and catch up. To stay ahead of the competition, a company needs to constantly set the pace with new capabilities and leave the scrambling to others.

Fixing bugs and issues

Nothing is more frustrating to an end user than software that doesn’t work. Users have short spans of attention and very little patience when “clicking the button” doesn’t produce the expected results. They very quickly take their business elsewhere and browse to the ever-present competition. Whether the company is running an eCommerce site or a reservation system, the presence of a bug can very quickly lead to millions of dollars lost.

Removing Security Vulnerabilities

The cyber security market has been estimated to reach $170 Billion by 2020. This is a testament to the amount of effort companies have to expend to keep their software safe. Security vulnerabilities detected in a company’s systems must be remediated as quickly as possible. The faster a company can release a software update to remove a detected vulnerability, the quicker it can protect its software. So it’s clear that releasing software fast is paramount to a company’s success, and each release is given an identifier – the version number, however this too is changing.

The Vanishing Version

In the old days of monolithic, bi-annual software deliveries, a release was a colossal event that took weeks to prepare, and due to the amount of changed code, was a risky undertaking. On the receiving end, customers would spend a lot of time unpacking the software, validating its different parts, and testing its integration with current systems until finally (and carefully) deploying it to production. Each monolithic version was ceremoniously tagged with a version number. This was a critical parameter of the software since it identified all the parts that worked coherently together, and was also needed for support staff to work through any issues reported by a customer. Today, the concept of a “version” is melting away due to three factors: short release cycles, distributed software and the Internet of Things (IoT).

Software automation has vastly reduced release cycles. Deliveries have accelerated so much that some forward-looking companies are releasing software several times a day. Customers no longer want (or even have the capacity) to unpack the software, test it and validate it for every single release. They just want to know that they are on the “latest” stable version at all times and that it will integrate smoothly with their currently running systems. The actual version number is irrelevant. In addition, software is becoming more and more distributed. What might once have been run as a fully onprem localized installation, is today, run as an array of microservices on the cloud where each microservice is updated on an independent release cycle. With each “micro update” the “macro version” changes, which effectively makes it meaningless since nobody is really aware of what version they’re running on.

Finally, the number of devices connected to the internet is exploding with predictions reaching over 50 Billion devices by 2020. As more and more devices get on the grid, managing the update of their software can only
be handled efficiently through automatic updates without human intervention, and devices don’t really care what version they’re running.

Liquid Software and Continuous Update

We started with monolithic, manual software releases with a distinct version number, and got to software built from distributed microservices released in rapid, automated cycles, but with no meaningful version number. If we now extrapolate the current state into the not-so-distant future, we can imagine a world where release cycles get so short, and microservices become so small that at any one time, it’s likely that something is being updated. In effect, software will become “liquid” in that we will be connected to “software pipes” that stream updates into our systems and devices; liquid software continuously and automatically updating our systems with no human intervention.

While eyebrows may be raised at this idea, the concept is not foreign, and in fact, we already encounter it in our everyday lives. We turn on the tap, and take it for granted that water will come out. We trust the municipal authorities to make sure the water is clean enough to drink, or provide us with alerts and warnings that it may only be used for bathing or irrigation, or not at all if water sources have become severely contaminated. Similarly, when we plug a device into an electrical outlet, we expect the device to receive a steady supply of electricity at the right voltage so our device “just works”. Similarly for cooking gas or any other utility we take for granted. None of us tests our utilities; we just trust their quality. So why can’t we just connect our systems and devices to “software pipes” and trust that our software will be continuously updated, safely, robustly and automatically? This is the next big challenge that DevOps must address.

The Last Mile

While there is still a way to go, we are already closer to Liquid Software and Continuous Update than most people and companies think. In many cases software updates are already automatic. Take mobile devices as an example. Most of us set a checkbox in our cellphone’s configuration to allow automatic updates of its firmware. The update just happens, and is even smart enough to wait until we’re on a Wi Fi network so as not to burden our data plan. Similarly, when we download an app, we allow the vendor to stream updates to us automatically through the corresponding app store. But even those of us who don’t allow automatic updates will click “I accept” when prompted without really thinking about it. We won’t bother reading any EULA we are confronted with, and even if we did read it, it’s unlikely that we would understand its legal jargon. At the end of the day, we just want the latest software without having to think about it.

This is the mode of operation we are moving towards for enterprise software, but for this to be widespread, there are still some challenges to overcome.

Trust and Security

When we turn on the tap, or plug into an outlet, we place trust our utility provider. That trust is based on past experience and the knowledge that the regulatory authorities are monitoring the relatively few utility providers we use every day, and ensuring that nobody is tampering with them. An enterprise software organization is likely to be “nurtured” by many different providers. Security mechanisms must be in place to validate the identity of each provider and confirm that the flow of software continuously updating our systems has not been tampered with.

Software Quality

Before an enterprise deploys a periodic update to its production environment, it will run a battery of tests to make sure nothing breaks. Nevertheless, production bugs and system outages are still costing enterprises billions of dollars each year. For enterprises to trust that continuous update is robust and will not break their production systems, liquid software quality will have to be be much better than the updates we get today. This places a heavy burden on vendors to provide software updates with a very high level of confidence.

Versionless Software

As already discussed, software is increasingly becoming versionless. End users (certainly those that are allowing automated continuous update) won’t be able to identify the software they are running by a version number. That also means that if some disastrous bug is discovered in an update, there’s no option to roll it back. And if the customer contacts the vendor’s help desk to report a problem, or even to just get help with a feature, there must be a way for support personnel to identify exactly what the customer is running.

Transparency and Coordination

Since software will become versionless, there must be a way to coordinate what is currently running with the new software updating it. The automated mechanisms that install the latest updates flowing through the pipe will need a way to determine that the update is compatible and desired.

Decreasing Release Cycles

Software vendors are still struggling to shorten their release cycles. There are many barriers to overcome such as availability of tools, the pace at which DevOps practises are adopted,code size, implementing fully automated pipelines and more. Some companies are succeeding. In 2011, Amazon publicly announced that it was deploying code to its production systems every 11.6 seconds. By the end of 2014, Amazon was deploying every second (albeit, to its own systems). So while not every company is Amazon, their case shows that it’s possible.

Conclusion

Software development organizations continue to release software at an ever increasing-pace with ever-decreasing cycles. Today’s challenge for enterprise software is to embrace this unstoppable trend and get release cycles down to zero to achieve controlled, secure, continuous update on everything that uses software, from computing systems, to smartphones and tablets, to consumer electronics to simple connected devices in the IoT. Once that is achieved, software will be liquid, flowing continuously from development environments, through distribution platforms to perform automatic updates. To get there, the same automation that has reduced release cycles to mere seconds (in some cases), will have to be extended further until it is pervasive in all phases of software development in every development organization. The security risks inherent in automated systems will be mitigated by standard mechanisms that authenticate the production end of the software pipe to the consumption end, and validate that the software flowing through the pipe has not been
tampered with. The whole update process will have to be mediated through exhaustive metadata that clearly describes the software and provides the transparency that software consumers need in order to understand what is being installed on their systems. At the end of the day, through the use of standard security systems, and metadata, the emergence of continuous and automatic update of liquid software is only a matter of time.