Future-proofing your cloud strategy
Businesses are racing to the cloud, but it’s important they don’t repeat the same mistakes as time goes on
Adopting cloud technologies is something that many organisations have struggled with, and these difficulties have been caused in no small part by large amounts of pre-existing technical debt. Legacy applications and physical infrastructure have, in many cases, become a millstone around the necks of companies who want to capitalise on the economic and transformational benefits of the cloud, leading to long migration roadmaps.
This is a challenge in and of itself, but as companies race to embrace the cloud, it’s imperative to ensure they don’t repeat the same mistakes that caused these headaches in the first place. Companies have often found themselves locked into expensive and inflexible relationships with vendors, and while this is less of an issue with the cloud than with on-premise systems, it has by no means disappeared altogether.
There are ways to mitigate the risk of cloud vendor lock-in, however, and the most important factor is proper planning. Planning is always the first phase of any cloud migration, and it’s vital to ensure that before you even open an account with a cloud provider, you’ve worked out all your application dependencies, compatibility requirements and budgets. You can then assess which cloud providers meet those needs, making it easier to identify an alternative provider to move to in the future.
Businesses should also take a long, hard look at which services they actually need to move to the cloud. Contrary to some popular wisdom, not every application and service is necessarily better off being run in the cloud. Establishing what does and doesn’t need to be migrated can save time and money later on, both in the initial migration process and potentially subsequent ones if those workloads are repatriated to on-premise systems.
Organisations should be mindful of contract lengths, too. Long lease terms on physical infrastructure are one of the biggest impediments to organisations’ cloud migrations, and although many cloud services will offer discounts on the price of longer contract lengths, this also contributes towards those same lock-in issues that you’re trying to avoid.
It’s important to remember that you can design and set up most elements of your public cloud infrastructure without spending a single penny, and you should do this as early as possible. Although public cloud providers market themselves on their ability to get up and running very quickly, mature organisations that want to undertake a comprehensive cloud deployment will quickly find that setting this up, along with all the associated account structures, security and compliance frameworks, will quickly eat up unexpectedly large amounts of time.
“None of this costs any money in terms of consumption,” says Lee Wynne, CDW’s public cloud architecture practice lead. “You can build out a well-architected multi-account AWS or Azure design, you can do all your billing strategy, and you can design and provision all your platform architecture and it costs you no money. There are no cloud consumption costs at all to do that; you have to know what you are doing but it won’t cost you a penny. So when you're ready, when that urgent project comes along, and they go ‘yeah, we need to spin this up in Azure or AWS, or GCP ASAP’, then you're ready to go. Nobody's waiting for anything, it's just done and dusted, a big tick in the box for your IT services. There's nothing dependent on this from a project perspective, no cost assessments, no buzzwords about machine learning and AI strategies, no politics.
“Now, when it comes to thinking about vendor lock-in you start thinking ‘well, should I just be doing this for one platform? Or should I do it for all of them?’, because it's the same. That strategy is the same across AWS, Azure or Google Cloud. They all have the same thing: a multi-account structure and a platform architecture, all can be designed and configured with no consumption so it's not too difficult to do that for all of them. And then all of a sudden, you've got a little bit more choice and bit more flexibility about where you choose to deploy certain elements. The only complexity is how you set up network comms between them, if that even needs to happen.”
Designing your workloads and applications in such a way that they can be deployed across multiple clouds from the outset makes jumping ship to a new provider much easier, and it also has the added bonus of making them much leaner and more portable in general.
Vendors themselves have even started warming to the idea of customers deploying across multiple providers, and multi-cloud tools and functionalities are becoming increasingly common. VMware, for example, has been rapidly expanding its portfolio of multi-cloud management tools and has recently announced its plans to incorporate Kubernetes management tools into vSphere, making multi-cloud workload management even simpler. Microsoft has also got in on the trend, announcing earlier this year that Azure Cost Management will also help customers manage their AWS spending.
Another important consideration is the tools that you use to build and run your apps. Most organisations will likely construct their apps using open source (or at the very least widely supported) programming languages, but once those applications are in the cloud, it’s very easy to end up accidentally bolting additional compatibility requirements onto them.
“For example, AWS has CodeStar and Azure has Azure DevOps, and they have a lot of native tools in their ecosystem that you can use to wrap around your source code, test and deployment pipelines,” Wynne points out. “Then you become reliant on it; it becomes part of your DevOps process, and then it becomes part of your culture, and it becomes part of your team. So over time, you can easily end up locked into one of those cloud platforms, if you consume a lot of their native services around your source code, and you begin to extend it further into proprietary database services such as Google Firebase, Azure Cosmos and AWS Aurora and serverless monitoring and debugging tools.”
Vendor lock-in remains a major problem for many IT departments, and it can be just as much of a risk when it comes to the cloud. With thorough planning, good design and careful monitoring, however, it is possible to architect your cloud estate in a way that minimises the chance of your organisation repeating the same woes of time gone by. For businesses that want to ensure they’re implementing the right cloud strategies and designing their platforms in the most flexible way possible, CDW is an ideal partner for planning and orchestrating your cloud migration, bringing years of experience and unparalleled cloud expertise to bear on your business challenges.
Get in touch with a CDW Account Director and ask for details on CloudCare® JumpStart or CloudPlan. Visit uk.cdw.com
Choosing a collaboration platform
Eight questions every IT leader should askDownload now
Performance benchmark: PostgreSQL/ MongoDB
Helping developers choose a databaseDownload now
Customer service vs. customer experience
Three-step guide to modern customer experienceDownload now
Taking a proactive approach to cyber security
A complete guide to penetration testingDownload now