Dark DevOps - Moving from Human Centric IT Automation to Lights out IT Automation

Background

There are two commonly used terms in this context - the first one is the word "Dark" and second one are the words, "Lights Out". Both of them has been historically used in the context of Manufacturing and Production engineering. The basic premise of Lights out or Dark Manufacturing is a philosophy where there is no need of human presence. The entire factory or manufacturing process can run on its own without any intervention.

This idea of "Lights out Automation" first came from a book called "Autofac" written by the American writer "Phillip K Dick" in 1955. Phillip is known to be the first to publicly think in terms of "Self Replicating Robots" in a war situation.

This idea of Self Replicating Robots was even taken to many movies like the 1995 movie screamers.

Phillip wrote a few more books on the same topic - on how machines or bots can gain predominance over humans in a war and post war scenario.

No question that the idea of a nuclear war and its post-effects are very dark and a war situation essentially means a lights out situation, but if used in the right context targeted for human benefit this lights out situation can provide lots of benefits.

Machines achieving sentience and able to communicate among themselves is no more an impossibility. There is also a philosophical paradigm of Machine Consciousness that is being actively pursued by many enthusiasts.

These essentially are efforts to build up the case of a controlled environment for Dark Automation.

Machine vs Machine Tool

These two terms are as old as the term Engineering itself. The difference between the two can be reiterated as below

It is very important to understand the difference between Machine and Machine tool to move forward, because the capability of the machine tooling is just replicated many-fold to achieve Dark DevOps.

A Machine can be created with a Machine tool. A set of Machine Tools is used in an assembly line to create a machine of value to its users. The below picture depicts an assembly like where humans operate on the assembly line to produce a machine of value. In this case is a Ford Car.

Humans in a Machine Tool Ecosystem

As of now Human beings were operating on assembly lines and trying to use machine tools with maximum productivity and efficiency to produce machines at lowest cost, even at the risk of humans of coming too near to machine tools.

Machines replacing human habits have also generally been rejected.

So in general too much of automation degrading the value of human life will never be acceptable - howsoever useful or capable is the machine or the machine tool.

What is Dark IT Automation or Dark DevOps ?

While there are many theories and experiments and subsequent results in manufacturing space, let us try and contextualize this to IT.

Dark IT or Lights Out IT automation or Dark DevOps is a philosophy where the entire IT is fully automated and does not need humans to develop or maintain the same. The entire development and maintenance of all the IT work is done by automation and automation for automation.

The word Lights out or Dark in this context means that when there are no employees in the building - generally all lights are put off - to save power. If there is no employee whatsoever - there is no need to have any light - as machines generally does not need light for themselves.Hence Dark or lights out.

So what we envision here is an Automation train which can create and maintain other automation trains intelligently which in turn is used to create and maintain IT products and services. The IT product and services can be used by humans for value added purpose.

Dark IT in Quantitative terms

As can be well understood we are trying to qualify and quantify the degree of automation to achieve dark IT.

So if Lead time for an IT need is L and Processing time is P and Idle time is I and the machine time is M.

Hence,

L = M + P + I

In a dark IT situation , I = 0, P tends to 0 such that L tends to M

So

L = M [assuming P and I near to zero]............................................................ (1)

So in an ideal situation L = M , meaning the total time is only the machine time and the processing and idle time is nearly zero. Without necessary thinking time , this model is much suited for repetitive tasks. So the equation needs to be modified for Dark IT, where the machine itself thinks and does the necessary processing, still keeping the idle time to be zero.

So all machines are either processing [read - learning and training] or executing [read - performing run-time actions]. So the overall processor time is connected to the leadtime as follows.

From equation 1.

M = M[Execution] + M[Learning] .......................................................................... (2)

So L = M[Execution] + M[Learning] .....................................................................(3)

Now both learning and execution time are can be treated as engineering constraints and necessary algorithms and interfaces can be developed to minimize lead time using powerful Machine learning and Machine execution algorithms.

Hence the engineering problem becomes how to minimize the lead time with Machine learning and Machine Execution.

The process part is now embedded in Machine Learning - and it becomes the imperative of the Dark IT engineer to successfully weave the machine learning and deep learning algorithms to effectively deliver IT in a human less fashion.

Why go Humanless ?

Humanless IT results in Dark IT. There is a huge benefit of going humanless in select areas. Let me explain you why.

