the goal is to support duplicate environments with consistent capabilities regardless of which cloud provider is operating underneath the abstraction layer , it requires that each cloud provider has the same underlying capabilities . This leads to the next challenge .
The second ( and larger ) challenge to the “ distribute your eggs ” approach arises from the drive to the lowest common denominator . By definition , if the goal is to operate duplicate environments , then all the capabilities that are relied upon must exist in both environments . Of course , it is obvious that while the three main cloud providers have services and features that significantly overlap , they are not even remotely close to being identical . The result ? Any full-fledged implementation of the “ don ’ t put all your eggs in one basket ” multi-cloud approach is by definition limited to using the lowest common denominator set of features shared by the two cloud providers . This again results in an agility penalty , because when new cloud provider features and services are being considered , it is necessary to wait until BOTH providers offer the feature or service before it can be used in this form of multi-cloud implementation .
Architectural Similarity (“ Like for Like ”)
It ’ s not uncommon to find different technology stacks in different divisions or departments , because of acquisitions or high levels of autonomy among groups . One division might be heavily built out on the Microsoft ecosystem with SQL Server , . NET and C #, while another has a history of Linux , Java and other open source technologies . We sometimes see a pattern where individual departments may choose to extend workloads into the public cloud based on ease of migration to a given public cloud . For example , Azure offers ease of migration for Microsoft workloads , so it ’ s not uncommon for a department or group to choose Azure as their public cloud for that reason , while another department may choose AWS .
It ’ s important to note that this pattern is not usually consistent with best practice . While it offers some cloud benefits ( e . g ., OpEx over CapEx , scalability and agility ), it creates two or more separate public cloud footprints , adding operational complexity , and limiting the ability to achieve a cohesive view of costs . In the end , it essentially becomes two duplicate environments .
Feature Availability (“ Best of Breed ”)
While the multi-cloud approaches above are fairly common today , we feel that a different model should be considered as a more successful one moving into the future . This promising multi-cloud architecture can be thought of as “ Best of Breed .” With this approach , the mindset is that the agility risk imposed by insisting on duplicating all features in both environments actually costs the enterprise more than the stability that is theoretically gained by deploying two
48 | THE DOPPLER | WINTER 2018