Introduction

A large part of the computer systems in recent years are moving to cloud services of various types. However, problems and glitches also began to appear, and technical issues also began to arise, as whenever new technology begins to catch on.

This article discusses the technical issues, and is intended for media people and information systems in organizations. You can read about the business-economic aspects in another blog where I publish together with Michael Pinchas, the author of the website Communication and Cloud Computing Solutions for Business, and you can read about the types of services, costs, business aspects and more.

Cloud structure, and challenges in working with cloud services

The structure of cloud services is basically very simple, with the whole idea being that our applications are installed on remote servers, in a local company, for example with ISPs, or in the cloud of one of the international giants, Amazon, Microsoft, Google and others.

Let’s talk about the simplest case, connecting a single office to the cloud, to working from a large number of branches in front of a single cloud and in front of a number of different Multi-Cloud clouds:

• Case 1 – A single office in front of a cloud
• Case 2 – Many offices in the country, facing a local or global cloud
• Case 3 – Many offices, in Israel and around the world, in front of a local or global cloud

But first, let us talk a little bit about protocols.

Structure and types of clouds

“Cloud” is just a number of servers installed on the site or remote sites, where in addition to a server that includes CPUs, RAM and Storage, infrastructures such as Databases (MS-SQL, MongoDB and others) can be purchased various services and applications, ranging from information security, load sharing (Load balancing), caching and organizing information on global networks (CDNs), to video servers with “pushing” the video to users and more.

When working in front of one cloud or another, there are two options:

1. To work with one of the local service providers. In this case the applications and information will be stored locally, and access to them will be in the bandwidth purchased, and in individual mSec delays. We will talk about the importance of this figure later. Depending on the types of applications we will be working on, it also makes a lot of sense whether the communication line is symmetrical or asymmetrical, as we will see below.
2. To work with one of the global service providers – Amazon AWS, Microsoft Azure, Google Cloud and others. In this case, we will work with servers and communication services at other sites in the world, until the establishment of local branches of the giants. Microsoft is already planned for 2021, Amazon on the way, also Oracle and many others, which will be very significant competition for local suppliers.

There are of course many other configurations, for example working with multiple cloud providers (multi-cloud), hybrid cloud i.e., working with services in our network (On-Prem) and cloud network (Cloud) and more. The technical aspects we will talk about are true of all the possibilities.

Applications

The applications that work in front of the cloud services are the same applications that we have been working with since time immemorial. These applications will be:

1. File storage, including work in Office, work in TBM (large files) applications, graphic/video files, etc.
2. Working with Databases – in Client, HTTP or Terminal/Citrix
3. Voice/Video/Multimedia services

File storage

In file storage we will work on a number of options. In the first option we will work on transferring / saving files via HTTP, when we are of course working over TCP. As I explained in previous articles, the formula for calculating the transfer rate (or the rule of thumb, because TCP has been upgraded several times since the formula was coined):

When RTT is the time between sending TCP Segment and getting the Acknowledge on it, which also depends on Delay on the communication line. That is, the higher the delay, the lower the transfer speed. If we are talking about file storage in Europe (50-70 milliseconds) or USA (150-200 milliseconds), then there is a built-in slowness in file transfer, and even if we take a very wide line to the Internet (on the way to cloud services), this limitation will slow down Our work.

Another important issue is that in Google we will work with the QUIC / GQUIC file transfer protocol which are file transfer protocols over UDP developed by Google themselves and will work significantly faster than the standard protocols.

Another thing, depending on the way it works, if it is about saving and opening files, it is important that the communication line to the Internet be symmetrical, ie the same in both directions (50/50, 100/100, etc.).

Another thing, depending on the way it works, if it is about saving and opening files, it is important that the communication line to the Internet be symmetrical, ie the same in both directions (50/50, 100/100, etc.). Quite a few small clients who came to us connected asymmetrically to the internet, with upload speeds of 4Mbps or 5Mbps and did not understand why saving a file takes minutes or tens of minutes.

