The cloud is ultimately just about hardware. You are running your code on someone else's hardware because either you don't want to run it on your or you don't have enough of your own hardware to do so.
Now, lets assume the answer is that you don't want to use your own hardware, for whatever reason, and will be running your code on someone else's hardware. In addition to the money cost ($-cost) you will be paying for that hardware there is also the time cost (T-cost) and complexity cost (C-cost).
T-cost represents the effort it will take to get your solution running on someone else's hardware. This can be as simple as a few config changes and deploy scripts but can also involve custom code. Depending on your architecture the T-cost could be a one-time constant or could scale with your entire solution.
C-cost represents the effort it will take to make any changes to your solution because it's running on someone else's hardware. You want to add a new feature and if your solution was a single program running on your desktop it would take X time, but because it's a distributed system running on an unknown number of someone else's hardware it takes twice as long to do.
T-cost mostly comes from optimization. You can take a solution that runs on your dev box, put that in a single VM and run it on someone else's hardware and it will work. But it doesn't scale much and you are paying a constant $-cost regardless of how much it is used. Making your solution scale generally requires breaking it up into smaller components that can be scaled separately. There are other optimizations you can make, often vendor specific, that can improve your solution's performance but are only available because (and were probably caused from) you are running on someone else's hardware.
C-cost scales with T-cost. If you do little-to-no optimization for running on someone else's hardware then there is no real impact to your solution and you will be just as productive as when everything was running on localhost. So all the effort you put into T-cost to improve your scalability/performance/$-cost comes with an additional cost of C-cost.
Now there are two processes you can follow to get to a cloud solution.
Start it from the beginning as a cloud solution
Start it as a "normal solution" and then at some point in the future migrate it to a cloud solution.
The vast majority of the time option 2 is the correct way to go. Why? Two reasons:
Get to market. You will get a usable solution much faster and get feedback earlier to improve it...or maybe cancel it because you learn your solution was based upon incorrect assumptions.
You original assumptions around how much you needed a cloud solution were wrong. What if running a single VM is actually sufficient for your solution's needs? What if you only needed to optimize one part of your solution, rather than make everything horizontally scalable? Cloud solutions are all about optimization and unless you know a LOT about a problem you should almost always get a simple solution first and then optimize as needed.
One of the great things about modern software tools is that with containers you can easily deploy your dev environment to run on someone else's hardware. So even for the cases where you could run on your own hardware but choose not to (aka almost every personal project that needs to be internet accessible) you can still have your cake and eat it too.
TLDR: You won't know how much cloud vendor features you need you have a working solution running in the cloud, so get a working solution first and then worry about the cloud.
I wish I could give you a gold star 😂. This is the kind of comparison I was looking for. Do you have any recommendations for "normal" providers (i.e. linode, bare-metal)
Unfortunately I cannot help you there - at work we use our own data centers and 95% of my personal projects are just for me so just run on my desktop.
What I will say is that there is nothing wrong with using a cloud providers from the beginning - what I would stay away from is all of their special tools and apis that they offer. Most providers have ways to easily run popular platforms (NodeJS, .NET, Java, Python, Ruby, etc) in such a way that none of your code cares that its running in their cloud.
As an example, I've recently been working on a personal project that's for 5 people rather than just me so I needed some way to host it. After about 20-30 minutes of comparisons I went with Heroku because the project involves a NodeJS app that uses a Postgres and they offered seamless hosting of those tools. While working on the app and with the DB locally 0% of my code referred to Heroku. The only special stuff was deploy scripts and different environment variables.
The cloud is ultimately just about hardware. You are running your code on someone else's hardware because either you don't want to run it on your or you don't have enough of your own hardware to do so.
Now, lets assume the answer is that you don't want to use your own hardware, for whatever reason, and will be running your code on someone else's hardware. In addition to the money cost ($-cost) you will be paying for that hardware there is also the time cost (T-cost) and complexity cost (C-cost).
T-cost represents the effort it will take to get your solution running on someone else's hardware. This can be as simple as a few config changes and deploy scripts but can also involve custom code. Depending on your architecture the T-cost could be a one-time constant or could scale with your entire solution.
C-cost represents the effort it will take to make any changes to your solution because it's running on someone else's hardware. You want to add a new feature and if your solution was a single program running on your desktop it would take X time, but because it's a distributed system running on an unknown number of someone else's hardware it takes twice as long to do.
T-cost mostly comes from optimization. You can take a solution that runs on your dev box, put that in a single VM and run it on someone else's hardware and it will work. But it doesn't scale much and you are paying a constant $-cost regardless of how much it is used. Making your solution scale generally requires breaking it up into smaller components that can be scaled separately. There are other optimizations you can make, often vendor specific, that can improve your solution's performance but are only available because (and were probably caused from) you are running on someone else's hardware.
C-cost scales with T-cost. If you do little-to-no optimization for running on someone else's hardware then there is no real impact to your solution and you will be just as productive as when everything was running on localhost. So all the effort you put into T-cost to improve your scalability/performance/$-cost comes with an additional cost of C-cost.
Now there are two processes you can follow to get to a cloud solution.
The vast majority of the time option 2 is the correct way to go. Why? Two reasons:
One of the great things about modern software tools is that with containers you can easily deploy your dev environment to run on someone else's hardware. So even for the cases where you could run on your own hardware but choose not to (aka almost every personal project that needs to be internet accessible) you can still have your cake and eat it too.
TLDR: You won't know how much cloud vendor features you need you have a working solution running in the cloud, so get a working solution first and then worry about the cloud.
I wish I could give you a gold star 😂. This is the kind of comparison I was looking for. Do you have any recommendations for "normal" providers (i.e. linode, bare-metal)
Unfortunately I cannot help you there - at work we use our own data centers and 95% of my personal projects are just for me so just run on my desktop.
What I will say is that there is nothing wrong with using a cloud providers from the beginning - what I would stay away from is all of their special tools and apis that they offer. Most providers have ways to easily run popular platforms (NodeJS, .NET, Java, Python, Ruby, etc) in such a way that none of your code cares that its running in their cloud.
As an example, I've recently been working on a personal project that's for 5 people rather than just me so I needed some way to host it. After about 20-30 minutes of comparisons I went with Heroku because the project involves a NodeJS app that uses a Postgres and they offered seamless hosting of those tools. While working on the app and with the DB locally 0% of my code referred to Heroku. The only special stuff was deploy scripts and different environment variables.
This deserves to be a blog post 😄
I think the reasoning is very good. Going to the cloud directly is a kind of premature optimization.