From a Computation Machine to a Coordination Machine
In this article, I reason about the usage of a new reference idea for dealing with computational resources which best fit with the reality of cloud computing.
Join the DZone community and get the full member experience.
Join For FreeToday there is a huge amount of technology for dealing with different aspects of cloud computing. In particular, containerization and microservices lead us to think of software applications as distributed applications whose components can be easily deployed and moved in the cloud. In my opinion, what we are facing today is a revolution that is not only a matter of technologies, it is something so profound that it can alter the way we conceive software and software infrastructures.
My idea is that we need new abstractions and concepts for dealing with such a revolution. In science, we are always looking for the best model which captures the essence of reality. We are doing this because on top of that model we can build the right technologies for satisfying our human needs. The same happened in computer science from the beginning when researchers started to automatize the ability of the mind: calculation. From that moment, the calculation machine has been always used as the basic reference for dealing with automatic calculation, and on top of this model, different technologies have been developed.
In this article, I start to reason about the usage of a new reference idea for dealing with computational resources which best fit with the reality of cloud computing, instead of the traditional computing machine model: the communication machine.
From a Machine Built for Computation...
Historically, computer machines were developed for automatizing computation. Starting from abacus to modern computers, the main idea behind computer machines was to increase the power of human brain computation with an external device. Computation machines were theoretically modeled by Alan Turing using his Turing machine and their basic architecture was proposed by Von Neumann.
The Computation Machine Evolves to Virtual Computation Machines
From that moment to today, computer machines have been improved to increase computation power. More memory, more CPUs, more computation frequency. The computation abilities of the real machines became so powerful that virtualization became a possibility. A single real machine today can run hundreds of instances of virtual machines that can be separately sold. The increasing of the virtualization market is quite interesting because it means that, in general, for commercial purposes, we do not need all the computation power of real machines, but we need less computation power that must be easily available. Virtual machines have the great value that can be modified in a few minutes in their basic parameters like memory, number of CPUs, disk storage, etc
The most interesting aspect of a virtual machine is that it is not a real machine made with hardware components, but it is a software that provides the illusion to have a real machine. This is not a detail. This is proof that there exists a cloud layer that provides us the abstraction of a computer machine that has the same behavior as a real machine. This software was made in this way for giving to system administrators and developers something that was the same as the computer they used to deal with but remotely deployed.
Containerization and Serverless
Recently, such an evolution from real computational machines to virtual machines has taken another step forward: containerization. With containerization, we finally abandon the illusion to deal with a full-featured computational machine but we deal with a configurable computational box instead.
Each container is specialized with the minimum technology stack for executing the application it hosts and unnecessary functionalities are not installed. Since we are free to configure the execution stack inside a container as we prefer, we can choose the technology we like for developing the application by taking care to use standard protocols and formats for achieving communication with other components. This is an important point because each container can be immediately associated with its external observed behavior (the functionalities it provides at the declared endpoints). Such a statement is so strong that we could say that a piece of our computational infrastructure (the container) is just denoted by the functionalities it provides (the software). What is becoming more and more important is the governance of the interactions among different containers instead of the programming of the computation inside.
An extreme consequence of such an approach can be seen in serverless architectures where the developer just focuses on the software functionalities leaving all the deployment aspects and resource allocation issues to the cloud provider. In this extreme case, the computation machine does not exist anymore, it just becomes a matter of used time and memory. The only problem with such an approach is the high level of lock-in to the specific cloud provider architecture: we are forced to use the technologies chosen by the cloud provider. On the contrary, containerization technologies leave us more flexibility because they permit us to select the technology for expressing computation. This is why, in the following, I will continue my reasoning using containerization as the final reference for the new machine by skipping serverless computing that can be considered as a special case of what I am gonna say.
To a Machine Built for Communication
Before continuing we could summarize what I have said so far in the next picture.
Today, when we are dealing with a cloud provider, we are still able to see the virtual machine abstraction level, but tomorrow we will soon just access only the containerization one (a lot of platforms are already doing this). At that moment, virtual machines will stop to exist and there will be only containers: a sea of computational boxes that run software functionalities. They will be the new computational layer we will have to deal with. There will be no bits to program in that case, only communication.
The new machine indeed will be composed of huge amounts of components that must be connected to obtain new applications and software functionalities. Make these components communicate with each other properly and correctly will be one of the main tasks of a developer. In that scenario, communication and coordination will become more important than computation.
Such a concept is not new, in the 80s Robin Milner introduced CCS (calculus of communicating systems) that provides a mathematical framework where computation is achieved by programming communications among the processes. In the same years, other calculi have been proposed for modeling communication systems. The only new thing we are facing today is that the communication machine is becoming a ubiquitous mass available machine for everybody, instead of a special tool used in a research laboratory. Containers are the building blocks of such a machine, and the programmable bits are the communication among them.
New Technologies for a New Machine
If we accept the idea that we are facing a revolution at the roots of computation, we can start to change the way we are approaching the new communication machine and its related technologies. The big challenge we have to deal with is trying to find better technologies for programming such a machine. API Programming, Architecture as a Code, Service-Oriented Computing, Microservices, Choreographies, etc. are just some of the keywords we need to take into account when we are reasoning about the future evolution of the technologies for the communication machine.
I am writing this article because of the experience I matured in collaborating at the creation of a new programming language (Jolie). We started from the mathematical foundations of the CCS adapting it to the service-oriented model. Jolie is a language where communication primitives come at the same level as the computation ones. What we have seen in Jolie is that having built-in primitives in the language can make communication and coordination easy, cutting time in the development and maintenance phases. It happens because some programming aspects are not offered by external libraries but they are already crystallized in the language. Moreover, developers require fewer skills to develop a distributed service-oriented application because they just have to know a programming language instead of a set of libraries and frameworks.
We are just at the beginning of a new era of Computer Science and everything could change rapidly but something is quite sure: we are going to completely change the way we are programming applications today.
Opinions expressed by DZone contributors are their own.
Trending
-
5 Common Data Structures and Algorithms Used in Machine Learning
-
Java Concurrency: Condition
-
Building a Flask Web Application With Docker: A Step-by-Step Guide
-
Decoding eBPF Observability: How eBPF Transforms Observability as We Know It
Comments