As our previous post on comparing cloud service providers (CSP) shows, financial models alone are insufficient criteria to make an impactful decision on which cloud you should run your entire business on. Choosing the cloud service provider that’s “right” for your business can be subjective, but it helps to start by asking yourself some guiding questions:
- What are your goals for moving to the cloud?
- Are there any other departments or divisions within your company that have already started experimenting with cloud services?
- Will you attempt to be cloud-agnostic in your service and tooling choices?
- How will you decide which of the hundreds of cloud services offered by each provider to use?
- Looking at your current application portfolio, can you directly migrate to the cloud or would it be more prudent to refactor?
Switching costs may not be as low as advertised, so it’s important to choose a CSP that you envision being beneficial in the long term. Let’s walk through some potential impacts.
What are your goals for moving to the cloud?
Companies choose to move to the cloud for many reasons. Many believe it will save them money, either through movement away from capital expenditures, reduced overhead, or increased economies of scale. Cost savings can certainly be achieved through behavioral and workload changes, but these savings are unlikely to give you a sustainable advantage over your competitors. Advantage stems from innovation, and this is where public cloud shines.
Each CSP continually adds net new services as well as increased functionality to existing services. They are increasingly working their way up from building block services (primitives) to niche, industry-aligned value-added services. Each of these reset the industry playing field, increasing commoditization and freeing your teams to focus more directly on building out custom services that truly add to your differentiation from competitors.
It’s a smart move to choose a CSP who you believe will add the most value to your industry long term — especially if they offer you a seat at the table guiding their service investments. As medical records vendor Cerner said about their choice of AWS, “This is not just a cloud infrastructure deal. It’s a relationship where we’re utilizing their cloud infrastructure, but we place much more emphasis on the innovation component and the ability to innovate with AWS and Amazon.”
Are there any other departments or divisions within your company that have already started experimenting with cloud services?
If you find out there are, you should collaborate with that department on:
- Why did you pick that CSP?
- What do you like about them?
- What workloads did you move to that cloud service provider, and were there any issues?
If you choose to use the same CSP, you may unlock additional discounts and find synergies leveraging your company’s existing engineering talent.
Will you attempt to be cloud-agnostic in your service and tooling choices?
Many companies publicly claim to be agnostic in their cloud platform adoption. This keeps their options open and can increase buying power during a competitive procurement cycle. New technologies like Kubernetes can even simplify the engineering required to be cloud-agnostic.
The idea of being able to deploy the same workload to any CSP at a moment’s notice sounds great in the boardroom, but misses a critical component: data. Data is fundamental to enhancing your customer experience — and it’s getting bigger all the time. Migration of data is far less straightforward than simply redeploying a Docker container, and the larger it gets, the longer it takes to migrate. As GE found out in their migration to AWS, data has gravity. The physics of networking lends to the compute layer being placed as close to the data layer as possible. Compound this with cloud-native architectures — where you increase the number of cloud-specific services you use to simplify and expedite your development and innovation process — and it’s not likely your application deployment targets will be as fluid as you’d like.
The CSPs are aware of this fundamental truth and optimize incentives towards those who go “all in” on a single CSP. You should measure your use of agnostic tooling — which often comes with its own complications like a minimal talent pool available to support — to only those services which are most likely to be needed in the multi-cloud or poly-cloud environment you’re actually planning, and minimize cycles, overhead and costs burnt on “what if” scenarios. If the service or tool is as valuable as you envision, the CSP will quickly offer a comparable solution — with a consolidated support path.
How will you decide which of the hundreds of cloud services offered by each provider to use?
If you’re truly cloud-agnostic this choice is easy: you’ll only use a handful of lowest common denominator services and rarely, if ever, venture outside of those to avoid vendor lockin. For the rest of us who are comfortable offloading non-value-added work to a CSP, there are more and more service options to choose from each day. The key to avoiding service — and cost — sprawl is to maintain an evaluation mechanism for cloud service adoption. In large businesses this may involve enterprise architects, boards, or centers of excellence. Common criteria used in this evaluation include:
- Suitability for production scenarios, which may involve dissecting CSP service level agreements, whether the cloud service is generally available yet, and support knowledge levels (whether in-house or managed)
- Availability of vendor substitutes: the degree to which the service adoption leads to lock-in
- Likelihood of momentum: the probability that the utility of the service will provide so greatly that it will eventually be used widely across the organization
- Productivity impact: the positive business or financial impacts that result from the service usage, at individual, department and company-wide levels
- Deployment capabilities: integration capabilities with the organization’s preferred automation tooling; availability of automated and local testing frameworks
Looking at your current application portfolio, can you directly migrate to the cloud, or would it be more prudent to refactor?
There are many paths to the cloud, and a lift and shift approach can get you there quickly. On the other end of the scale, refactoring — changing your application code — can take the longest but offers the highest benefits. However, not all applications are a fit for refactoring.
With commercial off-the-shelf software, you generally don’t have access to the source code to refactor, nor might you want to for contractual, supportability or security reasons. Those last two reasons also extend to open source software — the more you deviate from a release, the harder it may be to integrate future releases.
Custom software — whether built in-house or for hire — is the best fit for a refactor approach. The migration to the cloud is an opportune time to invest in modernization, and this extra upfront cost can pay dividends in lower operational costs and increased resiliency for the remaining lifetime of the application. A Cloud Readiness Assessment can help determine the right path to the cloud for each of your applications.
This journey of choosing a cloud service provider and considering all cloud services available is as unique as your business and should be treated as such. What works for one business, even if they are in the same industry, might not be the best for yours. And just because your competitor has chosen one cloud does not mean you should. A trusted, technology-agnostic partner like Nerdery can help you successfully navigate your cloud journey. Learn more about Nerdery’s cloud services.
