Urgent Relocation from Amazon Web Services - Two Customer Stories

Locks touched many projects that work for the Russian market. Below is the story of one of the urgent relocations of our customer.

On April 19, they noticed the blocking of one of the IP addresses of their public service by part of the providers in the territory of the Russian Federation. On April 20, the situation worsened - the entire subnet became inaccessible. This dropped the test environment, one of the backup channels, partially disrupted mail servers. The problem was solved by replacing IP addresses, by proxying traffic through other data centers.
')
When it became clear that all this was serious and for a long time (or rather, when such a risk arose), one of our customers, Teco, an international processing company, decided to deploy an instance in our cloud. Their CIO was important large federation service, greater presence in the territory of the Russian Federation. Quote:

“The cloud in the Russian Federation gives more guarantees to customers that the service will not be blocked by RKN. The speed at which resources were provided to us was very important. Everything happened quite quickly: first of all, we added GEO dns for the availability of the service on the territory of the Russian Federation, we started proxying traffic through unlocked data centers. The slow part is federation for the database. ”

“There were difficulties with the technological stack that we use, it was necessary to build additional tunnels to a foreign cloud, faced with a problem in the work of new versions of strongSwan ... How much did it cost? Very expensive: in addition to direct payment for computing resources, there are significant spending of temporary resources to support several clouds, the lack of necessary Amazon / Google services. As a result, we work with an additional cloud, we incur much higher financial expenses. There are additional points of failure. Diagnosing problems has become more difficult. We use the IaC (infrastructure as code) approach, which allowed us to build a reproducible infrastructure based on Terraform, Ansible, Kubernetes. Depla infrastructure quickly passed. "

Second story

“We noticed, like everyone, from news. Some third-party services that we use in our work stopped working or began to malfunction. For example, Slack and Maven repositories. It didn’t affect our business directly - we have long been keeping the infrastructure that serves clients in the Russian Federation, with providers in the Russian Federation. We have known the Technoserv cloud for a long time and have accumulated some knowledge about it.

When choosing a cloud provider, in addition to the quality and reliability of the service, legal issues are important. The document flow in the case of a cloud outside of the Russian Federation is rather complicated, the payment involves currency control and tax subtleties. If a company works and does business in the Russian Federation, then the easiest way is to have all the infrastructure serving it there.

We worked with different providers in the Russian Federation, our team also has extensive experience working with the AWS platform and other world leaders in IaaS. From the cloud provider, we expect not just the ability to rent a virtual machine, but additional functionality that will simplify infrastructure support, such as:

• cloud storage and databases that allow you to save on self-sustaining complex solutions. It is important that they are built on the basis of industry standards, and not lead to vendor-lock;
• flexible pricing, which takes into account the peculiarities of our use of computing resources, allows us to really save. The approach of the provider, its readiness together with the client to look for ways of optimization is important;
• convenient infrastructure management tools - working with a samopinny control panel without an API is not always convenient.

In the case of Technoserv, we saw all the listed functionality, it became an important argument for us. Further testing showed a large supply of infrastructure performance Technoserv and the desire of the technical service to meet and debug together the bottlenecks of the infrastructure, which eventually ceased to be so. We migrated several services from other cloud providers to it, then we began to deploy new services in the Technoserv cloud.

It took us about a month to deal with the cloud storage and build a new platform into our existing network infrastructure.

There were problems with the integration of cloud storage, perhaps we were the first to use it in this model. However, we were satisfied with the work with support: colleagues helped us solve the main problems, and if necessary we connected the developers of the repository to correct errors.

As a result, we received a platform, which became the main one for us in the Russian Federation. We connected a number of tools that we use for data processing, such as Apache Spark and Apache Zeppelin, to work with Technoserv cloud storage. We were pleasantly surprised that full compatibility with AWS S3 API allows using existing libraries without any changes. In the case of Spark, the use of cloud storage for us allows us to avoid the need for HDFS clusters and save money on this without losing speed and reliability. ”

What's happening?

Because of the blockages, the second wave of migration from Amazon to Russian clouds began (the first wave was at the time of the start of the new regulations on the storage and processing of personal data, it, in fact, gave impetus to the Russian virtualization market). Most of our new customers need the most compatible services like S3 object storage. In Russia, only four cloud providers deliver this service and we are most compatible according to expert estimates (it should be noted, the assessment was made when there were three S3 providers) - CIOs choose our site.

Why not VPN or proxying? Because sustaining such a structure is rather difficult in the light of the same locks. Some customers were considering options for transferring the infrastructure to German servers, but, as you know, this operational solution did not help - the same Hetzner fell into the list of locks at once with the entire subnet.

The result - transferred to the Russian cloud. The reason is quite banal: since Roskomnadzor is a Russian organization, on the territory of the Russian Federation, he first warns about blocking, then gives time to take action, then blocks. That is, we can either allocate a “subnet” to “hooligans”, the blocking of which will not affect other clients, or ask them to stop working on the clause on interference with other clients of the public cloud.

We have open prices, under certain conditions, we are more profitable than Amazon. Here is the price .

“Nightmare” will not physically start us for a number of reasons of an organizational nature - we need a judicial decision, which takes quite a long time. But my colleague will talk about this a little later.

Since we have a rather flexible quantization, if the situation stops, it will be possible to switch back to AWS and keep with us an agreement for backup deployment. If it does not stop, well, there is a Russian data center, where the Amazon-compatible cloud is spinning. We help to move quickly and climb with minimum downtime or without it - depending on the architecture and volume.

The most frequent case of moving small projects now is either backup, stopping and deploying from our backup, or backup, deploying, synchronizing and disabling the first instance.

For any questions, e-mail: MBlinov@technoserv.com