Single, Poly, Multi and Hybrid Cloud - Let's pin down the strategies

Posted on May 25, 2022 by Debashis Malo

Cloud is inevitable! Let’s agree to that.

Cloud platform offers an adaptable business and IT strategy to organizations, to remain competitive, and meet business needs in this ever-changing market. There are many reasons to rationalize this claim. However, to cut a long story short, we can say that cloud platforms provide cost savings, enhanced productivity, and the ease of scaling enterprise operations.

But please wait before jumping onto this attractive proposition. There are many cloud strategies which we need to carefully explore before choosing the right one. Otherwise, it may lead to many inescapable challenges.

In this article, I will provide a bird's-eye view on Single, Poly, multi and hybrid cloud. Also, I will try to explain vendor lock-in with some examples.

Single Cloud:

Single Cloud means you are using only one cloud provider for your enterprise solution. In an ideal world, a single cloud solution is ‘better secured’ as it can provide consistent approach towards cyber security for the organization. Also, single cloud is easier to orchestrate and administrate. This also provides ability to leverage unique specialized offerings from the vendor. ?You can optimize the workload as the various cloud services work best within their own cloud Platform. Some small and medium level organizations may have strict budget constraints. They must deal with low budget proposition. So, the more the organization uses one cloud vendor, the more discounts they may be offered. Therefore, Single cloud would be their strategic choice.

But there is a flip side of using Single Cloud. The three major Cloud Service Providers (CSPs) have a slightly different set of their cloud services and specialties. Opting for a single cloud service provider limits the organization to the service offerings of the solo provider, which could impose limitations on their flexibility if they want to expand beyond those core capabilities.

Though rare but an outage does happen even to major CSPs which can impact the business in undesirable ways. Hence, organizations often worry that using a single cloud provider might create a single point of failure (SPOF) in their environments.

Another critical aspect to be thought of while using single cloud is called Vendor lock-in. Though Vendor lock-in doesn’t always necessarily associate with cloud technology.?It can happen within your on-premise infrastructure or applications too.?

Vendor lock-in refers to a situation where users are locked to a vendor and will not be able to migrate data and IT workloads from one technology stack to another, between competing vendors and geographic locations. It is usually the result of proprietary services that are incompatible with those of competitors.

Let’s see some of the Vendor lock-in examples. You must have noticed particular charger lead for One Plus phones. You can’t use any other phone charger lead for charging One plus phones. Similarly, iTunes in the early days of the service had similar issue. Music purchased via iTunes could only be played using the iTunes application or on an iPod. Now Apple is reportedly using new proprietary software diagnostic tools to repair MacBook Pros and iMac Pros. It would seem that, without the proprietary software, third-party repair services will not be able to fix MacBook Pros that suffer from specific issues. The measures are presumably there to ensure security though.

Another common pitfall can be let’s say you have a superior IT department. It might sometimes be irresistible to design your own integration solution using different services with your own available software. In near future this custom integration solution may become a blocker for many reasons. Sometimes, you build the integration solutions which is tightly coupled with your legacy applications, or it may have a point-to-point approach to achieving a faster development. It may also not be scalable to a multitude of applications for future considerations. One way to solve this problem is to introduce highly sophisticated cloud integration platform team, but that requires investment and know how beyond just simple integration.

Let’s talk about AWS DynamoDB. It’s a fully managed proprietary NoSQL database service that supports key–value and document data structures and we love it. You have used DynamoDB in your cloud-based application. Now let’s say for some hypothetical reason you need to switch to different cloud vendor. You have your application tied to DynamoDB APIs from which you can’t decouple your code for migrating to different Vendor platform. It can create real difficulties during the migration process.

Having said that there are some best practices which we should consider when avoiding Vendor lock-in. I will discuss in a separate article on how to avoid Vendor lock-in. ?

Poly cloud:

I personally find this approach interesting. Sometimes Poly cloud is often misinterpreted as multi-cloud. However, there are key differences. In Poly cloud strategy, we can address a use case by running specific pieces of workloads on different cloud platforms instead of using single cloud. Poly cloud is a smarter strategy which is useful with the advent of serverless computing. For example, your warehouse might be on Google BigQuery, but you may be using an architecture where you want to load your AWS Kinesis data to Google BigQuery. Another example can be you keep your application database in Azure due to certain organizational policy, while you are running your API in AWS Lambda which is in line with some AWS S3 events where AWS S3 is your data lake.??

Again, every smart thing comes at a price. With Poly Cloud you may suffer from increased latency as you must rely on the cloud-to-cloud vendor connectivity. Also, different vendors availability may be a concern. Outage on one vendor can cause other parts of the application to stop performing. Therefore, this is also obvious that Poly Cloud is going to be a costly affair. Though in theory, Poly Cloud may look lucrative but in practice this is still not matured to be an optimized approach.

Multi cloud:

In a Multi-cloud approach, you are running the same workloads on multiple cloud providers. Multi-cloud architectures aim to eliminate this SPOF (Single Point of Failure) by enabling the rapid shifting of workloads between cloud providers. This can be a good approach for disaster recovery where your organization is running critical application and your IT doesn’t really trust any single Cloud Service Provider’s claim on their outage policy.

However, there are some downsides of using Multi cloud approach. While using Multi cloud approach you must balance your architecture to use common resources across cloud vendors to achieve compatibility between vendors. You will not be able to leverage the specialized value-add services from specific cloud vendor. Otherwise, architectural replication of these services in other cloud would be difficult. Of course, this is more of theory as yet coz this is going to be challenging and complicated to implement.

Hybrid cloud:

Hybrid cloud is like Poly cloud but there is a slight difference in approach. It refers to cloud deployments that integrate more than one cloud. A hybrid cloud infrastructure combines two or more different types of clouds, while Poly cloud combines different clouds of the same type (public-to-public). If the poly cloud deployment includes a private cloud or an on-premises data center/infrastructure, then the cloud deployment can be considered as hybrid cloud. For example, a hybrid cloud combines public cloud computing with a private cloud or on-premise infrastructure.

In this approach some business processes or services can be partly migrated to the public cloud. While other processes, and data storage still take place in legacy on-premise infrastructure. Sometimes a private cloud can be an internal data center. There are many reasons for which organizations may choose to adopt a hybrid cloud strategy. Due to some compliance restrictions or organization’s internal policy, you can’t move your data center to public cloud. Another reason can be that you want your data to be in more controlled environment (leveraging private cloud or on-premise infrastructure) or you have a roadmap to move your entire enterprise applications to public cloud, but you want to have a slow transition approach so that you can minimize the unforeseen issues and risks. ?

Despite being a popular approach, it also has its challenges. It can be a real difficult and complex to implement hybrid cloud. Private cloud requires strong fault-tolerant, highly available infrastructures which itself is huge task to achieve. There can be security issues as you are combining public, private and on-premise infrastructure. You need to have an impeccable security strategy as you are dealing with different varieties of platforms. It is much more expensive than the public cloud. The cost, that companies bear for the installation and the maintenance of servers and data centers, is obviously high.

Conclusion:

All four options can work well if chosen in the right context. Each of those options is valid and best for a specific type of business need. It depends on what you are trying to achieve. A proper due diligence is needed before picking up any organization’s cloud strategy.?