When we need to migrate workloads to the Cloud or build a greenfield environment in the Cloud, a point of discussion that often comes up is which Cloud provider to choose? The decision is often straightforward for organizations that are already on a specific Cloud for the last several years, and have adopted a specific Cloud provider. For any new workload migration or to build Cloud Native Apps, for obvious reasons that specific Cloud provider is often the preferred one. Unless, there is a compelling reason to look at some specialized capability of another Cloud provider.
However, there are many organizations today who have only moved a few workloads to the Cloud or none at all and plan to migrate their on-premise data center workloads in the next few years. For these organizations, it becomes critical to decide which Cloud provider to choose.
Choosing a Cloud provider is not easy. Also it is difficult to do an apple to apple comparison between the Cloud provider’s services. A holistic approach needs to be taken to identify the appropriate Cloud provider for an organization.
The decision gets complex as the service offerings of the big three Cloud providers, Amazon Web Services, Microsoft Azure and Google Cloud Platform are comparable and constantly evolving. More importantly, the decision is just not about the service offerings of the Cloud providers but also to understand the internal business and technical requirements and also the challenges of the organization to move the workloads to the Cloud.
While Amazon was far ahead in its capabilities at the onset, Microsoft Azure picked up in a big way in the last few years and Google Cloud Platform has now become a definite option to consider. The service offerings and feature gaps between the Cloud providers are reducing. Organizations are also adopting Multi-Cloud strategy and Hybrid-Cloud strategy, including a set of workloads residing in the on-premise data centers and Private Clouds. Coexistence of workloads on-premise and in the Public Cloud brings in another set of challenges from an operational and management perspective.
Adopting a Public Cloud platform would need a different approach for an Enterprise and a Startup. For a Startup having specific application stacks the focus will be on the specific set of Apps. Whereas for an Enterprise it needs to be more broadly thought through with hundreds of applications that need to migrate to the Cloud. The support model, agility and flexibility in adopting new technologies are also significantly different in startups, which are generally not suitable for enterprises.
My recommendation for startups is not to limit their search with just the big three Cloud providers. Explore other platforms like Digital Ocean and Heroku too (there are many more exciting platforms and I have picked these two as examples only). These platforms might be meeting the requirement of the use cases, roadmap items, performance demands and could be cost effective.
Identifying an appropriate Cloud provider is complex. Before directly jumping in to identifying a Cloud provider, it is important to first understand some key elements of the existing environment and the organization’s business vision and technology roadmap.
- Business Driver. What are the business drivers behind moving to the Cloud? It is an essential understanding necessary to set expectations and have clarity on what to achieve by moving to the Cloud. Is it to move out of data centers due to expiring leases, aged hardware, bring more agility to business applications, improve performance and scalability, disaster recovery, potential cost saving?
- Digital Transformation. Would the apps hosted on Cloud intend to bring digital transformation to the business i.e is there a plan to have a new way of using technology to run the business? Are transformation necessary to adopt to new models of business processes?
- Migrating workloads. While planning to move to the cloud my recommendation is to start thinking ahead on the migration candidates. What are the workloads that would potentially move to the Cloud? Are they specific applications, or are there hundreds of virtual machines and applications in the data centers? Are there bare metal servers and operating systems which will not be able to be ported to the Cloud? Would there be a need for hybrid-cloud connectivity?
- Apps driven, not Infra driven. Start thinking about the Apps landscape and not the Infra landscape to start with. Moving to the Cloud is not shifting the infrastructure from the on-premise data center to the Cloud IaaS platform and continuing to operate the way it was operating. That will not bring real value of adopting Cloud. The approach of managing workloads on Cloud would be significantly different from what is done traditionally in data centers. Lift and Shift could be the fastest option to take the workload to the Cloud, but as a next step optimizations are necessary to benefit from the capabilities of the Public Cloud.
- Adopt new processes. Moving to Cloud invariably challenges the existing processes. There are impacts on finance processes (moving from Capex to Opex with variable monthly charges), app dev (eg, using elastic architectures for the apps, and required code updates), team composition (having multi skilled Site Reliability Engineers or the likes and not siloed specialists), agile approach to change management, speed of delivery. Along with change of processes there needs to be a mindset change as well within the organization.
- Roadmap. Look at the current scope and the future aspirations, the business vision and the technology roadmap. The evaluation needs to consider not only the current workloads but also the potential future workloads too and have a well thought through strategy. The strategy should support the aspirations to convert to reality.
Once the current landscape and expectations from moving to the Cloud are well understood, the next step is to identify the list of criteria that would help make the decision. These criteria will become the framework to compare the Cloud providers against the organization’s requirements.
As part of the exercise it is key to acknowledge that it is not the comparative study of the Cloud providers that are required, but a comparison against the list of criteria that matters to the organization’s current scope and roadmap.
In this article I document my thoughts on the list of criteria to identify a Cloud Provider. I do not compare one Cloud provider against another, instead the focus is on documenting the criteria which can work as a framework in the decision making process.
Criteria to choose a Cloud provider
- Business decision. Is there any business reason to consider or to not consider a specific Cloud provider? For example, there are retail companies who do not choose AWS platform as Amazon is a direct competitor to their business.
- Data residency restrictions. Are there any restrictions whether the data needs to reside within a specific country? Are there multiple regions available for the Cloud provider within the country to host all the required services? The data stored and processed in the Cloud provider’s data centers should meet the regulatory, compliance and data privacy requirements of the organization.
- Compliance and regulatory requirements. Based on the compliance and regulatory requirements of an industry, an organization may need to be compliant with certain industry certifications like PCI DSS, ISO 27001, HIPAA etc. Compliance in the Cloud is a shared responsibility between the Cloud provider and the customer. Does the Cloud provider meet the compliance and standards required for the services that are required?
- Partner support. Choosing a Cloud provider is like choosing an outsourcing partner. It will be a journey over the coming years. Would you trust the provider as a partner to guide and support actively when there are issues? Cloud is not all shiny pieces of software. There will be issues. Plan ahead and architect for failures and disasters. What kind of 24x7 support and response time is available from the Cloud Provider? How engaging will the partnership be? Partner support may not be relevant for a direct Cloud provider if there is a Managed Services Provider who would manage the environment.
- Existing vendor relationships and influence on cost. Is there any existing relationship with a Cloud provider which will significantly drive discounts, credits and cost? Will that be one time benefit or continuous benefit?
- Analyst reports. Study the latest analyst reports for the in scope service offerings, for example the Magic Quadrant reports from Gartner. These reports provide very valuable insights.
- Current service offerings. Are the service offerings meeting the current technology needs and the organization’s roadmap items. It is necessary to deeply review the features of the offerings, service level objectives and the finer details. The offerings of the different Cloud providers may look similar at a first glance but going under the hood may reveal features or the lack of it, which may be crucial in the decision making process.
- Evolution of the cloud offerings and roadmap. The offerings of the Cloud providers are continuously evolving. Specific features that may not be available today may be launched in the near future. It is best to reach out to the Cloud provider’s representative to discuss these roadmap items. Not all roadmap items are available publicly and hence a direct discussion may reveal more than what is available on the Cloud provider’s websites. Would this align with the organization’s roadmap and timeline requirement?
- Lock-In. This is a debatable topic and needs deep analysis of the products to be used. On one hand there are certain capabilities of the Cloud provider which will improve efficiency and optimization. On the other hand, there will be re-architecting and switching cost to move out of the platform. What will be the effort and cost of exiting from the Cloud platform? How difficult will it be to stop using the cloud service and start using on-premise or port it to another cloud? While these are valid questions, it is also important to understand about the other aspect. What efficiency and performance will be lost in not using a certain service? Not using a certain Cloud service may also increase operational effort and cost. For example, using an app installed on an IaaS instead of using a PaaS service may not be the best judgement call, just to avoid the lock-in in the longer run. Cost of operations may far exceed the cost of switching later, if at all required. This is a matter of architecture trade-off and balanced decision making and needs to be evaluated on a case by case basis.
- Cloud provider regions. Check the number of regions and availability zones the customer has in the country the services and data need to be hosted. If there are no regulatory restrictions on storing data in a particular country, consider the regions where there would be the most number of users. Also keep in mind that the cloud service charges vary from region to region and all services may not be available in all regions. It is best to review the requirements against the services available in each region.
- Networking latency. Check the network latency that the users will have when using a specific cloud. If there are applications that need to coexist on-premise and in the Cloud, check if there are any network latency dependency which may have an impact on the performance. Will it be achieved for a specific provider?
- Cloud consumption costs. It is recommended that with your sample inventory that will be hosted in the Cloud, run the monthly cost calculators to check the comparative monthly consumption costs. Check the discounts that will be available by use of reserved or committed use instances. Based on your requirements check the factors that will potentially have a larger impact and check the comparative costs.
- Network egress costs. Review the network egress cost of the Cloud providers. It may not be initially apparent but the network egress costs may actually be a significant amount in the monthly consumption bill.
- Service Level Objectives. Review the service levels that the Cloud providers provide for each required service. Reading in detail would reveal that all Cloud providers do not provide the same level of Service Level Objectives. Check if the available SLOs meet the organization’s requirements. If your desired SLO is not available, check with the Cloud Provider representative if that is on the roadmap. Often these are roadmap items and by the time of going live on the Cloud, these SLOs may be available.
- Software licensing impacts. Review the licensing requirements for your operating systems and applications and the cost impact of taking them to the Cloud. The license costs of operating systems and softwares may vary between different Cloud providers. Are there any licensing policies that can be benefited when going to a particular Cloud? Does the Cloud provider allow to Bring Your Own License (BYOL) to the Cloud. Also check out whether all the required softwares and databases can be run in the Cloud.
- Security features. Review the security features available in the Cloud. Are all the required Security Compliance certifications available for the Cloud provider which are required for your business?
- Knowledge of your team. It is important to understand the capabilities of your team who will be managing the environment. There are excellent learning materials, training and labs available. The vendor certifications are a good milestone to build a team’s capabilities. This point is not very relevant when a Managed Service Provider will manage the environment.
These are a list of criteria which you may use to evaluate which could be the most appropriate Cloud provider. Not all criteria listed here would be relevant to all situations. I do not believe this is an exhaustive list and I am sure some situations and edge cases will entail looking at a few other aspects too. Also talk to your industry peers and check their feedback on the Cloud services they use. Ask the Cloud provider for reference customers and discuss with them, if possible and take feedback.
Adopting a Cloud is the start of a journey and a partnership. Doing due diligence prior to starting the partnership will reduce surprises during the journey.