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 political, but they’re far from the only examples. A quick search of discussion boards like Hacker News shows that the phrase “canceled account” 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 wasn’t massive enough 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 sharing 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 (1,2,3), explosions (1,2,3,4), wars (1,2) and disease (1,2) cause outages. Sometimes it’s not physical but a cyberattack on the infrastructure (1,2,3,4,5). How did the data centers in Texas handle the deep freeze?
The point isn’t that the tech giants are capricious sadists dangling us over a fire like spiders on the end of the thread we made. Most of us might agree with many of the decisions they make. The point is that all of us must be ready to bug out. The war could shift. We could end up on the wrong side of some philosophical line. Someone might decide that cracking down on semi-low quality email is the only way to win their bonus.
Here are 15 ways to prepare.
Don’t count on the Terms of Service
The lawyers at the cloud providers have had years to write these piles of weasel words and they weren’t thinking of you and your job when they did it. They often include the right to cancel your account at “any time” for “any reason,” and some of the lawyers tossed in the right to cancel your account for “no reason” too. According to Google’s search engine, there are 114,000,000 web pages with the words “terms of service” and “no reason.” The internet was never a very safe place to begin with, but it’s not like the arrival of the so-called “rule of law” has done much for the level of trust.
Don’t expect them to agree with you
Yes, you’re doing God’s work and everyone on your team is from the upper tiers of the celestial hierarchy of angels. But it won’t matter. The sob stories about cancelled accounts and locked up servers aren’t told by skeevy drug dealers who are totally blind-sided by “some jerk’s” decision to cancel their website Krack4Kids.com. No, they’re written by people who thought there was no chance of being shut down. It’s safer to assume your data and your app aren’t safe. As they say in the trenches, “You never hear the one that gets you.”
Don’t bother calling
In the past, companies would employ sales teams that would actually be nice to customers because their commission depended upon it. Lately, more and more decisions are made by AIs running automated scripts. If there are humans, they’re more and more likely to be hidden behind the curtain where they do their work anonymously. Hidden or not, today’s human reps are measured by their throughput so they’ve got minutes or even seconds to decide whether to hit the thumbs up or thumbs down button. And if you appeal, it gets placed in the queue of a slightly more experienced person who is still judged on throughput. No one is accountable to anyone—by design.
One of the scariest things about modern cloud computing is how many stories begin with, “We wouldn’t have gotten anywhere if I didn’t know someone who works there.” The AI bots and the unions are frantically kicking sites off the clouds. Having any kind of bond with a real human can be invaluable. So start buying more drinks at the bars. Start sending out more fruit baskets and birthday gifts.
Identify core data
Long ago, Saturday Night Live ran a commercial parody of a brokerage firm in which the founder proclaims, “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 microservice architectures 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?
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.
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.
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.