As you look at the preponderance of DevOps tooling solutions available today, you notice similarities in deployment automation and how they work. DevOps is purported to be the most significant catalyst for change in how we innovate in the last two decades. Yet, as you examine the tooling and the strengths and weaknesses of each, so many products are strikingly the same. It seems to me that if DevOps is to ingrain itself in IT culture, it must use its own principles to remain current, or remain fresh in the coming years. The doctors of IT must learn to use the tool of change to change it once again, and then again, and so on.
Case in point: The deployment discipline of DevOps is premised largely on a “controlled” rollout. Deploying versions of code and versions of applications into production is a fully controlled event. Our entire release orchestration (RO) discipline is merely an extension of our basic deployment tooling. RO tools add governance and quality assurance (QA), segregating it directly from a specific deployment and handling it more broadly in a release event. But whether we are examining a deployment tool or release orchestration software, both rely upon a premise of controlled distribution of applications to their respective destination.
The Mobility Disruption
Mobility, or mobile apps, disrupt this thinking. The platform our Apple partners have given us (in its current form, though I understand that is evolving as we speak), is based on an “at will” acceptance of a new version of a given application. When I look at my phone, I see a red balloon informing me of how many application “updates” are available for me to accept. I can decline an upgrade just by not taking any action. This is true, even of the newest version of the Apple OS (the foundational building block of application capabilities). Or, when I am home on my Wi-Fi network, I can at my leisure begin downloading and updating the various software application versions to the latest offerings. All are my actions, determined completely by my choice.
It’s a little different on my PC—I have more flexibility of what version I have running on this platform, at least in terms of rollback. If I do not like the next version of my web browser, I can pull up the site and choose an older version to use on my PC, until the errors that bothered me are resolved in the latest offering. Mobile apps, in the mobile catalog so many of us use on our phones, offer no such options. Once I have updated the application to the latest offering, I am stuck with it, errors and all. If it becomes too intrusive to my work efforts, I would have to pick something else to take its place, or just stop using it and wait until a new version is available again.
DevOps deployment tooling is foreign to this model. The servers in production do not get a choice about whether they intend to accept our deployments, and when they might get around to it. They do what we tell them to do, and when we tell them to do it. But it seems updating our servers, upon which future versions of applications will rely, does not cover the last mile of our application delivery. Mobility is accomplished ad hoc, by consent, and without controls on my part.
This has an immediate impact to my thinking about application distribution (and how DevOps will play in this new world). If I make a catastrophic change to the servers my mobile apps rely upon (that is, a change where only the new version of the app works), it will require my users to upgrade, or stop using the product as it sits today. This is dangerous if my application is utilitarian (not critical to daily life), and could be replaced by a competitor. It might mean that my applications must seek out version-specific back ends if I want to have multiple versions still working until people get around to upgrading. That costs time, money and support. Either case forces me to think differently about distribution.
You can imagine how angry you might be if your online banking software just stopped working. Mobility in its current form also makes rolling back to a previous version a near impossibility. So if the new version of the app has a bug in it that prevents key functionality, I am going to get a huge black eye with my customers, and must race to produce a new version minus the old bug, even assuming universal adoption. Alternatively, my customers may be using the buggy version for a while before they choose to upgrade to the bug-free version.
There is tooling for corporations to more tightly control a provided device or even govern what happens to personal devices for corporate software. But the ability for DevOps deployment solutions to integrate with a mobility platform requires a new way of thinking. The limitations and the new capabilities must be taken into account specifically before any vendor can legitimately offer a holistic solution for DevOps for mobile.
The Quantum Obliteration
Quantum computing is likely to prove once again to be another disruption to our DevOps model. Evolution will help us bridge the gaps and minimize the impacts. But consider that quantum systems are not based on a foundational binary model. This is not like English speakers having to learn the Cyrillic version of the alphabet to read and write in Russian. No, it is more like communication will be telepathic from now on. The entire constructs of binary will eventually fade into the history books, and a new construct will emerge in its place.
Today we use binary-based computing systems to attempt to converse and control the quantum systems built so far. When you don’t know how to communicate telepathically, you use what you do know: reading and writing. But it will take a long time before the power of quantum computing is truly unlocked; until then, we have to constrict its capabilities with binary-based computing methods. When native quantum languages, and perhaps hardware, are let loose, the true power of the platform will be better understood and impacts experienced.
How will DevOps play in a quantum computing environment? Will the fundamentals about deployment and distribution once again evolve to incorporate the impacts of new quantum platform capabilities such as entanglement? Or will we experience what we have in the mobile platforms of today: a series of catchup steps to deal with what is different? If we use our catalyst of change in DevOps to begin to think differently about our own future and the capabilities our tools should provide, perhaps DevOps will still be unlocking possibilities none of us dream of today. If not, I foresee DevOps becoming only another fad, replaced by the term we give to the next wave of innovation thought needed to unlock our future.
To continue the conversation, feel free to contact me.
