All that hard work you, as a CIO, put into getting off on-prem and into the cloud? Sorry — you’re not done yet. The reason I need to dampen your mood and focus your mind back on a problem you probably thought long since solved when you made a strategic decision to go AWS, Google Cloud or Azure, is that going with any one of these public cloud services is not a one-size-fits-all solution to your business problems. Worse: it may bring you back to deal with a dragon you spent the years fighting before cloud—the danger of vendor lock-in.
Vendor neutrality
In the rush to the cloud, it can be all heads down, with focus on where the next project is coming from. But it’s possible that you’ve opened yourself up to a bit of risk through making your cloud vendor decision too quickly. And ultimately, the problem comes down to the best way for you to optimise your cloud usage for your business. To give a flavour of this, consider the problem of clouds in different countries: we often frame this problem as a data location problem, and that’s a factor, but that definition doesn’t exhaust the problem.
For a start, not every cloud provider is available in every country, which could be a problem for your colleagues in Istanbul or South Africa, for example. But there are also political facets to this; US retailers don’t see much point in paying Amazon for their IT if they’re competing with them so viciously. In a global marketplace, being tied to one cloud service can be either impossible to achieve or not tolerable to the business, so cloud vendor neutrality becomes important.
Practicality is one driver for always being open to multiple cloud solutions. There’s also vendor strategy: you will get driven, hard, to opt for its version of key parts of the software stack; their cloud version of database, say, as Amazon doesn’t want you to move your Oracle apps onto Amazon, but the Amazon database products instead.
In and of itself, that’s not a crazy or risky decision; there are advantages to doing that if you are an Amazon customer already, and there will probably be economies of scale. It might even be cheaper (although that isn’t always the case with cloud contracts). This may feel like an easier solution to adopt, but could be a real headache if you have committed to microservices and have all kinds of open source apps running all over the place (as you want to, as it’s horses for courses here), and the database at the back is an Amazon database. What happens if you fall out with them, or when at renewal time they come back and say that the rent’s going up, as you’re using more and more resources than first scoped, or they have another outage?
Making a case for consumption-based pricing
‘A single cloud for everything’ will be an impediment to your business
What you really want is the upper hand in all this — to retain your room for manoeuvre and operational flexibility. You might fancy that other cloud service in region X, as it’s politically better or is more resilient in those operating conditions (e.g., telecoms stability). Not all cloud vendors have the same pricing or the same level of guaranteed support or the same capability in all the different parts of the world where you want to operate, too.
This means that ‘a single cloud for everything’ will be an impediment to your business. That’s why all the larger organisations are looking more and more — even if they didn’t start off that way — at multi-cloud as a defining strategy of all their cloud work now. Sometimes, that’s Amazon for operations and maybe Azure, because of all the collaboration, software and support they already get from Microsoft for something else; Google, again, for other attractions.
The job’s not done just by the board approving your cloud business case and budget for a migration being released. You really want to be making each cloud vendor compete for each and every bit of your business, and in each part of the world where you’re in business. And you need to be clear that going single cloud means a very high chance of being saddled with the chosen partner’s proprietary technologies themselves, and hence you are being locked-in.
Is there a danger of complexity here? Does the need to work with multiple vendors sounds potentially like something that’s going to slow you down? I think this is less of a danger in the long run, than losing your ability to innovate and go in a new direction when external business circumstances change — along with the cloud vendor’s offerings and prices! You may do an exhaustive competitive evaluation for your cloud vendor at day one; you should remember that this isn’t a one-time decision, and something you’ll want to revisit, even if you are going to one cloud only for now.
So, always, always try to think multi-cloud. But you should also be looking to be as open source as you can be on whatever cloud topology you end up with. For one, if the technologies you deployed are all open source, or are from a vendor who is truly cloud independent, you should be able to move it to another cloud or even another vendor without too much hassle.
WIT Summit Europe Q&A: digital transformation and open source
The crucial database 10%
This is true about pretty much every part of the application stack, apart from one rather important element: the database. The reason CIOs looked to the cloud in the first place, remember, was that instead of having one big box in the data centre running one big expensive Oracle or DB2 data engine, they wanted to get off-prem and save all that investment. Cloud vendors are more than happy for you to do that, and if you don’t like their database, then they are fine with you running open source or NoSQL instead. But they then open the laptop and tell you all about their special wonderful SQL, which is what you know and love from the monolithic app… and suddenly, you have an open source stack for 90% of the picture, but that vital 10% is locked into your vendor’s special SQL.
This means that the whole stack is effectively locked — as that’s the special sauce, that means your global sales ledger always gets properly updated! So, you need to look for freedom at the SQL and database level, too: if you want to run SQL Server in one country for six months, or partner with some regional cloud start-up for a bit, then you could end up having to rip out all the back of this, and put another database in there… and it’ll be messy, expensive, and a drag on your company’s ability to execute.
So: sorry to be the party pooper — I can assure you the decision to go cloud was the right one for your technology architecture, costs, and the future of the business. But the job’s not done until all the advantages of cloud are secured, which means never allowing yourself to be locked-in to just one company’s way of doing things, no matter how fluffy the cloud presentation slides look, or nice the sales team!
