Amazon Web Services Urgent Relocation - Two Client Stories

Locks affected many projects working for the Russian market. Below is the story of one of our customer’s urgent relocations.

On April 19, they noticed the blocking of one of the IP addresses of their public service by some providers in 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 the operation of mail servers. We managed to solve the problem by replacing IP addresses, proxying traffic through other data centers.

When it became clear that all this was serious and for a long time (more precisely, when such a risk arose), one of our customers, the Teko company, an international processing company, decided to deploy an instance in our cloud. Their CIO was important more federated service, a greater presence in the Russian Federation. Quote:

“The cloud in the Russian Federation gives more guarantees to customers that the service will not be blocked by ILV. The speed with which we were provided with resources was very important. Everything happened quite quickly: first of all, we added GEO dns for the availability of the service in the Russian Federation, and started proxying traffic through unblocked DCs. The slower part is the database federation. ”

“There were difficulties with the technological stack that we use, it was necessary to build additional tunnels to the 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 is a significant expenditure of temporary resources to support several clouds, the lack of necessary Amazonian / Google services. As a result, we work with an additional cloud, we bear much greater financial costs. There are additional points of failure. Diagnosing problems has become more difficult. We use the IaC (infrastructure as code) approach, this allowed us to build a reproducible infrastructure based on Terraform, Ansible, Kubernetes. Deployment of infrastructure passed quite quickly. ”

Second story

“They noticed, like everyone else, from the news. Some third-party services that we use in our work ceased to work or began to malfunction. For example, Slack and Maven repositories. This did not affect our business directly - we have been holding the infrastructure that serves customers in the Russian Federation for a long time with providers in the Russian Federation. We have known the Technoserv cloud for quite some 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. Document flow in the case of a cloud outside the Russian Federation is quite complicated; payment involves currency control and tax subtleties. If a company operates and conducts business in the Russian Federation, then it is easiest to have all the infrastructure serving it there.

We have 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, which allow you to save on self-support of complex solutions. At the same time, 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 features of our use of computing resources, allows us to really save. The provider’s approach is important, its readiness together with the client to look for optimization methods;
• convenient infrastructure management tools - working with a self-written control panel without an API is not always convenient.

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

It took us about a month to figure out the cloud storage and build a new site in our existing network infrastructure.

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

As a result, we got the site, which became the main for us in the Russian Federation. We have 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 the AWS S3 API allows you to use existing libraries without any changes. In the case of Spark, the use of cloud storage for us eliminates the need for HDFS clusters and saves money on it, 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 the new standards for the storage and processing of personal data started, it, in fact, gave an 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 provide this service and we are most compatible according to experts (it should be noted that the assessment was done when there were three S3 providers) - CIO choose our site.

Why not VPN or proxy? Because it is rather difficult to maintain such a structure stably in the light of the same locks. Some customers were considering options for transferring infrastructure to German servers, but, as you know, this operational solution did not help - the same Hetzner got into the list of locks immediately on the entire subnet.

The result is to be transferred to the Russian cloud. The reason is quite banal: since Roskomnadzor is a Russian organization, in the territory of the Russian Federation it first warns of blocking, then gives time to take action, then blocks. That is, we can either give the “hooligans" a subnet whose blocking will not affect the other clients, or ask them to stop the activity 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 list .

Physically, they won’t start to “nightmare us” for a number of organizational reasons - a court order is needed, which takes quite a while. But my colleague will tell about this a little later.

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

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

For all questions, write to the mail: MBlinov@technoserv.com