… and should you even try to avoid it?
Cross-cloud portability, that one great argument against using specific cloud provider to it’s full extent. This is also kind of often used by competing cloud providers as a leverage to get at least some business from a client coming their way.
The Golden Cage – Term used in IT to represent a vendor lock-in situation, where customer is forced to stay within a vendor, a product or a service because of architectural, contractual or other specific reasons, which make “escaping” too complicated or expensive
This is easily also one of my favourite subjects to discuss with customers, who are only starting their cloud journey. And when someone represents them with this rationale, that how should they react.
Be rational – be informed
I just recently was invited by my coworkers in Denmark to speak to a group of CIOs within a specific industry. These CIOs had a peer-group, which assembles monthly to discuss challenges of IT in their respective field of industry. It was an interesting session and audience to talk to. It was also somewhat of a challenge to speak to a group of people of which you basically only knew the industry they were representing. And that they wanted to know about AWS.
This very same topic was something I discussed there with them at length – as most of them were in the very first steps of leveraging the cloud in their respective workloads. And this was an argument they had already received from other parties.
To cut to the chase, my final argument was: make informed decisions.
OK, maybe some further explanation is required.
The cost of portability
As with every decision with architecture, there is always some impact in cost. It can be infrastructure / capacity related cost, labor cost or some other hidden cost, but it is definitely there.
There are basically two main routes with portability in mind: 1) Being portable. Be as generic as possible. Do it all yourself. 2) Be brave, lock yourself in. Go full throttle and leverage all the added value services.
Other routes are more or less variations of the theme.
All these fine AWS added value service – to use them or not?
So what are the mechanisms that affect cost based on these selected approaches? With preparing for portability, you essentially need to handle everything yourself and select only common tools across selected cloud vendors. Like virtual servers and basic storage space. This requires time and effort to create. And extra capacity for all management components and so on. And not to forget that you will need to handle the lifecycle of all components.
With full-on cloud approach, you select more agile method, faster time-to-actual-value by leveraging components, that someone else takes care of that are properly maintained and secure. And you more or less sacrifice portability at that point in time.
But what is the actual scenario, you are preparing for with “portable architecture”? Are you preparing for portability just for the sake of portability? Or do you have a legitimate business reason.
So the question follows: how – and why – do you prepare for something which might never happen. And when should you do it?
To insure or not to insure
Actually this boils down to quite simple metaphor: should you think this scenario as buying (or not buying) an insurance and should you think like an individual or like government – who usually do not buy any insurances.
To insure on not to insure – that is the question
How much are you willing to pay for something that might not ever happen? What is the probability of the scenario actually coming to be, where you would be forced to pack up and leave?
The “pay the insurance” scenario is more or less the one, where you make a portable architecture and pay beforehand the cost related to it. You might never actually need to be portable, but hey, the possibility is there!
The “think like government” scenario is based on the fact, that if your scale is high enough an probability of something occurring is small enough, it makes sense to take a calculated risk and decide to realise the cost only if the circumstances require. The cost at this point might be higher, but you have been able to redirect your assets and resources to build actual value instead for possibly a long period of time. If this time is long enough, then the calculated risk has paid off.
The hard part here is, that comparing actually these two options with cost and risk included side-by-side might be borderline impossible…
Be informed
I’m not making a blanket statement here stating that one or the other is always the way to go. And neither should you. It totally depends on your specific circumstances, which approach is the best.
And now we get back to the point: make informed decisions. If you have identified risks and reasons, why you choose to leverage added-value technologies, which make it harder to be portable, it is still an informed decision. You have calculated risk and accepted it – nothing more, nothing less. And on a side note, this same rationale applies to much more broader spectrum of IT technologies, than just the cloud.
So make good decisions. Based on facts. And your specific needs. Don’t let anyone tell you, that you should make portable architectures, if you do not find a legitimate business need to do so. And on the other way around, if you have legitimate reason, make a decision and go for it.
But in the end – be brave to embrace the new
As an end note though, I can say, that I personally have long ago decided which is my go-to approach of these two. If you didn’t already guess.
So I invite you also to take some (calculated) risk, a leap of faith and embrace the value-added services in cloud platforms.
—
The author works as Chief Technologist for Managed Cloud Services at Cybercom Group. Cybercom is a Nordic based IT consultancy offering managed services and solutions to their client in the connected world.