Service Migration: A Prerequisite for Modern Agility

Have you heard the buzz about service migration? Do you want to know why it's important to your agility? In this post, I'll explain what service migration is and how it may be important to your company. Then I'll share some suggestions about how to build with service migration in mind.

Service migration is the general concept of being able to move your service from one cloud provider to another. That is, you should be able to move your service without rewriting it, modifying its configuration, or changing anything. The goal of such a thing is to provide yourself with the ability to pivot. You might do this for any number of reasons, including cost, regulatory issues, or to take advantage of services provided by one vendor and not another. What we're really talking about is the general property of portability. Ideally, this would be a frictionless movement of a service from one hosting platform or service provider to another. But practically speaking, this is pretty difficult to achieve.

Let's dig into why we might want this mobility. The most obvious motivation is to have flexibility in choosing a cloud platform vendor. If you can select a new provider at any time, you can switch to the less expensive option at will. Of course, you'll want to make this transition with minimal technical risk. Another motivation for mobility is to enable the organization to follow the industry leaders. Having the ability to quickly redeploy your software on a different cloud gives you a potential market advantage. No multi-month efforts; just choose a new platform account and deploy. Modern businesses need these capabilities in order to compete in an ever-expanding global market. The ability to pivot is essential and increasing in importance as the rate of development increases on the internet. Vendor lock-in is a recipe for failure.

When we talk about service migration, we aren't talking about simply being capable of deploying to a different cloud. We want an almost seamless transfer of a service from one platform to another. What that really means is being able to redeploy your system on a new cloud in a few hours without changing anything significant. That requires a lot of preparation. Today's cloud platforms have many similar features, but none of them are configured in the same way. There is a myriad of tools on the market today that promise to make service migration a reality. Many of these tools do a good job of at least reducing the pain. However, they have not reached a panacea-level solution yet.

It will be some time before we can move a service from one cloud provider to another with a click of a button or the drag of a mouse. Until that day arrives, there are a number of things we can do to ease the pain of transition.

The vast majority of businesses are in the business of doing business with or without computer software. That is, the software isn't the differentiator. Adhering to industry standards using well-understood tooling, platforms, and protocols should result in pretty stable solutions. For one, you just simply avoid the issue of incompatibility by keeping to the standards. For those cases where it's the differentiator, there's plenty of room on the ranch before you have to go all ROFL-scale customization crazy.

Infrastructure-as-code tools can go a long way toward insulating your application from the cloud, but they don't solve all the problems. Choose the best of breed for these tools. Then make sure your development teams are well educated in how they work. And whenever possible, see that development teams have sandboxes to play with too. These tools make strong claims about their ability to bring you mobility and service migration, but you'll never be sure until you try. A sandbox can save you from a very expensive mistake when trying to manipulate your organization's cloud-deployed applications. That's true whether you're switching clouds or just reconfiguring your load balancer.

If service migration is a concern, you need to consider whether that nifty new feature from vendor X is worth it; you might have to reconstruct some or all of your service in order to move to vendor Y. How does that affect the overall bottom line for your organization? Does it put you at a competitive disadvantage? Stay focused on delivery, not on cool. Each cloud has a set of cool tools and features. You should look at each one closely and determine on your own if it's worth investing in. In that determination, you have to look at a variety of financial and human factors. If you can isolate what's special about your software, do so. Make what is special, special. And use the best possible standardized tools, libraries, and infrastructures for whatever isn't special. This will minimize the pain of transition.

When we get close to the metal, we have to start thinking about how we'll build our software. So here are a few considerations, with service migration in mind. First, choose common languages and tools. Nobody wants you to run your Fortran-77 code on the cloud in the first place. But if you choose to, mobility won't be available to you. Rather, choose commonly available robust languages like Java, Python, or Ruby. Not only will this ensure available development resources but it will also be much more likely that you'll find support for these languages and their tooling on any given cloud. Next, choose configuration over customization. Anytime you can configure a platform to do your bidding, choose that over writing custom code, extensions, plugins, and modules. You'll save yourself a lot of headaches going forward. The caveat here is this: do make sure the configurations you're applying are applicable in general and not specific to a particular vendor; you don't want to re-roll custom shims and adapters to get moving on a new platform. Otherwise, you're trading mobility for convenience.

Isolation of your special nugget of awesomeness is mandatory. If you've built a system that relies on specific components, you've limited the field of play to only places that provide those components. For example, if you use an enterprise service bus (ESB), only cloud providers with ESBs are viable. If you wanted to move to another cloud that didn't provide an ESB, you'd be forced into selecting a vendor on that cloud who does—or worse still, you'd build and deploy one for yourself. At that point, you're treating the cloud as if it were just someone else's computer. And we've already talked about why that's a bad idea. Furthermore, the APIs and SDKs for things like an ESB are not always going to match up between clouds. You won't often see a generic ESB module; you'll see the MuleESB module. I'm not saying that some providers won't have a few of these things, but often they're just thin wrappers around specific implementations. For example, there might be document databases, named after the cloud they live on, that are ultimately MongoDB. So what are you going to do about this? Isolate your software.

It may sound passé, but build an abstraction around these external components and take care not to violate those boundaries. Keep the delineation clean. If you choose to swap out the component underneath, at most you should replace the adapter layer. In a perfect world, you might not even have to do that.

Consider that in the future it's likely you'll choose a new database or swap out a messaging infrastructure. Those are non-trivial tasks, even with careful planning. The possibility of this causing a service interruption is enormous. It could be fatal—or at least terrifyingly expensive—for any organization. One mechanism you can employ is to wrap things with feature toggles. Feature toggles can make it quick and more or less painless to change system configurations. You'll typically use them to turn features on and off. In most discussions of feature toggles, we end up talking about things like introducing new customer-facing features to specific users, groups, regions. We might also discuss them semi-randomly as part of an A/B test. There's another opportunity, though. You can use feature toggles to swap out entire sub-systems. These toggles give you a chance to do experiments and fail without irrevocably corrupting your production environment. For example, if you were swapping out your MySQL database for MongoDB, you could try this out using a feature toggle. If it fails for any reason, flip the switch back to MySQL. No serious harm done. The big advantage of a feature toggle, when well implemented, is that you can make these changes at runtime. You can partially deploy code and have it turned off until you think you have everything you need. In this way, you can effectively integrate new subsystems continuously. Then, when the time is right, you can turn them on in production.

All in all, service migration is a lofty goal and an expensive endeavor if not planned for. That said, the benefits of having this capability may well be worth it to your organization. You'll increase your ability to provide services anywhere, anytime, and this quickly may give you the competitive advantage necessary to dominate a market sector. When you can chase after the optimum cost model for your deployment, you'll reduce operational cost and increase the profitability of business operations. Keeping your implementation flexible will allow you to follow the best-of-breed cloud offerings. And finally, the flexibility of your implementation will allow you to experiment with your software to a degree that makes switching cost evaluations a non-issue.