You would have to be living under a rock not to notice that multicloud deployments have become the new normal, for many reasons. The core arguments I’m hearing are the notions of avoiding lock-in and picking best-of-breed cloud services.
As I’ve pointed out here before, with multicloud comes complexity and the challenge of operationalizing a complex architecture. Many enterprises can move these deployments to operations (cloudops), and others are stuck in kind of a cloud computing limbo.
The easy answer is they should have planned better, but that’s not what enterprises want to hear, and to be fair to them, it’s not a productive response. They need to move forward with a multicloud architecture that will solve the prevailing business problems as well as provide a path to an optimized, multicloud architecture that won’t break operations.
Here are a few candidate architectures:
Heterogeneous cloud native. In the quest for best-of-breed, decoupled cloud computing deployment, groups are picking whatever they feel is the best technology for the job. This architecture ends up with many cloud-native services from many different public cloud providers, and that’s really causing problems.
This does not mean that cloud native is not desirable—it is. This means we’re doing cloud native incorrectly. The issue is that few or no common services exist above the native cloud services. You’ll end up with ten different security solutions, several governance tools, and a dozen or so management and monitoring solutions. Try working with all of those at the same time and see what happens.
Heterogeneous federated. Although this seems like an old architectural pattern warmed over for cloud computing, the reality is that it’s pretty new. This architecture is able to leverage containers and container clusters, but does so by deploying to many different public clouds as federated hosts.
This approach depends on a few things occurring. First, standards such as KubeFed, and resulting products that will use container cluster federation must appear in the market. Second, the cloud community needs to accept this architecture as something desirable, and an ecosystem will arise.
None of the above. This path means that we’re off in another architectural direction for multicloud, but what would that be? If we’re looking at the issues with heterogeneous cloud native, meaning the complexity battle that’s underway, the logical way out would be planning and developing common services, such as security, governance, management, monitoring, and even a devops approach and toolchain.
The debate is really between the lack of planning (hetero native) and the overplanning (hetero federated), and does not mandate the use of a specific, standard enabling technology, such as containers and Kubernetes.
What will win? From my point of view as long as we move away from heterogeneous cloud native and its limiting complexities, we’ll be just fine. What’s your move?