Four. Liquid Software by Fred Simon, Yoav Landman and Baruch Sadogursky

2018, self published, 194 pages. Written in English, read in English.

(Medium are making me clarify issues regarding possible affiliate links in my articles so please read this.)

Disclaimer: In my profession, I am a developer and a developer team lead. As part of my job and my wish to continuously learn and improve, I read trade books every once in a while, and I will write about them here. If your interest lies more in the general fiction or non-fiction realm, these reviews may not be interesting to you, in which case you are welcome to read many of the other articles in the Sixty Books publication which are not about trade books. I will add a disclaimer similar to this at the front of any review about a trade book in the future, so you can tell.

A lot of software companies are deploying software to production using a methodology called Continuous Deployment. In contrast to the more traditional way of deployment, which requires production servers downtime, or for the customer to download and install a new version on their devices, continuous deployment uses a pipeline in which software is checked and verified, and then quarantined and stopped if needed in various checkpoints if it is not applicable to be deployed to production. This allows for more frequent deployment cycles to production (sometimes even daily or hourly) and allows the customers to enjoy the software continuously without downtime.

There are still a few aspects of upgrading software in production which Continuous Deployment does not solve, and that is primarily what “Liquid Software” is talking about. In the book, they interchangeably refer to the methodology as Liquid Software or Continuous Update, and they address two of the main concerns remaining with Continuous Deployment: The first is, that this kind of update can only be relevant to software components that are within the company’s control, and only to software components. Meaning that third party components, and components which are not based on software (like a database, for example), cannot be updated in production in the same way; the second is, that this process still requires the knowledge, control and possible intervention of a dedicated person or team of people.

The book offers some examples and some solutions. I’m not going to divulge any of them here — you will need to read the book for those. However the main premise of the book is to persuade you, the software professional or dev ops professional, to accept a different mindset. A mindset in which a production system can be allowed to become so large and intricate that it cannot be controlled by human employees (the book also makes an effort to persuade you that it shouldn’t), and in which the precious mental resources of a developer are engaged only when there’s a need to develop new code, or fix a problem that is found, by machine learning and automated processes, in the existing pipeline.

I found the book to be very interesting and very persuasive in providing this new concept and explaining why it’s important for all companies to embrace it. Being a book that was written by three key members of a software company that sells a product, an average reader would become suspicious that they were trying to sell something. They may have, but I did not detect any particular product or set of products mentioned in more than a passing remark in the book. What I think is being done in the book, is planting a seed in the minds of the readers that would allow them to want to improve the way code is being deployed in their production systems. The company publishing this book may have some products in the future which are going to be helpful with automating and improving key components of this pipeline, and if that is the case — good for them. Providing easy, off the shelf solutions for common problems in the development cycle of other companies seems to be the wave of the future in emerging companies, and so, according to this book at least, is Continuous Deployment.

(The book can be found here, or, apparently, in conferences in which JFrog has a booth)