The biggest cloud migration challenges in 2021
One thing that we often hear at nine, being a Managed Service Provider (MSP) is "Why are you needed? Why don't we go directly to the cloud ourselves?" Although it's not in doubt that with the easy to use GUI's and extensive service offerings of cloud providers doing everything yourself appears to be a tempting proposal, but unfortunately there are a number of pitfalls to avoid and this is where working with an MSP could help you. My colleague Peter has already written about this from a more general perspective and I would urge you to begin with his excellent overview. The aim of this article is to talk a little more in detail about technical challenges that you may face and how an MSP can support you.
Range of choice
Probably the first, and most obvious, issue is simply the sheer range of choice available in the cloud. To make the move from a "classic" VM based setup to a dynamic cloud infrastructure can be overwhelming without guidance, not only do you need to select the right services, but you will need to be sure that you configure them correctly, understand the quality guarantees that are given, and design your architecture with this in mind.
Unfortunately, unless you are a very big company (with correspondingly deep pockets) you are probably not going to get the assistance you need directly from a cloud provider, indeed this is exactly why cloud providers partner with companies such as nine.
We are able to stay close to you, work in concert with you, and accompany you along your journey to the cloud. At nine because we offer both classic hosting in our datacenter and in the public cloud we are able to join you at whatever stage of the cloud adoption journey you are in, and our highly trained engineers and solution architects are able to meet all of your needs, working with you to design your architecture for evolution based best practices and industry standard open-source software.
The second issue is hidden complexity, and this is a theme that will run through the rest of this article, for example, did you know that when using GCP it is possible to make configuration changes that would invalidate your SLA with Google Cloud? For example, setting specific flags on your cloud SQL database.
It's fair to point out that to avoid these you just need to RTFM, but GCP has a pretty big manual and it's always easy to overlook something that might have an impact later, especially if you are focused on your product and getting the next release out of the door.
Allowing someone else to perform this infrastructure setup, using Infrastructure as Code (IaC) principles with strict review and update practices (such as the four eyes principle) goes a long way towards mitigating these issues, and although it might feel like a loss of control to allow someone else to maintain this configuration, it's a level of control that you don't actually want, or indeed need, when your company or product value is derived from elsewhere.
Cost optimisation is often an issue that people want to tackle when they decide to move into the cloud, but a pure life-and-shift approach can actually end up costing you more since there is hidden complexity in ingress and egress traffic, failing to optimise the size of machines or services that you use and so on. Flexera's "State of the cloud 2020" report states that "Organizations are over budget for cloud spend by an average of 23 percent and expect cloud spend to increase by 47 percent next year." this might be quite a startling read if your plans for cloud adoption revolve around this lift and shift approach.
However the same report states that "organizations waste 30 percent of cloud spend" which suggests that with the right guidance and architectural design it would be possible to realise the saving that people expect from moving into the cloud.
An MSP, if they have trained solution architects and cloud engineers, will certainly be able to help you in making these savings and moving into the cloud in a cost effective way through support, training, workshops and working together.
If you choose to run everything yourself in the cloud one of the first hurdles that you will encounter is how to robustly monitor your application. As anyone who has run an application in production knows accurate and robust monitoring is the key to understanding what is happening at runtime, and what the quality of your service is like for your customers. Even with an MSP there is no way around this, as only you have the knowledge to pick the metrics that really matter to your customers and which you will use to measure service quality, but if you have to run your own monitoring system as well, you will face critical additional problems.
Monitoring is in fact so important that if you run everything yourself you will quickly realise that keeping your monitoring system up and running becomes more important than looking after your application, since without it you are flying blind. This means that significant resources would have to be devoted to implementing, running (and eve7n monitoring!) your own monitoring system.
This is certainly one place where an MSP can provide great value by provisioning and ensuring the quality of these auxiliary monitoring services. Nine operates a strict SLA/SLO principle for services that it offers, to ensure that they are available when you need them, and we have SLA's to ensure that we are bound to provide a level of service that meets, and ideally exceeds, your requirements.
Know How + Training
You may hope to overcome this monitoring reliability issue yourself by choosing to use the specific monitoring system implemented by your cloud provider of choice, since these will in theory, produce the most detailed metrics and be the most stable. However this creates a pressure on your business, it not only creates a vendor lock in to that cloud monitoring system and thus that cloud provider because the software and configuration is not portable to other setups, but it will require extensive training and education to extract the most value as you must adapt to its specific paradigms.
This time investment in a closed system obviously does not create value for you and again this is where an MSP can help, by deploying portable, open-source, industry standards for monitoring (which in the container world is usually Prometheus/Alert Manager/Grafana) an MSP can help to ensure that you focus your efforts on the part of monitoring that matters for your product’s success, defining your own SLO/SLI's based on the issues that your customers really feel.
If you need help with understanding and defining those, most MSP's can help there too with consulting and enablement services that put their engineers together with yours to determine your golden signals.
Beyond monitoring if you wish to adopt cloud best practices and DevOps workflows you will need a robust toolchain and experience that allows you to build and deploy your application easily. The same problem as with monitoring arises again; these systems quickly gain as much, if not more, importance that your app since delivery of new features, critical bug fixes and so on become reliant on these systems working. This is particularly true in the world of containers and orchestration platforms where there are no such (dangerous and not recommended) workarounds such as FTP'ing files to a server in the case of last resort.
Again this is where an MSP can help you by providing these services, and again they should be industry standard, portable, open-source tools, with ensured service reliability and quality so you can keep focused on your application.
Nine is particularly specialised in this area, having many years of experience of running both our own and customers containers in production, and this is why our platform offering is not simply a managed vanilla GKE instance but comes with all of the tools that you would need for an end to end cloud native workflow for image building, packaging, deployment, backup, monitoring and so on.
Indeed the system that we have developed allows you to go even further than this, by building on cloud standards you can easily deploy pre-made services into your cluster via helm charts, you can configure complex red/green deployments with traffic balancing to test new features, see the status of all the components of your application at a glance and roll back to a previous version easily.
We not only preach these practices, we live by them, we are using exactly the same systems as we provide to you to stage our components in both our clusters and those of our customers.
Since "Lack of resources/expertise is cited by 41 percent of respondents as a top container challenge" according to Flexera, nine has introduced all these features as standard with our Kubernetes offering to give you an experience that no other managed service provider can match (and I say this without hyperbole, if you can find a managed kubernetes offering as holistic as nine's please get in touch with me!) along with regular workshops, our kubernetes academy and the option for individual consulting and even project work and support.
The nine Difference
The engineers that build and maintain our managed Kubernetes platform and clusters have many years of experience of running containers in production and have administered both Openshift and Kubernetes clusters. They all hold CKA and Google Professional Cloud Architect certifications and they work with the same tools and technologies as we offer to our customers every day.
All of these reasons are why we call ourselves "cloud navigators", at nine we pride ourselves on our ability to work closely with our customers to guide, assist, teach and support at every step of the way. To ensure that you are able to deliver the maximum value to your customers with the most robust and flexible architectures possible is our passion and we hope to join you on your journey to the cloud.