Distributed systems: from mechanic to the IT infrastructure

Img.1.:: Complex Distribute System ~ new tools definition

Many things that we know in IT these days could be partly taken as the reflection of the mechanical tools evolution (Img.2.). Such evolution is continually happening over last centuries. Physical and other laws define the world we are currently living in. These laws also playing significant role in the future discoveries and related new tool definitions (Img.1.).

Img.2.: Codex Madrid I by Leonardo da Vinci - Device for Calculation :: Leonard's mechanism maintains a constant ratio of ten to one in each of it's 13 digit-registering wheels...

There is no surprise to hear the argument about the tools simplicity or easy to control which are reflecting the past compare to current situation.

Img.3.: Python-based open source toolkit for magnetic resonance connectome mapping, data management, sharing and analysis (http://www.cmtk.org/) 

Argument maybe true but it's omitting minimally two key variables.

1. The resources sharing variable which could be directly projected into any individual learning curve. 
2. Visualisation variable which helps faster connect system with purpose (Img.3.) and understand the role.

The increasing speed of the information sharing (massages exchange process) supporting the general fact that many current systems are becoming to be more and more distributed + complex.
Similarly to the visualisation needs which helps to connect situation to the appropriate state of art.  ps: At the mechanic age the visualisation was not a big issue as all parts were almost always clearly visible (Img.2.).

Such evolution process can be highly observable in the IT industry as the whole IT industry has cradle in Mechanical Engineering followed by Chemistry with taste of Physics (Computer Science).

The distributed systems (DS) design itself has also evolved (Img.4.) based on possibilities and needs according to the evolution time line. The design itself is connecting more different aspects together which makes whole design process complex, challenging and hard.

Img.4.: Client-Server ~ the centralised system architecture where both has communication Interfaces.  This relation can be also taken as the building cell of the much bigger system so it become to be "Client-Server Unit". This cell has it's own life cycle. 

What it a distributed system ? 
A distributed system is a software system in which components located on networked computer communicate and coordinate their own action by passing messages. The components interact with each other to achieve a appropriate goal. (link)

According to the distributed system definition that DS is the software (includes algorithms, data-structures, design patterns etc. ), we can move Server-Client architecture as the building cell of the another system (Img.4.) ~ "Client-Server Unit" (CSUnit). 

Img.5.: Traditional Three-tier architecture pattern - support different levels of abstractions.   

Even more because the current technologies state allows us to define both part ("Client-Server Unit") into appropriate tiers (Img.5.).  Those tiers could be evaluated and tested according to their purposes.  

How the client application could be divided into such tiers ? 
Good example shows AngularJS framework which is superheroic JavaScript Model-View-Whatever Framework (data-binding, Model-View-Controller or Model-View-ViewModel pattern) offering junit testing on the client side. 

The natural necessity of appropriate server functionality, stability... testing is self understandable independently on used technologies. 

Img.6. Possible Cloud Computing abstraction where individual process are invisible to the user (Laptop, Server, Desktop, Phone, Table) and result is provided as a service

Let's take a look at cloud computing as the services~product delivery and divide such "product" into general parts (applications, platform, infrastructure).
Each of those parts have their own definitions and over all when we take the Img.1. and do the extension, according to the cloud computing, we can can end up with new system abstraction (img.6.)

Every cell becomes to be it's own sustainable unit with its specific functionality and we should still keep in mind couple of questions that needs be answered : Cost, Availability, Reliability, Performance, Scalability and Manageability related with such new unit.

From general perspective in this model (Img.6.) aren't only presented "Client-Server Units", there is new unit type: "Client-Server-Client Unit" (CSCUnit) . 

"Client-Server-Client Unit" means that the server inside the CSCUnit maybe in the client position for another service at any time of its life cycle. Example of Peer2Peer technologies present in the cloud be Infinispan, scalable map-like data-structure distributed among the grid of servers. The Infinispan now plays the role of distributed memory without necessity of central coordination. 

As the final cloud system is obviously collection of different smaller parts another questions become to be more and more important then ever before eg.: individual system part transparency, communication related to others, how concurrency between them and how big is the resistance agains the any part failure (fault tolerance). 

Conclusion: I wanted to highlight relation between the mechanical engineering and IT branch evolution according to the new technologies which are coming continually on a market. I hope I was more then partly successful because the way how we look at Mechanical equipment and IT ones is sometimes question only about to changing view perspective (Img.7.). 

Img.7.: Leonardo da Vinci - Codex Madrid I - counting machine