Potential Problems When Switching To Multicloud Native Service And How To Avoid Them

Of course, the Multicloud Native Service approach has its pitfalls. Below is a list of the most common problems and how to solve them:

Network Delays

Suppose your system prioritizes low latency, for example. In that case, you require synchronous database replicas, then most likely, the combination of local and global providers will not work for you due to their territorial remoteness. You should choose providers that can provide minimal latency, for example, over a dedicated Direct Connect channel. It can be two local providers in the Russian Federation or a combination of a local cloud provider and private infrastructure. Some global providers also allow Direct Connect.

If for your system, a slight lag in the data, measured in minutes, is not critical, and asynchronous replications are acceptable, then the use of global providers is quite possible.

Compute Performance Difference

The combination of different providers is fraught with the fact that the power of the equipment used in them will be very different. Therefore, when choosing a provider and subsequent tuning of VM configurations, it is important not to allow strong discrepancies in the performance of resources used in different legs. The type and frequency of processors, size, bandwidth and amount of latency on disks, size of RAM – all these and other parameters should be approximately the same. Otherwise, the processing of data in two arms will turn out to be extremely uneven.

Vendor Lock-In

This is binding to the services of a certain cloud provider, which makes it impossible to change the provider if necessary quickly.

The easiest way to explain the Vendor lock-in problem is to use the Architecture References offered by most of the leading cloud providers as an example. These architectures describe ready-made solutions (combinations of components, their interconnections, and so on) for typical architectural problems that may arise when moving to the cloud. 

Reference Architectures From Google And AWS

Reference architecture from AWS for processing logs, which are subsequently used to build monitoring. From the figure, it is obvious that to solve an architectural problem; the provider offers several of its proprietary services at once: AWS Lambda, Amazon Kinesis Data Streams, and so on.

Suppose you followed the provider’s recommendations and built a beautiful and fast solution based on its services. But what if in the future you need to change your provider? That’s right; a lot will have to be rewritten from scratch. You will waste time and, in fact, have to do double work. And besides this, you can give way to competitors who, finding themselves in a similar situation, will change the provider faster if they do not use proprietary services.

This does not mean that reference architectures are harmful, and there is no point in using them. On the contrary, they can and should be applied in practice. I myself often refer to them. But always try to avoid proprietary services and take only generally accepted ones from other providers. This recommendation is also relevant when using one cloud provider.

Which Provider To Give Preference To

In the previous sections, we determined that it is best to use a couple of different cloud providers to build fault-tolerant applications. But how to make the right choice out of the many options available in the modern IT market, what opportunities does the ideal provider offer? And also, what services should you focus on in order not to fall into the Vendor lock-in trap?

In my opinion, the gentleman’s set of a modern cloud provider should look something like this:

1.Implementation Of The IaC (Infrastructure as Code) Approach

In most cases, this implies support for Terraform, but not necessarily.  Cloud Solutions employs a standard Terraform provider; you can also use our own Terraform provider to modify our platform’s infrastructure. It also necessarily includes the management of the life cycle of virtual machines (Virtual Machine Lifecycle Management).

2.Well-Documented CLI And API

Essential for fast and easy management of cloud resources.

3.DC Connectivity (Direct Connect)

This is setting up a dedicated network connection between the cloud and your own data center or office to provide an isolated network connection and increase bandwidth and provide a more robust experience than an Internet connection. In this case, the level at which the connection is configured is not critical (L2, L3).

4.CDN (Content Delivery Network) Support

Leveraging the geographically dispersed network infrastructure that underlies CDNs, content can be quickly delivered globally with millisecond latency, even during peak loads

5.Availability Of DNS And Network Load Balancers

This is an important part of configuring any virtual network.

6.Compliance With Local Regulations And Other Certifications

For example, PCI DSS, ISO 27 *, GDPR for Europe, FSTEC for Russia, and so on. This will help avoid additional localization headaches.

7.Technological Correspondence Between Providers

If, for example, your source infrastructure uses VMWare, it makes sense to choose a provider that provides the ESXi hypervisor, preferably the same version. This will greatly simplify the migration. The same is true for other platforms and hypervisors. The requirement is optional; you can accommodate on different platforms.

8.Main Service Pool Support

• Containerization / orchestration (generally recognized K8s or OpenShift standard);
• Databases as a service;
• S3 – object storage for storing large amounts of data and static content;
• Message queues (Simple Queue Service, SQS);
• Big Data – you should be careful with this service so as not to get Vendor lock-in, as some providers implement it in their own way;
• Monitoring infrastructure and business metrics, ideally the monitoring service should be independent;
• Serverless computing (Function as a Service, FaaS). Indispensable for handling unpredictable stateless load (chatbots, social media, etc.)
• Audit as a service;
• Standard functions of the type of billing, information security services (such as WAF, AntiDDOS, the ability to conduct information security audits), the ability to use IDP, RBAC;
• Choose a reliable Global Server Load Balancer, do not rely only on balancing at the cloud provider level, as it is subject to the same risks.

Also Read: Cloud And Connectivity The Technological Revolution Of 2021