Odhrán McConnell, CTO at 101 Ways, explains some of the misconceptions about cloud migration – and why they should be discounted.
101 Ways is speaking and exhibiting at the upcoming Digital City Expo next week. Find out more about the Expo and Digital City Festival week here.
Advancements in technology are immediate and plain to see everywhere. New services and apps are popping up all over the place, largely enabled by the advent of cloud computing. The ability to quickly and easily develop “internet scale” software has been a game-changer for many new companies. But it can be considered risky.
When researching cloud migration, the internet will deliver equal, but opposite opinions that cause a lot of confusion.
In my opinion, the primary thing every organisation should be doing over and above any other activity, is focus on product development. I’ve seen huge investments and initiatives focused on infrastructure and maintaining physical hardware, often to the detriment of developing the core product. This isn’t ideal and should be discouraged.
Secondly, it’s worth noting that there are certain industries where a move to the cloud should be considered with extreme caution – or potentially not at all. These tend to be businesses or organisations with life-critical systems (such as operating theatres and flight control systems), or systems where bandwidth and throughput are critical (such as game servers).
With that in mind, I will look at the common arguments against moving to the cloud, and why in 2020 they are no longer valid.
Fallacy 1: The Cloud Isn’t Secure
This is by far the biggest concern people have. Cloud-based services tend to be hacker targets and there are now strict laws (and even stricter penalties) that can be imposed in the case of serious security breaches. Organisations with a more risk-averse attitude tend to dwell on this. There is also the perception around a loss of control of data security such that if there is data loss, it’s hard to prove who is at fault, you or the cloud provider.
While these are valid concerns, they can all be mitigated if not overcome by the implementation of good practice such as:
- Implement and use the cloud providers’ Identity and Access Management (IAM) correctly. There are plenty of good ‘how-to’ articles on the subject, so there’s no need to rehash it. It’s a solved problem and not immensely difficult.
- When deploying applications to the cloud, use infrastructure as code and make sure to use best practice around key management. If the hosting environment set-up is separate from the application code that runs on it, it’s a recipe for trouble. By provisioning the environment, as the code is compiled and deployed, it means changes to this environment to suit the needs of the application, work hand-in-hand.
Regarding security of deployment and environment keys, every major cloud provider has a service for key management. Use it! If you don’t trust the provider for whatever reason, then implement your own.
Either way, the keys to deploy to the production environment should only be accessible and used programmatically by the CI/CD tooling. Distributing keys to team members, trusted or otherwise, is not best practice and should be discouraged.
Fallacy 2: No ROI with cloud infrastructure
Attempting to attribute ROI to cloud spend is futile. However, while investment in creating a data centre (DC) might be capital expenditure, there is seldom any directly attributable ROI. Instead, the assets are depreciated over a number of years. Running of the DC is operating expense – just as spending on a cloud environment would be. Why make that huge investment in on-premises hardware only for it to depreciate?
Additionally, there are hidden overheads to running DCs on premises. There are always people required to operate and maintain the hardware that gets lost in the calculation and can hugely deflate the true cost. This is potentially avoided with good implementation of cloud infrastructure.
Building on-premises hardware also leads to a false economy where the DC built may no longer be fit for purpose. Efforts are then made to “sweat assets” or hold on while it is underperforming. This creates barriers to true product innovation and development. Effort will probably be spent tinkering around the lack of capacity instead of focusing on what customers really want from your product.
Fallacy 3: You need a fast, expensive connection
The argument here is usually around the bandwidth and cost to connect to cloud-hosted systems for your company.
This is, for the most part, a myth. Over the past 20 years, huge investment in telecommunications infrastructure has led to an abundance of broadband services at affordable rates.
Fallacy 4: Vendor lock-in
What if you choose a cloud provider and two years down the line, regret it? Surely changing providers is a prohibitive undertaking?
There’s a lot to unpick here and it is a valid risk. But as with everything, if you’re clever about it, there is no reason why it needs to be an issue. Again, there are some steps you can take to mitigate this happening.
- Ensure your infrastructure is code in the first instance – Invest in training your developers or hire experts to help kick-start this in the right way. Couple this with making sure the code you write is transpiled into the appropriate cloud language (cloud formation in the case of AWS). This technique exists to make it easier to change providers at a later date. There will be some infrastructure that is specific to a particular provider, and changes will have to be made here and there, but if you approach this purposefully you’ll be aware enough to lessen the choice.
- Use an orchestration system common to all cloud providers – Kubernetes has emerged as the platform ‘de rigour’ across all major providers. In theory, it’s as simple as repointing your deployment to another provider. In practice however, there is always some work to be done, so do account for this if changing provider is important to you. Additionally, managed Kubernetes provides a smoother learning path than setting it up from scratch.
- There’s little difference between the major providers anyway, so don’t expend effort on something that isn’t a problem
Your developers are best placed to know which provider they want to use, based on how they work themselves. As such, you need to make the hosting costs a problem the developers actively look out for.
Make it an objective for the team to try to save a certain percentage every few months and see how far they get. You’d be surprised how effective software engineers can be at solving problems like this if you empower them to do so.
Should you do it?
While I’ve talked at length about mitigating the negatives of migrating to the cloud, there are also plenty of benefits to take advantage of too such as rapid release and set-up time, zero admin hosting and easy to understand infrastructure.
Taking all of that into account, I see little reason why a move to the cloud shouldn’t be part of your company’s IT strategy today.
