tl;dr: Starting out with containers that have no own state, running on x86 on Linux has the highest chance of success I'd say, and when you grow, you have the capability to flow between IaaS, PaaS and SaaS and all-in-one clouds as you wish. That means that your 'first' service provider is irrelevant if you don't have pre-existing knowledge or affinity. If you can produce good container images, you can run anywhere.
At some point 'the other clouds' aren't as relevant.
Think about the following interactions instead:
- CNCF compatibility (interpret as deep and as wide as you like)
- Infrastructure vs. Platforms vs. Services
- Legal boundaries
- Locality (can interact with legal limits, but also latency, transfer costs)
- Scope of services vs. scope of what you actually need
A lot of providers are good at a thing, and bad at everything they tack on to it. Some providers are reasonably good at many things, but win on integration between those things. Others are simply too dissimilar to orchestrate, so either you'll have to bring your own orchestration or not use it in orchestrated scenarios.
Instead of knowing about the clouds, know about requirements engineering. Fitting your needs and the services you pay for is way more important than the details of those needs and services.
If you just need some random compute (read: a shell into an OS, a complete VM, a container, things like that) and nothing else, do NOT use some cloud. It will require you to do a lot of other things as a side-effect of using those services at all, and will cost a lot for what you need.
On the other hand, if you need to be highly elastic, have completely managed RDBMs on-demand available and orchestrate networking, IAM, object storage, block storage, compute and ingress, do start out with a cloud.
Regardless of what you are building, make sure you know ahead of time if:
- What your scaling is going to depend on (usage, work hours peaking, seasonal peaking, tenants)
- What your scaling is going to be like (horizontally scale and spread the load? vertically scale for a few weeks until you reach the scaling limit and then rebuild the application the right way instead? deploy one instance per customer?)
- What availability rules are you going to have? (downtime? data loss? time to recover?)
- what legal limits will it have?
Example for a MVP SaaS: say you want to manage shopping lists for consumers, you might call it Shoppr and build a PWA and a app-wrapped PWA so you get immense reach. You mostly have front-end engineers, but you do know a bit about metrics and scaling.
I'd say that means:
- Downtime for a few hours unlikely to tank the business
- Legal limits are basically just generic data protection
- Scaling is likely linear
- Since your data is mostly basic CRUD, any read-replicated system will do
This can be built using any stack, and as long as your persistence can keep up you're golden. Don't fuck it up with an ORM that doesn't know how to create the proper indexing rules on tables and you can easily get a couple of million customers on an IaaS-only provider that just has virtual machines or containers, and only has one flavour of persistence store. Plonk Cloudflare in front of it and done.
You can make this infinitely more complicated, but as an example add this feature to make this entire setup suck and the entire infrastructure incompatible with the needs of the application: international receipt scanning to recommend/autocomplete shopping lists for customers. Suddenly your requirements are expanded with:
- Incoming upload queue
- Object storage for image blobs
- OCR or ML pipeline to process images
- ML or Analysis pipeline to make sense of the contents of the now processed/read images
- Instances or expansion for all of the above per region
To make your traffic bill not suck you'll need endpoints in most major regions, and you'll probably want to prevent cross-region transfers so you'll want multi-region compute. Since you don't really have to do the processing realtime, you'll be doing some queue work and perhaps have a DLQ that needs human intervention or QA analysis for product improvement. All that stuff also needs a 'control panel' for lack of a better word so you'll be adding backoffice systems too, and those will have a workflow that doesn't compare to consumers at all and should never share any interaction with them, so now your application tenancy requirements change as well, which flows down into infrastructure requirements. At the same time you'll also need training data or validation data, and you'll want to be able to do all of that elastically to not go bankrupt for paying for 100% of capacity that you'll use 50% of the time at best. Suddenly 99% of the vendors are unable to provide what you need and the 'big three' remain (well, not exactly, but for illustrative purposes this will do).
Considering a good SaaS might grow, make revenue and be sold or be valuable etc. there will be requirements stacked on top of everything else about redundancy, durability and availability and those will be increasingly hard to guarantee in an IaaS-only provider or PaaS-only provider scenario.
When you 'start' with a SaaS, you'll need to know what you need now, and what you might need in the near future, and make sure that whatever you do now doesn't paint you into a corner within weeks. That means that setting up IIS on a Windows desktop by hand on a VPS at some IaaS hosting provider is highly unlikely to be a good place to start. On the other hand, an equally janky setup with a random Ubuntu VM where you manually install Docker and say, Nomad might actually not paint you into a corner too much since a container can easily be run on a container-PaaS and Kubernetes beyond that.