Human Microservices
If we spent half as much time on monitoring and fine tuning the configuration and performance of all of these "microservices", what an incredible system could evolve. Instead, we ignore the "real" aspects of our lives, the relationships we have with our families, our children, our community and our dreams & aspirations. Should we not rather focus on developing applications that "enable" us - but enable us to do... what?
There is this interesting question that is asked on Passover regarding the Exodus - the gaining of freedom from bondage - and it is this: "Ask not what only what do you want to be free FROM, but what do you wish to be free FOR?" Of course, the response is that we were given the Torah as an instruction manual of how to use this freedom. For bondage is when there is no freedom of choice.
We stand at a time in the world where we can choose...
It is not about simply eradicating these "evil" aspects of the human condition - something we have tried to do over the ages, and seemed to have had some success, but not close to completion. In fact, it might even produce the opposite effect. In that what we focus on grows!
Is it not interesting that in the world of IT we have FinTech, but no SocTech? So this is my question: What if we used the incredible advances in IT to design a more fluid, dynamic and reactive social system of governance? One that does not work on averages, and on very gross lines describing the natural social topology.
Socio-political systems
Let me start from another angle.
I started my career on a monochrome terminal hooked up by a telephone cable to a mainframe computer. I typed in my program. Printed it on punch cards, walked over to the computer room, placed the pack of cards in a box (the queue), and then went and spent a couple of hours in the library until my job was completed. Back in the computer room, I picked out my printout, and retrieved my pack, and then check if I had any bugs... If there were any syntax errors, then I would fix the error and resubmit. Once this was clean, then one had to ensure that the algorithm was working properly! This process was not interactive, but time-bound, and sequential.
This reminds me of our current socio-political systems. Though the computers have changed dramatically since that time, our social governance systems remain very similar, with the computer focussed on enabling them to process the "paper" work swifter, to perform the same tasks, only faster, and with more potential monitoring. But the concept is still the same. Fill out your form, stand in a queue, hand in the paper work, and wait for a response. If correct, all is well. If not, amend the form, include missing documents, and try again.
The mainframe decides everything and you have little to no hope of amending the system that is making these decisions. These IT systems emerged as merely a digital copy of this process, but the drivers of this change soon realised, as demand for more services and greater responsiveness grew, the client/server paradigm emerged, and has been expanding its domain ever since. At first it was horizontal, but now it is becoming vertical, shaking the very foundations of the computer field.
What if there is an error in the system? What is the process for getting that fixed? Well, in the age of the mainframe, the "salespeople" came back with customer feedback, and then the system was amended accordingly, if deemed suitable... Reminds you of bureaucracy?
It is a quantum leap, or a leap into the quantum dimension. In the beginning the ground was solid. Computers were pieces of metal and wires that ran software. This software did something. But through "pattern recognition" we have come to realise that much of this software does similar things, just wrapped together differently, even in a single environment. So why not segment these functions, and re-use them? This is similar to object in programming, but more, in that everything now can be virtualised and exist as a virtual environment overlaid upon the "real" datacenter, consisting of real computers and real networks.
This reminds me of our existence. The human as a virtualised (or specific) environment, running in a virtual container, that is defined by software (consciousness), existing upon the "real" background/datacenter, consisting of real elements like metal. Thus the foundation upon which these services now run are virtual, not "real", and can be created and destroyed as necessary. This is just to underlie the very fluidity of the technology. What if all this technology and expertise, from ID, AUTH, Security, ensuring source is really the source, reacting to "bad" messages, dealing asynchronously, having templates for different situations (and if there is a situation that does not have a template that fits, then it will be flagged and that unpredictable situation will be dealt with?
pApps - people apps
What if the bugs were not pertaining to apps, but to people? What if these sophisticated messaging queues were not passing messages between apps but perhaps messages between people? Though I might refer to them rather as papps (people apps), as they are not simply messages between people (like FB msgs, or WhatsApp chats, Instagram shares, or any of the other myriad chatterings) but rather relevant messages. Starting with unemployment benefits, or foodstamps, or businesses. Ideally, it would percolate upwards, instead of down. However, even if it was top down, these technologies will enable us to very quickly evaluate the efficacy of the implementation, and adjust accordingly. (with the papps - which are essentially apps that 1. monitor 2. communicate) [These remind me of the agent/nodes of an enterprise scale monitoring system.]
Scaling
These last two return me to ToL Net.
Small scale projects networked that scale to large scale. Just like the separation of elements in the microservices paradigm. Once the app/solution/algorithm works, and has been implemented, it just needs to scale... The journey is the same as is being experienced and solved in many large corporations. It starts off as a large pile of mud, the monolith. What we have to do is break it up into microservices, so as to effectively handle the "user" or "customer" - the citizen. One of the problems that needs to be avoided is to segment too much. Then to manage a slew of microservices is overwhelming. To deal "individually" with each citizen would be impossible.So this needs to be sliced more broadly. (BTW, already we have a huge amount of information as to the interactions and relationships between the "users" that would enable us to make accurate predictions. We already see the results of this powerful technology in the hands of the powerful.) There are a myriad of ways to do that. And I would be interested to hear them...
However, I believe a good and effective way to that would be to group the citizens in small peer groups of 10 [+/-2]. [with proxies/shadows - that will make 16 - 24] [12 shown to be max. amount for efficient meetings.]
Message Queue (IT)
