In the present startup and enterprise landscape cloud deployments is a norm. If you want to scale seamlessly, you need to be on the cloud either on public or on-prem. There are numerous reasons why a business would want to deploy its services on the cloud.
There are many cloud vendors in the market, some of the big ones are AWS, GCP and Azure and then there are some small players focussing on a specific niche.
Every provider has its unique technological offerings with different pricing models. Choosing the right cloud provider for our business requires some thorough research. In this write-up, I discuss various factors that come into play when researching the right cloud provider for our application.
So, without further ado,
Let’s get on with it.
1. Our business domain
By business domain, I mean the kind of application/service in a certain domain (gaming, telecom, retail, finance, etc.) we intend to deploy on the cloud. There are several things associated with this.
1.1 Does the cloud provider already has a customer similar to our business?
This is a key factor in making up your mind to pick a certain cloud provider. For instance, imagine we need to deploy an augmented reality game like Pokemon Go on the cloud and we expect it to blow up just like it.
Pokemon Go scaled to millions of users with Google Cloud. This gives Google Cloud extra points in our research for the right cloud provider, since the GCP team has already scaled a similar kind of service like ours to the moon and is aware of the intricacies of scaling a service like Pokemon.
Similarly, Fortnite scaled with 125 million players on AWS. Evernote moved their stack to the Google Cloud Platform.
We should ideally go through the customers of different cloud vendors and read how they leverage the cloud services to scale their businesses. These kinds of success stories prove that our business won’t face any sort of performance, scalability or availability issues when hit with a heavy traffic load on these respective platforms.
1.2 Be thorough with the technical requirements
There is no workaround for this. If we do not want to be overwhelmed with the range of technology offerings and pricing models cloud platforms offer, we need to be thorough with what we want.
Run a rough estimate of the deployment pricing via the price calculators offered by these vendors.
Google Cloud Price Calculator
AWS Price Calculator
Serverless Cost Calculator
Before deploying your app make sure you are ok with the pricing model and the estimated cost fits well in your budget.
1.3 Products and solutions offered by the cloud vendor in context to our use case
The cloud vendor should offer a complete range of tech in context to the current industry technology standards. And the offerings should fulfill our requirements.
Naturally, the cloud vendor should provide state-of-the-art technological offerings, products and solutions. Nobody wants to run their services on archaic hardware. To understand this further, let’s take the help of an example.
Imagine we pick a DBaaS (Database as a Service) to implement a use case. Initially, everything seems good. But as our service starts gaining traction, the log management, monitoring and other tangent services let us down. We start to feel the technological limitations of the platform. They act as a sticking point in our growth.
Besides the core service, the add-on services should be equally efficient.
What if in the future we need to move our data to a different database or move out of the cloud entirely intending to deploy our service on-prem. Does the vendor let us do that seamlessly?
Another instance, imagine we’ve deployed our service on a certain cloud end-to-end. The business is growing at an astonishing rate. Everything seems fine. To further scale we need a machine-learning solution that pulls out information from the user-uploaded images. Does the cloud provider offer us a product to fulfill our requirements? Or do we need to look out for a different vendor to do that, ending up with a hybrid cloud architecture? This is where running a proof of concept initially becomes a life savior.
The crux is the cloud provider we choose should continually innovate and upgrade to match the industry standards.
If you wish to master the fundamentals of cloud computing, check out my platform-agnostic course Cloud Computing 101 – Master the Fundamentals which helps you understand the infrastructure on which modern-day distributed applications run and much more. This is also the second course in the Zero to Software Architect learning track that educates you step by step on the fundamentals of web architecture and distributed systems design. Check it out.
2. Checkout the smaller niche players in the market
If you have very specific needs and do not wish to grapple with the extensive product offerings of large cloud providers, you can check out other smaller cloud vendors in the market like Netlify, Heroku, etc. which cater to specific niches, for instance, serverless deployments, smoothening end-to-end development and deployment workflows, etc.
An upside of working with smaller providers is that they offer very competitive pricing models, features and better support in comparison to the big guns.
3. Run a POC (Proof Of Concept) before going all in
Once we zero in on a cloud vendor, the best way to have an insight into the technology, platform and pricing model is to run a POC (Proof Of Concept) on the cloud platform.
Let it run for a while. Do a stress test on the sample app. Check if you are comfortable with the monitoring, analytics, logging and other services.
There is no better way than this to minimize any kind of issues and risks that might pop up in the future acting as a sticking point.
The pricing models aren’t that simple. For instance, if a vendor says you have x hours of instance time in a particular quota that doesn’t mean no matter what you’ll get x instance hours. Chances are you might not. The reason being, there are request and response data limits associated with the instance hour limit. If our request-response data limits get exhausted, we might not be able to use even x/10 instance hours.
4. Deployment ease. Ease of migration, Vendor lock-in
I can’t stress this enough. Always look for an open-source solution first before moving forward with custom closed-source proprietary cloud offerings. This reduces vendor lock-down risk by notches.
Don’t like the managed open-source service offering after a while? Move out to another cloud or on-prem. But if we use a proprietary service, we are in for some serious code refactoring.
5. Security
This is again a key factor for migrating or not migrating to the cloud. Check the security policies of the cloud vendor. There are domains that just cannot afford a security breach like finance, healthcare, governance, military, etc.
This is the reason most companies implement a hybrid cloud architecture. The sensitive data is stored on-prem in their private cloud. And the relatively non-sensitive data lives on the public cloud.
Organizations dealing with sensitive data typically prefer to avoid using any third-party SaaS service that streams their data onto their external servers. For instance, SaaS workplace communication tools pose a security threat as the org. data is streamed to external third-party servers. To tackle this either they ask the SaaS vendor to deploy their software on-prem or the org. leverages an open-source alternative on-prem.
Security is important, folks.
6. Support
This is another important factor to look upon when giving business to a cloud vendor. Do they have a dedicated technical support team? What is the support policy? What if we hit a wall? Is the support paid? What’s the support pricing model?
Run a Google search to get an insight into the market sentiment for a certain cloud provider.
7. Cloud platform marketplace
Cloud platforms like AWS, Google Cloud, Azure, etc. have their marketplaces that offer utilities, developer tools and services to accelerate development. Before writing a utility from the ground up, reinventing the wheel, do look into the marketplace to save resources and time.
8. Multi-cloud deployments
There are several reasons why we should consider multi-cloud deployments. The primary reason is to never put all our eggs in one basket.
9. Community opinion
Check out what the community has to say about a particular platform. Reviews and opinions come in handy when making the decision to move to a certain cloud.
This is pretty much it. If you found the content helpful, consider sharing it with your network for better reach. I am Shivang, you can read more about me here. Cheers!
If you found the content helpful, check out the Zero to Software Architect learning track, a series of three courses I have written intending to educate you, step by step, on the domain of software architecture and distributed system design. The learning track takes you right from having no knowledge in it to making you a pro in designing large-scale distributed systems like YouTube, Netflix, Hotstar, and more.
Follow Me On Social Media