13 tips to foil cloud lock-in
Public cloud vendors want your workloads forever. Here’s how to create a viable exit strategy
Last month I noted that the big AWS outage proved one cloud isn’t enough. This week, I’d like to go a bit further into the topic and talk about some of the things you can do concretely to embrace the cloud without betting the farm.
It’s not just about outages. Any vendor who has you by the data will eventually extract the maximum value from the relationship. Sometimes the most important question in a business relationship is: “What’s your exit strategy?” Here are my best answers, arranged by cloud type.
For IaaS
- Use Docker or a similar solution. You should have relocatable containers that you can rebuild and deploy at a whim. This is a critical if you want to protect yourself against lock-in.
- Avoid direct database integration. OK, your app needs a store, but no two apps should talk to the same operational store. Those sorts of connections and protocols tend to build a house of cards. You can’t move anything until you move the database — but everything goes down once you do, or you end up with a split brain situation.
For IaaS/PaaS
- Implement API/REST integration. Rest easy that you are connecting over HTTPS and making standard, easily relocatable web calls.
- Externalize configuration. Don’t hard-code the scheme, server, or domain into your URLs. Anything else that’s environmental should be externalized.
- Use common APIs. If you’re using NodeJS and Express or other, similar, well-known APIs, then you’re pretty safe from vendor lock-in. If you start using platform-provided services, you’ve got a bigger problem.
For SaaS
- Ensure there’s a standard method for data export. By that I really mean a way that you could feasibly import your data into another system.
- Test the method of data export. That they theoretically let you grab a dump of data isn’t really that promising. I’ve seen vendors that offered it, but then the dump feature didn’t actually work on any kind of reasonable timeline and the data was trash by the time it did.
- Favor solutions with well-known, stable REST APIs. Realistically, you’re not likely to dump, import, and move all in one shot. You may need some custom glue code where you grab and transport.
For everything cloud
- Favor open source technologies. If the core technology, APIs, and functionality are provided by a healthy open source project, you have a lot better chance of leaving if you need to. This means architectural choices (for example, using Kafka instead of Kinesis).
- Avoid dependence on unique cloud vendor technology. Sometimes your architectural ties are more process than code. These tend to leak into API calls or other operational management procedures. For instance, maybe you don’t use AWS’ Elastic Map Reduce, because it’s frankly not the greatest financial deal and it’s somewhat flakey. Maybe you just shouldn’t use it because it’s different from what you’d use on any other cloud platform.
- Use fixed IPs and DNS names tied to your company, not the provider.Using an IP and a DNS name is sort of internet 101. Having virtual instances that go down and come up with a new IP isn’t very resilient not to mention relocatable.
- Use messaging where possible. If you can do something on more of a message basis, where a service that’s down can be tolerated, do that. It means while you are moving you can forward things somewhere else.
- Two clouds. As I said before, it is easier to move if you start with at least two different vendors. That’s harder to do with SaaS, but pretty operable with IaaS/PaaS.
The bottom line is that you should favor open source, open standards, and open APIs over vendor-specific solutions. Use microservices architecture or at least the principles thereof. Always maintain your cloud provider exit strategy, and you’ll have a very advantageous relationship with your cloud provider. Always assume your cloud vendor follows the Ferengi Rules of Acquisition.
By Andrew C. Oliver, source by InfoWorld
Visit ICT Hardware website to get more information
