What does “multicloud” really mean? Is it a destination? An action? How would one “multicloud” anyway?
The term “multicloud” has been a buzzword that many talk about doing but very few execute successfully. If you ask 10 people about multicloud, you will get 10 different answers. Do you want to work separately in multiple clouds? Or, do you want the same work and fundamental data to exist across multiple clouds — and even span multiple clouds? I want the latter, with the option to place the right data, at the right time, in the right location.
My Multicloud Wish List
If I were looking to execute on a multicloud mandate, to begin I would put a few common pieces of tooling in place. I would search for a process or product that is agnostic of any hyperscaler or on-premises platform that exists in the industry today. The first order of multicloud: create no silos.
What am I trying to do with multicloud? Well, what do I want to do with AI? AI follows the data, and it takes substantial compute power to properly train AI models. The data also needs to be closely accessible by the AI model trainer.
I would like a foundational multicloud solution, free of the rigid constructs that can be exposed as I move up the stack. I would consider this foundation the storage layer. The storage can be block or file and structured or unstructured with any protocol available; just let me deploy a consistent storage target anywhere I want.
It should also be free of the potential and very real constraints of moving around the entire stack. As a multicloud architect, I do not want to drag around all the silos, layers and prerequisites that come with an application. I want my storage layer to be common, available across any deployment, whether on premises or in any hyperscaler. Once my data, driven by a common storage layer, resides in the target location, it can be quickly consumed by the specific target stack orchestration that exists at that target.
What My Multicloud Takes from DevOps
As my DevOps friends already have seamless processes in place, they optimize access and refresh data frequently, because working with stale data is not a good idea. Looking across my clouds, it should be straightforward to compare what my data looks like on cloud A versus cloud B?
Then, to simplify my storage accessibility implementation of Infrastructure as Code (IaC), my tools must have patterned, self-documenting automation with checks and balances for my chosen workflow repository that proliferate throughout the desired environment.
I like to think of this as a “superhighway of storage” that is paved across any landscape, and anyone can drive on this storage layer as they see fit.
When I convey my multicloud foundation to my DevOps teammates, they will ask for this storage to be fluid with frictionless data mobility. My multicloud world would incorporate API-first data mobility, again with fundamental IaC and playbook execution. With this, I can move data around to consume it in the right place and at the right time.
Back to the “AI follows the data” construct, I can minimize and hopefully remove any “Rube Goldberg data transformation” design and move fundamental storage and volumes as needed. Having this option gives me the flexibility to move only the data I need from source to target. This also checks the “good guy” box with regard to the multicloud economics.
Storage efficiency is key for the multicloud solution. I know hyperscalers are not really in the business of providing storage efficiency, at least not as an offering I can consume. I want the ability to have efficient storage, including thin provisioning and snapshotting. Then I can point whatever application that consumes that data at the target. I just want to move my storage and associated data around between multicloud targets.
A big part of my multicloud wish list includes my friend Kubernetes. My DevOps friends are threading with Kubernetes hourly, building data services with ephemeral storage hooks and application mobility as part of one or many namespaces. I need my multicloud storage deployment to streamline Kubernetes persistence management. This common storage layer will bring some cohesion to the laundry list of CNCF Kubernetes offerings that are out in the wild.
Arguably, the most important conversation around multicloud is security. This includes logging and auditing, identity and access management (IAM), and traffic patterns — both ingress and egress — through a secure connect gateway. These are fundamental principles to a successful multicloud implementation and worthy of a separate article.
A Single View of the IT Ecosystem
There are so many positive outcomes that come with a multicloud storage foundation. Even shadow IT operations could simply fade away, as engineering would be aware of what processes are executing where, on any part of the stack. Call it a “single pane of glass” view of the IT ecosystem.
The post Multicloud Architecture: What I Want to See appeared first on The New Stack.
Beyond a mere buzzword, multicloud offers significant benefits for IT architectures. Here's what's on my wish list.