From the Archives: About Data Clouds
Clouds in the sky are one thing, but clouds that separate users from data are another
These are three articles that I published in https://technoglot.blogspot.com on May 28, June 1, and June 8, 2012. I am putting all three articles together as they have a single topic and I see no reason to re-release them in three parts once again. I try to make my articles “timeless” as I try to work with “foundational” issues — that are hopefully applicable to current times. These articles are also available via Amazon in my compendiums.
Any edits (if any) from the original will be marked with []s. In general, these don’t seem to date themselves very much —- the problems keep marching on.
___________________
Once upon a time, I had a Cathode Ray Terminal (CRT -- similar to old televisions) that was connected to a MODEM (MODulator DEModulator -- a box that converted digital signals to/from analog signals on a phone line) which connected to a "mainframe" (very large -- for those days -- computer). My terminal, an ADM 3A, was a monocolor screen with a keyboard. No local processor, no local storage. When I logged into my account on the mainframe, I had my own set of files and access to any applications that had been installed on the main computer.
Now, with the computing clouds, I can have a computer (possibly without a disk drive/local storage) of, perhaps, limited computing power connected to the Internet which gives access to one or more main computers and multiple storage areas. I can connect via different devices and from different locations and get access to my own set of files and make use of various applications installed on those devices/computers.
It sounds very similar between 1981 and 2012 doesn't it? It certainly does to me. What are the differences that exist and what makes those differences?
The first is access speed. In 1981, connections were slow. A person could type in a set of commands (no Graphical User Interface (GUI)) and expect to receive back sets of words or numbers -- possibly some crude pictures made up of typeable characters. The terminal would allow some movement of the "cursor" (think of the marker from the mouse) after receiving special characters that would be interpreted specially. But, basically, it was for sending and receiving text.
In 2012, expectations of connection speed are FAST or FASTER. This means that the user can use a GUI and can receive back all forms of data including video, music, and multiple windows of information.
The second difference is primarily on the "mainframe" side. Via the Internet, the user has access to many different computers, different environments, and a multitude of applications. Thus, the user can treat the "cloud" environment as their own individual computing setup. Plus, since the computer that one uses usually has its own memory (even without a disk), work can be divided between the local computer/PC and the cloud devices.
From an outside point of view, 1981 and 2012 seem rather similar. The effect of access speed and the Internet's capability of hiding where and what is happening creates a very different experience.
Clouds have been around for a long time. No, I'm not talking about the groups of water droplets that sometimes are between us and the sky. The cloud has been the nickname for the general network for a long time. When a picture was drawn of two people talking together over the phone system, the picture usually had the originator (call this person 'A') talking on a phone which had a line to a cloud-shaped symbol which then had another line leading out of it to the recipient (call this person 'B') of the call. When a physical connection exists between A and B, it is called a "circuit-switched" line.
Over the years, what has actually been within that cloud has changed. Long, long ago, the contents of the cloud were a series of connected wires such that, physically, there was a single wire leading from A to B. In order to achieve this connection, various people ("operators") would use a small section of wire (called a "patch cord") to connect lengths of wire together. So, your local operator (which had ALL the local phone wires leading into the office) would connect your wire to a wire leading to a long-distance operator, who would then connect to the destination region, who would connect to a destination city who would connect to a local phone company who would then connect to B's line and then put a "ringing signal" on the line to tell B that they had a call.
The next iteration of content in the cloud was to replace part (then all) of the human operators with mechanical analog (no bits and bytes) switches. One switch type, called a "cross-bar" was an important development that allowed this progression to change. There was still, by the time a call was completed, a single physical connection from A to B.
The change from analog to digital allowed "breakage" of the physical connection. While there was still, after the call was completed, a physical connection, the form of the signal now changed from section to section of the connection. This usually meant a parallel line that contained "signal" information. The signal information includes such things as to whom the call has been placed, who made the call, when it occurred and (for billing purposes, in particular) how long the call was active.
Packet-switching broke the physical connection. Packet switching includes the address information (telephone number, etc) with the data (voice, video, music, ...). Since the address was included along with the data, it could be sent anywhere -- it could even be stored temporarily if a connection was unavailable. Finally, the Internet Protocol (IP) started to take over this type of combined address/data format.
However, when you make a call (or, access a computer or network service or whatever), you don't really know what is happening in the network -- and that is why it is still envisioned as a cloud. And, you don't really CARE how it gets from A to B as long as it gets there. It is likely to be a mixture of technologies and it just isn't important to A or B -- but it is vitally important to the providers of the network.
Modern "cloud" services rely on a packet-switched Internet Protocol network to allow access, storage, transfer, and interpretation of data. The next blog will talk about some of those specific services.
_____________
OK. We have seen that the cloud is a nickname for the potentially changing and somewhat mysterious connections that allow equipment (and people) to talk and send data to each other. The modern cloud will usually make direct use of the Internet Protocol (IP) network -- although that is not mandatory. The advantage to using the IP network is that each request can be routed to a different location.
In the old cloud, you basically had a direct connection (often called "point-to-point") between two pieces of equipment (possibly phones). With an IP network, since each message contains the address of the originator and the address of the destination, the resulting connections are "many-to-many". Your local equipment probably has a single IP address but the IP address is used in conjunction with another piece of information called the "port". The IP address identifies the physical device that is receiving and transmitting data and the port is used for routing the data to the right application or task.
What does this mean in real life? Let's say that you have a word processing application open and you also want to listen to music while you are typing on the document. The word processing app might be using a combination address of "53.13.18.01:2022" where the part before the colon (":") is the IP address and the part after is the port number. The music application makes use of "53.13.18.01:1954" (these are arbitrary numbers). Since the two apps are making use of two distinct ports, the data can be routed appropriately.
On the other end, the word processing app might be connected to "103.44.17.34:1113" and the music app is getting the music (data) from "87.19.33.92:1954". Note that the music app and its data are using the same port number -- it's not required but it does simplify some of the interactions. We can see from the addresses that we have two applications on a single physical device connected to two separate data providers which are likely on separate physical devices.
This is the power of the cloud -- the physical and logical separation of the data from the applications making use of the data. The data storage might be of music, documents, spreadsheets, ebooks, or whatever else you can imagine.
Next, what about applications in the cloud (sometimes referred to as "Software as a Service" or SaaS)? Well, actually, the data providers are applications and are interpreting the data coming from the "local" application in order to retrieve and route data appropriately. SaaS moves most of the processing of the data to the remote server. It isn't actually in the cloud but, from the point-of-view of the local user, it may still be located anywhere and, thus, part of the cloud from one endpoint's point-of-view.
Finally, the cloud can provide alternative paths and destinations. This can provide data transparent backup. Let's say that you have your endpoint making use of data stored at location C. Unknown to the user, C is constantly backing up ("mirroring") the data at location D. If the physical device hosting C goes down (is now unavailable) then the local app can be routed to D without the user even knowing anything has gone wrong.
The cloud provides many services and will provide even more in the future. However, with this complexity comes different types of vulnerability.
[Since 2012, the services provided by the clouds have just increased and become more complex. Since the speed of data lines has also continued to increase, it seems more like “realtime” where questions and answers seem almost to line up in time. There is so much available that wasn’t dreamt of in 2012. Most are due to the massive increase in speed both within the network as well as in the microprocessors commonly found in home computers. The underlying structure has changed only in the rapid ability to swap “servers” from one part of the solution to the next.]






A well researched piece of work