Originally Published on ToolBox for IT

 

What’s Operational Flexibility and Why You Need It

 

Imagine being able to mold your IT operations to exactly match your business needs without technological limitations. This is ”operational flexibility”.

However, this remains out of reach for most of us, as the biggest obstacle standing between you and operational flexibility is the problem of data portability in the public cloud. This is because operational flexibility requires application mobility, which in turn depends on data portability, something which is currently the number one barrier to operational flexibility in the public cloud world.

 

Data Portability and Its Importance

 

Data portability is often confused with data mobility. But there’s an important distinction: While data mobility means getting data to where you need it once, data portability means you can use the data wherever you need at any time because data is always in sync between locations.

 

Lack of Data Portability Is Antithetical To Operational Flexibility in the Public Cloud

 

We want to live in a world only made of stateless applications. But in reality, no business application can ever be truly stateless, as there is always data pulling your application towards it.

So the next question is: who manages your data, as he who controls your data controls your application. For a while now, the go-to solution would be to use managed first-party data services like RDS or Aurora on AWS or equivalents in other clouds when setting up a Kubernetes-based environment. It would then be letting the cloud vendor who manages your data decide whether you can have true operational flexibility.

The answer is always “no.”

 

Limitations To Operational Flexibility in the Public Cloud

 

The public cloud allows for limited operational flexibility. For instance, if you have AWS EBS storage, applications with data can’t be replicated synchronously within the same region without jumping through hoops like setting up app-level replication.

Cross-region replication is even more complex. You can take a snapshot in one region then replicate it to a different region. Data portability between regions comes at a price of high RTOs and RPOs, taking time and giving you a copy of the data hours or days in the past.

And it’s nearly impossible if you want to move data from cloud to cloud. You can’t ship an AWS snapshot to Azure or Google Cloud because there’s no compatibility layer or API that would allow you to do that.

The cloud vendor you pick today is the cloud vendor you’ll stick with forever. This is typical because of data gravity. Five years from now, you’re going to have exponentially more data than you have today, making it impossible for you to switch vendors.

 

Application Mobility Equals Application Independence

 

The advantages of multi-cloud deployments are difficult to overestimate. When applications are infrastructure- and cloud-agnostic, you can shift workloads according to your business needs without limitations or constraints.

 

The Pros of Becoming Cloud Agnostic

 

1. Avoiding Vendor Lock-In 

Buying a first-party data service from cloud vendors such as RDS, Aurora, or Azure SQL means designing your applications and infrastructure in a non-portable way and constraining your flexibility according to the limitations of the data service you choose.

Cloud agnostic organizations can easily switch between clouds when vendors change their product or technology in a way that doesn’t suit your needs, another vendor launches a better offering, you’re not happy with the quality of service your vendor provides, or your vendor raises the price and you can negotiate a better deal elsewhere.

Data portability between clouds enables you to avoid vendor lock-in and gain maximum business value from using different vendors. This is a big part of operational flexibility because you don’t know what your business needs will look like in the future.

2. Better Risk Management and Resiliency

Data portability ensures resiliency. If a cloud vendor has an outage or a security event, it’s easier to switch to another one without delays or losing any data.

Opting for a multi-cloud environment also boosts security and disaster recovery and ensures easier migration for data and applications. Spreading applications across different vendors means a cyber-attack is less likely to bring your entire business down at once.

3. Cost Management

Cloud vendors have the power to raise prices which you will have no choice but to agree to because of your dependency on them. But when you can move data at any time, you’re in a much better position to negotiate prices.

4. Flexibility

With access to multiple clouds, you can play around with the strengths of each vendor and combine them as you see fit. Having immediate access to more than one cloud also means being able to take advantage of these features when you need them, without having to fully migrate to another cloud.

Workloads can be shifted as needed without having to redesign your applications or completely rethink your infrastructure. As a result, you can pick and choose the best features different platforms offer. The one who owns the data makes the rules.

 

How To Achieve Operational Freedom in the Public Cloud

 

If you’re just building your infrastructure, now is the most appropriate time to look into cloud-agnostic solutions that allow operational flexibility for application mobility. If you make the mistake of locking yourself into a single cloud vendor, moving your business somewhere else down the line is going to be costly and painful.

1. Use an Infrastructure-Agnostic Storage Layer

As mentioned earlier, you can’t ship an AWS snapshot to Azure or Google Cloud because there’s no compatibility layer or API that would allow you to do this. The solution lies in utilizing an infrastructure-agnostic storage layer that makes your data appear in all of the locations you need, regardless of the underlying infrastructure.

2. Decouple Applications from Infrastructure

Using first-party data services from cloud vendors such as RDS, Aurora, or Azure SQL means you’re designing your applications and your infrastructure in such a way that’s not portable. You are constraining your flexibility according to the limitations of the data service you chose.

The key lies in decoupling your applications from the cloud vendor completely.

3. Find a Solution with a Common Cross-Platform API

Let go of all the first-party data services. Spinning up your own data services for your applications’ state on your own Kubernetes cluster is just one command. You should be able to see all of your application states from one place and all the clusters that need to have access to it in the same standard way. This means you write an application manifest once, and you can bring up your application anywhere just by applying the same exact YAML file or Helm chart to any cluster anywhere in the world.

4. Keep Data in Sync 

Keep data synchronized across multiple locations and cloud vendors so when you need to start your application somewhere else, your state is already there. This takes the risk out of cross-cloud migration.

Data portability in the public cloud is an essential prerequisite for flexibility, agility, and resiliency when searching for solutions to help reach the mobility goal. Remember – services should support and not restrict. The best decisions are reversible ones.