How are you doing? Welcome to scaleyourapp.com
Recently, a software development methodology or I would say a software release methodology to be precise, called the Liquid Software Development caught my eye.
Being in the trade of shipping software, I am sure you must have come across the industry buzzwords such as the continuous integration, continuous delivery & the continuous deployment. Practices involved in shipping software, patches & upgrades to the customer ASAP.
When I read about it, it got me pretty intrigued. What is liquid? Software has a state now? Well, that’s interesting…
Let’s find out about it.
1. What is Liquid Software Development?
The concept is introduced to the world by Jfrog. A company helping businesses manage & release software efficiently.
Liquid Software Development simply means a quicker move to production. Having a software release system in place which would enable teams push upgrades to their apps or online systems several times a day. Implementing new features on the fly, without worrying about breaking stuff, security & repercussions of frequent upgrades on the user experience.
How do we expect to do that?
By having a software release pipeline directly connected to the end product. And via the pipeline, patches & upgrades would flow to the app, continually like a liquid. Hence the term Liquid software development.
So, instead of planned releases, there would be pipelines which would automatically continually keep pushing the upgrades to apps without any fuss.
With so many frequent updates, software versions are a thing of the past. Now there is just one version, the latest version. That’s it.
This concept is very closely related to continuous deployment. Where things go to production without any human intervention. We would have automatic builds, unit tests, integration tests, code analytics in place to assure the quality of the patch going into the production.
The industry is going towards automation. Bots run automated tasks, manage & improve workflows in GitHub repos enabling the moderators to focus on important stuff.
2. Why Do We Need to Adopt the Liquid Software Development Approach?
First thing, we have the realization of the importance of moving fast in the industry. Businesses are evolving at an exponential rate. The software development processes had to evolve from Waterfall to Agile & from quarterly code releases to continuous integration, delivery & deployment.
Nobody can refute the early mover advantage in the market. It holds the potential of making & breaking businesses. Also, you kind of get a bit of a leeway in perfecting your product in case of few faults or limitations, if any, in the initial phase of launch. Solely due to the reason you are the first to bring it to the market.
I would like to share one of my industry experiences where I strongly felt, a hell lot of time could have been saved if he had a continuous update infrastructure in place
In the past, I worked as a programmer in a massive Telecom project. The system was built on Siebel, An Oracle CRM tech.
Ok, so being a telecom company, the business had to continually come up with new calling & message plans to stay competitive in the market. The work was always pretty intense.
At that time pushing the code to production was really something. Software release was not automated & it was a tedious process.
We made changes in code. Pushed to the staging environments. Had to manually run the builds & tests & everything. Only when we were certain of the correctness of the code.
We gave the manual testing team a green light. And then they took a solid time to test things from scratch.
Why test from the scratch?
The testing involved regression testing too. If the new changes had broken any existing functionalities. Boy, it was something. You can imagine the amount of time a small code change took to move to production. It was months of work.
The code change hardly took 40 to 50% of the time. The major time sink was the entire deployment flow.
Though there are scenarios where we cannot do without manual testing, I’ve talked about it in the upcoming section, but we can always save time running the automated regression & integration tests.
Continuous deployment & Liquid software release pipelines would have cut down the deployment time by notches.
3. Some Of the Real-World Observations Which Give Us an Insight Into the Need For Faster Deployments
3.1 Browser Wars
Browsers are our portal to the web. That makes them data mines to the companies. The competition to attract users to use their product is fierce. Some of the big names in the game are Chrome, Firefox, UC, Opera etc.
If you don’t move fast. There is no survival. Companies are innovating at a quick rate. To move fast, we need to cut down the deployment time as much as possible.
Chrome always has so many frequent upgrades. Whenever I happen to look at the top right corner of the browser, I always happen to see that upgrade icon green.
UC browser offers so many features out of the box, messenger integrations, VPN, social features, news & what not. It already has a firm grip on the Asian market.
Do you think we stand a chance if we launch a product & do not continuously improve on it?
3.2 Banking Applications
Banking systems have ideally operated on legacy systems & archaic tech which in my opinion is a major hurdle in innovation & bringing out new features to the market. But lately, they seem to have realized this & coming out with new features for their customers.
I am always sort of wary of using credit cards online, especially on servers hosted outside of my country. The government has no control over it. If a miscreant sitting in any other country gets hold of my credit card. I am screwed. Just the card number will suffice. Even the PIN is not required.
Recently a popular global bank, came up with a pretty amazing feature which would enable a customer to turn off the transactions on their card via their mobile app at wish. It’s a toggle switch. Just turn it on when you need the card, turn it off when done.
Not only it adds an extra layer of security, it also attracts potential new customers to the business.
I recently wrote an app on Firebase. It had a pretty nice feature called the Remote config. It enabled the developers to change the behaviour & appearance of the app without requiring the users to download an update.
In the present state of the gaming business, there is a battle royale going on between the gaming companies.
You might have heard of the Fortnite & the PUBG tussle. Moving on… I am sure you’ve heard of Clash of Clans, even if you are remotely into gaming. The sole reason why Clans of Clans & PUBG exploded was that they brought something innovative to the market & they kept innovating. They did not give an inch of ground to their competitors. The only way to stay ahead of the curve is a faster deployment of patches. Fixing bugs in the system ASAP.
Another instance is Youtube Gaming & Twitch. Both are streaming platforms for games. Youtube is spending a lot of money on their Gaming platform to compete with Twitch. Both the platforms keep experimenting on launching new monetization strategies like donations buttons, subscription-based models etc, to attract more creators. Faster deployments give businesses a competitive edge.
3.4 IoT Internet of Things
Manually upgrading IoT devices such as a cluster of UNIX servers, home automation systems, devices installed in the Hospitals, every now & then is never feasible.
We need to have an efficient way of detecting & automatically updating software running in these devices.
4. Possible Risks Involved in Completely Automating Software Release & Frequent Updation
This is where I talk about the risks involved in completely automating the release process.
Entirely automated software release sounds pretty cool but here are some of the possible limitations which occur to me:
Automated tests never always cover the product comprehensively. We do have to look out for the corner cases manually. We need humans for that.
Now you might think, yeah that’s kind of a trade-off but there are instances where we have to be more than a cent per cent sure that the new upgrade won’t mess things up.
For instance, systems monitoring patient’s health, or assisting surgeons in operations. Systems online in an aircraft. There is no scope for folly, lives are at stake.
Even if we have a continuous upgrade pipeline, we also need a solid fail-safe & a rollback mechanism.
What if something breaks, or changes the flow or something after an update in a trading app. Chaos. Just not acceptable. Well, it’s ok for social apps. Things can be fixed in the second patch. But not ok for mission-critical systems.
More On the Blog
Well, Guys, this was pretty much it. My views on Liquid Software Development. If you liked the article. Do let me know in the comments. Feel free to share your views. Share this article with your friends.
See you in the next article
- Distributed Systems, Scalability & System Design #1 – Heroku Client Rate Throttling
- Zero to Software/Application Architect – Learning Track
- Java Full Stack Developer – The Complete Roadmap – Part 2 – Let’s Talk
- Java Full Stack Developer – The Complete Roadmap – Part 1 – Let’s Talk
- Best Handpicked Resources To Learn Software Architecture, Distributed Systems & System Design