15 ways to leave your cloud provider

0
56


The younger generation may find this hard to believe, but there was once a sitcom, “M*A*S*H,” built around all of the funny moments in the Korean War. It ran for 11 years. When the script writers wanted to add a bit of excitement, the war would shift, danger would approach, and it was time to “bug out.” The patients would be loaded onto buses, the tents would be torn down, and someone would start saying, “The M in M.A.S.H. stands for Mobile.” (The rest of the acronym was “Army Surgical Hospital.”)

The modern IT staff’s job may never involve moving bodies recovering from major abdominal surgery or amputation, but the need to remain nimble seems to be growing and growing. More and more teams are finding that their carefully built architectures are sitting on a layer of quicksand. The hard won data and the code crafted in late night bouts of genius might need to be moved—and sometimes the move needs to be done before the end of the weekend.

The highest profile cases have been , but they’re far from the only examples. A quick search of discussion boards like Hacker News shows that the phrase “” appears shockingly often. In many cases, the confused programmer turned to the web to find some kind of answer because the tech leviathan was a black hole that wouldn’t respond to emails and didn’t list a phone number or even a physical address.

The stories come in all sizes. While many cases are small developers who tripped on some clause buried deep in the Terms of Service, there are plenty of big companies too. One monstrous game company with even bigger sales balked at paying the hefty percentage to the mobile phone app stores and found out that it to win the sumo match on weight alone. Sometimes there’s even some irony because one of the tech’s biggest dispensers of cancelation tears is its own sob stories with the mobile app stores. Even giants have feelings too.

A quick skim of the Terms of Service shows they’re a mixed collection of crisp rules that draw bright lines and nebulous rules that could keep us arguing until the bar closes. One TOS bans sending “low quality email.” Of course they mean spam, but just how low is low? Does it include parents that send short notes that “just want to see how you are?”

And it’s worth remembering that it’s not just disagreements. Fires (,,), explosions (,,,), wars (,) and disease (,) cause outages. Sometimes it’s not physical but a cyberattack on the infrastructure (,,,,). How did the data centers in Texas handle the deep freeze? 

, “We must take special care of the list with each client’s name and the amount of money he has invested. If we were to lose that list, we would be ruined.”

Some bits are more important than others. Figure out your core database tables and concentrate on them. Replicate those tables on a server that’s in your physical control. Then replicate it on another one. When you bug out, you can bring those tables back up first.

Design flexible failover

Can your website still work even if half of the microservices don’t respond? If you can bring back the crucial services first, it’s nice to offer something. Those who embrace should be sure to keep everything running even when some fail. This will add flexibility to any rapid migration. The users may not care about the slick AI recommendation engine or the API importing localized weather forecasts. They may just want to place an order.

Imagine running on half the hardware

When you move, you may not be able to start up all of the databases and services. Start working on a triage plan now. A good architecture will include a plan for partial hardware support. Can you turn off enough so that what’s left will run on half of the hardware? What about one tenth? Maybe one hundredth? 

Use containers

The devops teams have one major goal: Make deployment easier and faster. Almost everything they do will also help you move to a new provider with just a bit of planning. The good news is that they’re already doing much of the work.

Containers are the latest form of bundling your application for quick deployment but there are other, similar options like unikernels. The good news is that we’ve come a long way from the days when it took the team a week to configure a new server.

Run drills

Why not run a mock migration? Try spinning up copies of everything in a different cloud or in some servers down the hall. See how long it takes. Are there any configuration files or software packages that can be tweaked to make it faster? Can any of the databases replicate themselves automatically? Do your containers all start as expected?

Test with experimental projects

Traditional skunk works projects start with the same hardware configuration in the same cloud. If you’re going to be experimenting with a new service or an enhanced database, why not try it in a different cloud at the same time?

Build self-reconstructing datasets

Many applications consist of a series of events that are summarized in a set of tables that form a single source of truth. In other words, a series of database UPSERTS. What happens if the stream of events is stopped? What if some events are repeated? Design the architecture for failure so the database summarizing reality stays consistent even when data flows are interrupted.

Avoid concentration

While it’s tempting to keep things simple by using the same cloud for everything, the danger is that one cloud becomes a big point of failure. Microsoft, for instance, bought GitHub and this should give Azure users a reason to start thinking about storing their code in other repositories. Or at the very least, make sure it is pushed regularly to backups. The same goes for the other clouds.

Use open source

Proprietary code has many wonderful aspects. Sometimes the business model delivers some amazing software. There are many times in life when you get what you pay for and that can be true in the software world too. But only open source software offers you the freedom to move the code easily and quickly without begging, “Mother, may I?” Richard Stallman always said that he was after “free as in speech, not free as in beer.”

Avoid proprietary tools

The cloud providers usually offer two types of products: open source clones and proprietary tools. While the closed source products may offer plenty of tempting options and attractive innovations, the threat of losing service is too great to risk using them. If you choose the MySQL service at AWS, you can move to MySQL on your own box. If you choose a proprietary tool, you can’t.

Recognize the scale of political turmoil

The fervor used to sweep through America every four years. Now it seems like it’s endless and it’s not just for who gets elected. Every part of life seems open for interrogation. Google workers have formed a union and they’re not just agitating for higher wages and better donuts on Fridays. Their mission statement announced that “We will use our reclaimed power to control what we work on and how it is used.”

Amazon’s Terms of Service now include a complete ban on using their facial recognition software on “criminal investigations” but not “missing persons.” Is your software used by the police? If you started your project before the moratorium was announced, tough. You can now use your time off to ponder whether it applies to police investigations of kidnapping cases. 

Copyright © 2021 IDG Communications, Inc.

LEAVE A REPLY