1. Human mind does not generally want to focus on repetitive tasks as our mind is creative entity and does not like to operate within the confines of a limited boundary. So in general human mind tends to be limitless.The degree of limitlessness varies from person to person based on human propensity. Mundane data crunching is disliked by most.So its probably a good idea that the data crunching work be completely translated to machine language from business language and a bot controls the machine translation.
2. The degree of focus on some specific set of repetitive work makes the general human mind restless and it wants to break free from time to time. The frequency of loss of focus of human mind is very high, because the human mind is generally very inquisitive and seeks frequent change. Human mind dislikes boredom arising out of the repetitive work that he is told to focus on.
3. The creativity of this human has been enlarged and encouraged by machine based IT realizations to new business models like Digital Business.

Digital Business with Lights-On IT

Digital business in general does not require a lot of humans to begin with. Let us take the case of a digital bank. If you look at the site below you will find that many banks are Digital Only banks now. These digital banks have no employees or branches where you can go, its only available digitally. The existence of the bank is virtual , and it deals with digital money. So kind of "lights off" from the business side - the digital bank does not really need so many people to operate successfully- everyone and everything is available digitally in an omnichannel scheme. Only a few techies and business folks are enough to run the show.

It is now technically possible to host a Complete Bank with all its functionality in a few hours over a few computers using a DevOps pipeline. IBM has given a sample implementation using Bluemix and Watson for the purpose. It is available at

If you go deep in the code-base above , it will be clear that you will need some people to understand new changes, code them, push new changes, update new pipeline elements - typically operational activities. The code still needs to be maintained and new features needs to be coded and then built, tested and then sent to production.

So if there is an automation to further automate the pipeline management process , via parameterization, sub-classing, overriding , filtering etc etc, then the process of "Lights off Operations" can be established.

Lights off Operations

"Lights off" or "Lights Out" Data-Center is not uncommon. A common meaning is explained in the link

There are various companies who are consulting their customers to move to Lights out Data Center for better cost model and better support structure because everything is via a remote control. The physical systems is least manned and has been artistically visualized as below

Security of Lights Out Data Center

Security is an automation in a lights out or Dark DevOps world, Security tasks are generated by machines and is applied across every phase of the automated development process. So while humans will be designing the automation for the automation which will run the processes, the business security will be converted into a machine understandable form and applied to the Data Center. This includes but is not limited to physical threats, natural calamities, political threats, cyber threats etc etc.

Design Against Failure

This is done to save on the cost of failure. The principle is extremely simple :- If a service is not performing well remove him from the operations. This means for a system where the entire IT can be viewed as service matrix or mesh or mosaic , the User Interface will simply remove a service related space within it, if the service is not performing to expectations. This will reduce the cost of failure - because the faulty service has been automatically taken off from the user interface - via necessary automation and once the service becomes in a performing condition the necessary User Interface is automatically enabled again.

This reduces a lot of cost - that would result from the failure arising if the faulty service endpoint User Interface is still available.

If we think about this from an infrastructure service standpoint - the same principle applies

Reliability,Resilience, Chaos Monkey , Gremlins ....

If you look at Chaos Monkey or Gremlin, both of them uses their proprietary algorithms to achieve a state of reliability.

or

Now the question is how to run these tests in an orchestrated format. Some primitive integrations are available with Jenkins and no new development is seen.

more can be found at

Conversational AI

Conversational AI can be technically seen as a dialog agent that can take decision under uncertain conditions with partial observability and that too with very high degree of correctness.

There are many conversational AI tools in today's world and all of them promote a space where the Conversational agent is the one stop shop for all operations - so the rest of IT becomes dark if we have a few set of rational agents running the operations. So essentially a full stack Bot driven Operations and Bot Driven Development is the road to Dark IT.

Conversational and Action Oriented AI can be used effectively to bring on a state of semi-lighted DevOps where some humans and bots collaboratively can work. The bots as of today are not creative at all as compared to a human at work - but it can be very data oriented and can help take precise decision and execute the same.

The complete lights off or Dark DevOps is a situation where an AI based system will govern the process and technology and there will no need of direct human support as there will be a voice assistance for every work that can be done digitally and a set of bots, robots and IOT operated devices will be used for the Development and operations needs.

How to manage the job threat associated with this automation ?

Unfortunately there is a scope of job threat when we move from a Human Centric to Dark Models which are essentially more advanced form of Information Technology Paradigm

This new paradigm has the capability to compensate this with more jobs to create and maintain this new format of technology. Hence there will be lot of training and coaching institute including the tier one colleges and universities of the world who will be focusing on these disciplines and effective retraining can help a better transitioning.

Every company is looking at Agile and DevOps as their key performance area. So it is important to to be able quantitatively assess and evaluate one's position as a head or an executive within the enterprise value stream - which will effectively used to guide on how to retain, retrain and ensure growth and maintain a stable people architecture.

How to know more about Quantitative DevOps Assessment ?

You can start reading our book. Assessing DevOps Quantitatively. The book is available in amazon and on Kindle unlimited.