More on Multi-Cloud

Me (answering phone): "Hey, what's going on?"
Business Owner: "Have you seen what happened?!"
Me: "Uhhh....ummmm....yeah....I did."
Business owner: "So what the #$%# am I supposed to do, Brooks?!"

Ever want to end a call and sneak away from your phone? Well, after I heard that interrobang on a call from a furious business owner in Louisiana, I wanted to sneak away.


Angry is not a big enough word. That client was incandescent! About what, you ask? A cloud provider had de-platformed a customer in a very public way and all of their IT resources had already migrated to that provider. 


After the story broke, they didn't hear/read the story the way other people did. They heard ‘violating an end user-license agreement with a cloud provider could ruin a business.’ Their entire IT workload could be shut down with no recourse to on-premise solution replacements. Worse, because of their experience as an engineer, they saw past the simple issue of de-platforming to an even bigger potential problem lurking: vendor lock-in.


That was the core of their anger. They instinctively saw the course their company was heading down. All the IT resources were in one basket. This isn’t a unique problem in the IT world and many. business persons will not tolerate critical resources being single-sourced. 


But there is a way out! We can get out of the single-source trap like Indiana Jones swinging on a whip. That whip is called multi-cloud!


Multi-cloud means having enterprise workloads in more than one cloud provider. For example, using Azure for authentication to AWS web servers. Then, in their dark places of magic, data scientists export data from AWS for machine learning in GCP, leading to the material the marketing team can use for perfectly targeted advertising campaigns. 


Multi-cloud is not using on-premise IT or "private cloud" resources with those in a public cloud provider's offerings. That's a hybrid cloud. Hybrid cloud is an excellent option when latency and data governance issues arise with a pure cloud solution.  


So how does multi-cloud solve the issues? If I could wrap some of it into one statement, it would be this: embrace evolutionary architectural principles. This means:

• ⁠Engineer decoupled solutions using APIs
• ⁠⁠Build so changes can be incremental (a modularized, microservice architecture)
• ⁠⁠Being intentional about data engineering. (More on this in a moment)
• ⁠⁠Using fitness functions for testing
  

APIs: Avoiding Vendor Lock-In
A little history will serve to illuminate our current dilemma. In the late 1990’s, through the early part of the last decade, the number one fear of lock-in was from using products unique to vendors such as Oracle and IBM. The organization starts using one of their products and those products become hard-wired into workloads (bad architectural decisions), replacing the product becomes impractical (the proprietary structure of the data is too complex to migrate), and then you’re locked in. Usage begins to snowball leading to larger bills, often for other related services (think bandwidth or data storage). Worse, later down the line, audits discover "punitive licensing" is a real thing.

Lock-in for the cloud happens because providers make using other services in their portfolio easy. That's the point. You consume some compute resources in Azure and need a NoSQL data store. Why roll your own when writing to Cosmos DB is straightforward. This "ease of use" motivator serves to take you further down the road to single-source cloud services. Amazingly, the solution to avoiding vendor lock-in is what makes using the services so easy in the first place: well-formed APIs. Let's look at an extreme example.

This past December, Azure released several updates to their security services in the cloud. The one update that should have made sirens go off everywhere was Defender for Cloud, which now helps secure AWS resources (learn more here). You read that right: Azure managing AWS. That's possible because AWS mandates all services have well-formed APIs. So if Azure can call AWS services, it’s easy to see we can do that same. The well-formed API paradigm appears in almost every service offered by cloud providers. Thus, calls between GCP, OCI, AWS, and Azure are relatively simple.

Modules...not monoliths
Builders can embrace API-centric development by focusing on modular, decoupled architectures. Ensure your services are callable via a well-defined API and be able to use that service wherever it resides. Better, you can move the service between cloud providers when needed. 

Modular architecture also means you can make incremental changes during and after deployments. When you are moving from one provider to another, being able to make gradual changes to the deployment is a substantial unit of measure for DevOps performance. Moving towards multi-cloud capability has very positive knock-on effects to other aspects of your IT organization.

Data has gravity
Now, about data. Inside all the major cloud providers, there is a phrase spoken with a smile on the face and dollar signs in the eyes: Data has gravity. The more data a customer has, the more data will collect in their account. You collect data on customer habits, which leads to more data as new features are added, which grows even further when machine learning is implemented. And so on. Eventually, your bill for that data is super healthy (for the provider), or it becomes unreasonable to move that data out of the provider's cloud infrastructure.  

To help resolve this, businesses should start looking for cloud providers with the lowest charges against moving data out of their infrastructure and identify those with the highest costs for migrating your data to another location. This will help when selecting between different clouds. It also helps to find out if there are services available for speeding up this process, such as on-demand hardware storage units that you can use to move data in and out of the cloud (e.g., AWS Snowball).

What's the magic for making multi-cloud happen?
Building a solid multi-cloud practice requires architects, engineers, administrators, and developers to have strong, real-world cloud skills. Knowing how to use different categories of services from two or more providers will empower your organization to make positive, long-lasting decisions instead of settling for what a particular provider is offering at any given time. Build a culture that strictly adheres to best architectural practices, such as evolutionary architecture. Before anyone builds, deploys, codes, and so on, ensure the architecture leads to services that can exist in various environments.

And here's the big one: get the team trained!

Training…training…training…but the right training
At INE, we are focusing on that last critical element. Training on a cloud provider's tech is ubiquitous. Real-world, non-greenfield material is not, especially when you mix in best-of-breed tooling for cloud (e.g., Terraform, Pulumi, GitHub, and so on) within the training itself. So if you want to set yourself and your organization on track for success in the cloud, train to build skills in multiple clouds, learn how to host services between them, and enforce proper architectural design. We will deliver the training you need for real-world cloud skills.

About INE
INE is the premier provider of technical training for the IT industry. INE is revolutionizing the digital learning industry through the implementation of adaptive technologies and a proven method of hands-on training experiences. Our portfolio of training is built for all levels of technical learning, specializing in advanced networking technologies, next generation security and infrastructure programming and development. Want to talk to a training advisor about our course offerings and training plans? Give us a call at 877-224-8987 or email us at sales@ine.com.