Who should NOT move to the cloud and why

Last time I talked about the myths of the transfer of IT infrastructure to the cloud. And the last of them was that far from always something needs to be transferred to the cloud. I want to dwell on it in more detail, because here history is often confused with “it’s difficult for us to be organizational” and “we don’t need it for technical reasons”.

The first reason - someone has already managed to buy iron. It often happens that a new CIO comes to an organization and sees the following picture: six months ago his predecessor bought the equipment, it is still on support and guarantees and will work for three years stably. Naturally, in this situation it is necessary to build everything on it simply for economic reasons.
')
A more difficult situation is when someone bought the iron 20 years ago (I'm not joking right now), but it is still needed. More precisely, you need something that is compatible with it. I saw software that was written 15 years ago, 20 years ago, and even 25 years ago. The one who wrote it, has long been dead or not working. And this, for example, is a register in a state structure on the mainframe or a bank code that is tied to the microinstructions of a particular processor line or specific OS functions. There are no sources. Documentation only for use. If you're lucky.

So, if someone says that it can be taken, reversed and rewritten in a modern language, spit in his face, step on his back and jump.

In general, almost everything is not x86 (including modern IBM POWER) is the path to its own iron infrastructure or complex hybrids, when the main services in its server node or data center, and the external "marketing" - outside in the cloud. By the way, many designers (especially on VDI) need video cards. There are video cards in the cloud, problems with them are minimal. Problems with non-standard kernels and old OS.

The following history of binding to the existing equipment is a merger-acquisition of companies. Imagine that in a month you absorb a company of almost the same size as yours, only a competitor. They have their own IT team, their own CIO, their hardware and their processes. And they will obey you. And all this together in three months should work as one system. The size of hemorrhoids and the smell of burning deadlines can be presented by yourself.

At this point, you get a lot of iron from another information system - and it's strange to throw it out. Therefore, virtualization is often delayed and integration begins.

Brave security officers are the next reason that sometimes you don’t need to go to the cloud. There are those who, under the IS regulation, cannot move to a virtualized environment at all, even to private clouds. There are those who can in theory, but it is difficult and too bold. This is primarily about banks, because their security standards have been written for quite some time and are partially tied to hardware.

For example, in communicating with one large bank, or rather, with its security guards, it became clear that banks and other credit organizations are regulated, in terms of protecting information, not only the FSB and the FSTEC, but also the most significant regulator for them, which is the CBR. The latter is much more terrible for them, since, if the first two issue prescriptions and impose fines, the Central Bank of the Russian Federation has broader powers. So, in the CBR regulations, under the abbreviation STO BR, there is a provision that calls into question any possibility of placing banks in the clouds. It says there that "Information containing bank secrecy should be placed on equipment belonging to a credit institution." That is, everything that contains banking secrets should be placed on the bank’s equipment, and that’s all the bank’s business systems, which make up 90% of its IT. It turns out that only peripheral systems in the minimum volume can be placed in the cloud. There are brave people who interpret the conditions without waiting for the clarification of the Central Bank or another regulator, but in fact very few people decide on this. In open sources there is information about placement in the clouds of some banks. For example, Telekommertsbank, with all its systems located in the cloud, and the Opening Bank uses clouds for a part of its systems. And no problems as far as we know they did not have. And yet, for most of these enterprises, IT does not control the requirements (they come from above), so there is only one thing left to do — obey.

Even more interesting is the situation in the defense sphere. There, the requirements can be fulfilled and they are quite unambiguous, but this execution will cost so much that it is easier to build your own data center or server node. Defense research institutes build internal clusters. This is generally very advisable - given that in the cloud each technical support employee, while exaggerating, would have to register the admission and the absence of leave for five years. Just for the fact that he serves the server, seeing in general nothing but his address. Secrecy and state secrets are not a story for public clouds.

Requirements for IB relate to completely "civilian" companies, that is, the commercial sector. There are two situations:

• The requirements are set by the parent company, for example, in Europe, and the branch in Russia can only submit. No matter how stupid these requirements are, they are the law. And we must do as it says.
• There is a large group of companies that are doing something important. For example, mines diamonds or melts ore. They have very strict security requirements. Inside the group of companies there are much more “mundane”, for example, confectionery production or some simple shops. They inherit these security requirements, since no one will do anything for them separately. It remains only to obey. Again, no matter how stupid these requirements are - they are the law. And we must do as it says. I know a situation when the head of a similar company did not see the CIO of the holding ever in his life and worked from him for two thousand kilometers. This is normal.

Another serious reason not to move into a commercial cloud is a large-scale service. When software starts to work a little better on specific virtual machines with a specific ratio of memory to the processor, and you need several thousand or even several tens of cores, it is better to build your own cloud. With all the overhead costs, it will be cheaper at a certain scale. We are now talking about social networks, search engines, financial structures and about everything that develops the application layer for itself. They make the most of everything that they can get from the equipment. They can rewrite the OS for network devices and often test new architectures. No one in the cloud will do this, naturally.

The last objective reason for medium and large companies not to move to the cloud is the cost of licenses. Why do not touch small - they either do not have such application software and DBMS, or they use free solutions, or simply steal licenses. We don’t know, because the hypervisor doesn’t see what happens on the cloud machines any further.

But there are vendors who impose licensing requirements, which in fact simply block the use of their products in the cloud. For example, they oblige the user to purchase a separate license for each physical processor that is installed in the provider’s cloud.

Example. There is one server for 48 cores. You give when setting up VM 8 cores and are going to be licensed by them. The vendor says: let us pay a license for all 48 cores, but then suddenly decide to expand the VM. That was earlier. In the clouds it is even more interesting: if there are 100–200 servers, and 4,000 cores, pay for everything. And then suddenly you are migrating from one core to another in the course of the play. You have to pay for it too!

Microsoft offers the intermediate option, it requires the provider to pay for the number of cores, but clients can then run any number of virtual machines with OS on these servers (that is, we pay once), this is a much more realistic scheme for the provider. There is a fundamental difference.

Now let's get to biased reasons.

Stereotyped corporate culture is a factor “I do not believe in clouds”. When it is “I do not believe”, this is a biased factor and soon the invisible hand of the market will make you believe. Another thing is when this is a requirement of the Security Service or the regulator or the head office in Europe - this is what we discussed above. Then this is an objective factor, even if you personally do not want to agree with him. We end the meeting: “Okay, let's go back to the question on March 22, 2021 at 14:00. Planning a meeting? ”

There are people who budget only for capital expenditures, without operating rooms. This requirement can often be circumvented, because you can buy a cloud as CAPEX, paying for the period immediately. There are even a whole bunch of external companies that are engaged in such operations for many structures.

Government agencies, by the way, often talk about different budget items, but in reality it is possible to reallocate funds between items. Indeed, it is difficult, but possible, if you do this in advance when planning a new fiscal year.

Sometimes you can simply redistribute the budget - and everything will be fine. And most often, the CIO manages this.

Someone ran into a cloud that does not work well. In Russia, for example, we have one large cloud structure, which falls, like winter crops, every two months. People have cursed them a thousand times, but they continue to make contracts and fall. The same Amazon also falls due to storms on the US coast or lightning to data centers, but offers many points in different geographic locations. The moral is to choose the right supplier. The second question is that many are mistaken on architecture. It is difficult to build architecture. It is necessary to reserve, test, it is necessary to approach risk assessment and critical sites to reserve many times. This requires professionalism. Here my colleague from exploitation tells how it looks in the real world .

The story is simple: when you are a payment aggregator and thousands of transactions per day pass through you, and placing in only one region of the Amazon is possible, someone is an idiot. Because a simple service threatens with losses for six months and must be placed in two different clouds or at least at two points of the Amazon. There is a risk model - you have to work with it.

Many believe that they will make a data center, build a private cloud, resell it to others and pay back the results. Seriously, I know a couple of examples. People are afraid at the level of insanity that someone steals their data, that there are admins in the cloud and that they will read traffic and steal data.

About admins have already disassembled: beyond the hypervisor just no one sees. If you are paranoid, encrypt everything and do not keep the encryption keys on the cloud servers. We educate our customers about such architectures and recommend them. This, of course, will impose costs, but you can only encrypt the critical one.

The biggest fear here is that when the court asks to upload the data, the cloud provider must obey. It happens sometimes. The answer is very simple: if someone “nightmares” your business, it will not begin with IT. It will start with checks, product delays and so on. If all this goes into the sweet stage of the struggle in IT - with weaning equipment. It is much easier to come and pick up the iron server than to upload data from the cloud: people who are professionally involved in this are well aware that a number of modern technologies allow one way or another to distort data discharged from the server to external media.

What is more effective - that the chief accountant will be put in the bullpen and he will surrender all? Or that during the search equipment will be taken from the office? Or what will force the cloud provider through the cloud to issue? Practice shows that the third scenario is less likely than the first two. In the third, we still have to interact with the third legal entity, make official requests and so on. Again, there are chances to get a dataset without keys. And one more thing: it does not happen that the customer does not know about uploading data from the cloud. If we are not talking about force majeure at the state level, then this is not just a letter, but either a court sanction, or a reasoned request of law enforcement officers (and only those who have the authority to do so). And the customer usually knows that such things have been going against him for six months already. Just imagine: you need to know what data is needed, where you are, you need to get an official decision. If the customer does not know, this is a very strange story. And the server from the office would have been taken long ago.

In general, when discussing the infrastructure, our task is to find out what hinders the relocation. If this is an objective reason - “see you in 5 years”. If not, the work of a psychologist and a financier begins. And another guy who is responsible for educational programs about the twenty-first century - for example, a post about the kind of illiteracy we face .