You would need to learn about automation resources a cloud provider has to deploy something. Think about a typical LAMP server: instead of you manually building

You would need to learn about automation resources a cloud provider has to deploy something. Think about a typical LAMP server: instead of you manually building the LAMP server: picking a Linux distro, installing Apache, PHP, MySQL, cPanel, etc. you will have scripts to build the LAMP from scratch and deploy your code. Minus the MySQL part of LAMP, your database would be running on a separate host, always on and available for any number of web servers to connect. That is a key concept that cloud typically requires a multi-tier architecture: a db server, multiple web servers behind a load balancer and the domain points to the load balancer. Think of it like a bunch of web servers running and you define when to scale up another one (say 75% CPU utilized), it runs the scripts to create a new web server and add it behind a load balancer when that web server responds positively to a health check. This is where containers help, you define your web server build and an image is created of that build. Then cloud provider just creates a new pod/container running that image. I tried to keep this generic, cloud providers have their own terminology on how this all works. Reading up on kubernetes will help. The decision to use cloud computing should really be based on the number of requests. You can probably safely serve hundreds to low thousands of requests per minute on a standalone LAMP server (depending on its size). A brochure website, say for a local restaurant, will not get a lot of traffic so cloud computing is overkill and will be too expensive compared with a $5/mo LAMP server somewhere. Hosting 1000 brochure websites could be a good use of cloud since a lot of them will have low traffic but if something gets a lot of attention it could be mostly hands-off to let the cloud scale up appropriately, to some $ threshold.