Working with Databases

When working with Database, there are three main forms of work – Client / Server work, HTTP access or Terminal / Citrix access. Each method has advantages and disadvantages, and here too the delay factor is significant.

1. Working in Client / Server – Here there is a Client that exchanges information with the Server. Too many packets moving between them when the server is a few tens of milliseconds or more can be problematic and slow down the work.
2. Working in Terminal Server or Citrix MetaFrame (XenApp) – here the way it works is that we actually type on the server, when what we see is the Echo to us on the screen. I had a few cases that worked this way in front of the Database, when the typists typed very fast, and since the Echo came back to them from remote servers (70-80 milliseconds or higher), it took time for the Echo of the letters to come back from the server to local computers, and the typists complained That they write and the writing is very slow.
3. Working in HTTP, when accessing a WEB server on which the client working in front of the server is installed. This is usually the most efficient and common form of work. You just need to take care of it (and also pay the cloud provider) to have a powerful WEB server that will access the database server and both will be installed at the cloud provider.

Voice / Video / Multimedia services

In simple Voice / Video services, i.e. phone calls or video calls, what we see working in the cloud is exactly what we see in services like Microsoft Skype, Google Hangouts and dozens of other services. Since the signaling will work in SIP from the exchange from which we purchased the service to the exchange to which the call destination is connected, and the call will be conducted in RTP anyway, then the quality of the call we receive will depend on the quality of the line between us and the destination. Reasonable quality and more.

When the demand is for high quality calls, which is required mainly in video calls, regular or conference calls, we will in any case need dedicated lines between us and the other destinations in the world, a topic I have expanded on in other blog articles. In local calls it will usually not be a problem to have a high-level call through the internet as well.

Communication protocols and how to work in the cloud

Let us see a few examples of file transfer, working in Database and watching video:

File transfer

When transferring files over TCP, we usually see several packets in the transfer direction, and Acknowledge in the opposite direction, as in the following example (downloading a printer driver from the HPE website):

The picture shows Packets 3118-3134, but if we consider a file of at least a few Mbytes, which will take thousands of Packets to bring to us, when after every 2-3 Packets also get Acknowledge back, then it is clear why the high delay download will take time.

In the download rate graph, we see that we reach a download rate of about 0.8-1.8Mbps on average, as seen below:

This is because of the high delay, as seen in the IO Graph below:

Although the line is 100Mbps we got a low download rate, due to the very high delay.

The same problems will occur if you work in FTP as in Example, HTTP or NetBIOS / SMB. In the case of using portals (e.g. SharePoint), caching, CDNs, etc., the physical location of the files, and where we access them, is important. The closer they are to us (in terms of Delay), the better performance we will get.

In Google GQUIC (next image), we see a transfer over UDP, when we see a large amount of packets in the server direction (file saving), and only after 8-10 packets do we see a repeating packet. Of course, the header size in UDP is also smaller than in TCP, which also improves the file saving speed.

Work in Database

Even when working in Databases, when working in Client / Server, the issue of delay is critical. In the following example we see Client work versus Server:

And here too, although the Delay is relatively reasonable (tens of mSec’s), because for a particular Query the Client passes thousands of Packets in front of the Server, we will get the result of that Query after a long time.

Summary:

When we move our computing or part of it to some cloud service, it has advantages, there are disadvantages, and there are things to pay attention to. It’s not that we’ll move to the cloud, all the problems will be solved, prices will go down and everything will be fine. We need to prepare and understand what we do and what we buy (as always ..).

Beyond the different types of services, there are also the technical aspects that need to be aware of, such as bandwidth, delay, the types of applications we transfer to the cloud and more. Many times the main considerations in moving to the cloud are business / economic considerations, but there are also quite a few technical considerations that need to be considered, a small taste of which I have tried to give in this article.