The documentation is thick but it has a common theme and format to it. So once you get the hang of finding the "juicy bits" you can usually locate them anywhere. The docs do generally warn you of these cases, or have a whole "best practices" section which highlights them directly.
The key is, do not make decisions lightly in the cloud, just because something is easy to enable in the UI does not mean it's recommended. Sit down with the pricing page or calculator and /really/ think over your use case. Get used to thinking about your infrastructure in terms of batch jobs instead of real time and understand the implementation and import of techniques like "circuit breakers."
Once you get the hang of it it's actually very easy and somewhat liberating. It's really easy to test solutions out in a limited form and then completely tear them down. Personally I'm very happy that I put the effort in.
I am 100% not willing to put that much effort into it.
Actually I am not willing to spend that much time reading "cloud" provider docs and best practices.
What I care about is hosting services and getting the mission done. I value predictable and reasonable costs much more than "flexibility".
In general whatever host I have ever used typically have "cloud" offerings too. So real services go to dedicated hosts, experiments go into 5 buck a month vms.
> It doesn't take that much time just intentional reading to learn something new. Do you not read any docs?
There is a tradeoff, between the time it takes to read the docs and the time it would take to achieve what you want to do with another tool which you are either familiar with or is simpler. A very important factor for that balance is how reusable and how reapplicable the knowledge you will gain will be. I am perfectly happy reading docs for PostgreSQL, Varnish, nginx and many other things if it will help me achieve my goal. But when it comes to cloud providers I am not willing to spend a minute reading how to vendor lock my stack on their platform. If there is a standalone service I might want to use like SQS or SES sure, but most other things are a hard pass, I would rather have a dedicated host.
> The point is that these aren't mutually exclusive.
They are really not, cloud providers charge incredibly high rates for both bandwidth and computational resources so there goes the reasonable part. The usage based pricing they use is typically not capped so you are always a misconfiguration away from incurring many times your monthly costs on bandwidth charges (see a similar case from azure https://news.ycombinator.com/item?id=30054739). To add insult to injury you usually get inferior performance.
> And when it becomes overloaded, needs upgrading, or requires other maintenance? There's a problem I've completely left behind.
You have replaced these problems with having to deal with the cloud providers. It costs time to deal with their impenetrable pricing, processes and abstractions. Do yourself a favor and track how much time you spend dealing with their tools and how much time and effort you spend trying to optimize costs.
Upgrades and maintenance are not really solved, depending on the products you use. If you are using EC2 you still need to do upgrades and maintenance exactly like you would with bare metal. Now if you are using a serverless approach you might be clear of that too, but in general docker helps a lot with removing a lot of the pain of using bare metal.
Overloading is typically easily solved by over provisioning and yeah if you have very spiky usage patterns it might make sense to use a cloud provider. If your typical load can be dealt by 1 Hetzner node but you need 20 nodes 2% of the time you might be better off using a cloud provider. Modern hardware though has a lot of capability and while you don't have an "entire datacenter" to fall back on like you would with AWS a few bare metal nodes can handle a very large volume of requests depending on your use case.
