I believe this all depends how you're using Cloud. You have to pick the right tools for the job at the end of the day, and my choice is: all of them.
I have a small book I'm going to be releasing soon. It's going to be self published as it's an entirely online mixed media book (text, videos, quizzes, etc.) and I'm going to be packing it all into a Go binary (minus the videos, those will be on YouTube) to make deployments insanely easy.
(The binary will be less than 50MB in size - smaller than most Docker images. It can also be made to run on any OS I care about without a third party tool. Just sayin'.)
I have a 100/100 fiber line here at the office with an SLA. I have plenty of hardware too. I could self host it here, but instead I'm going hybrid.
It's simply too easy to spin up an EC2 instance fronted by an ALB, TLS being handled by ACM and DNS by Route53, all "as code" (Terraform is my weapon of choice.) I can buy that instance as a reserved instance and pay up front for the year too, reducing its cost by 45-50%.
Then I can attach that instance to an AutoScaling Group with a minimum of '1'. If I get traffic influx it will scale out to meet the demand at per-hour costs. It's more expensive but it shouldn't be for long.
If the (static) instance goes down the ASG brings one back up at "full fat" per-hour fees... but at least I'm up and running.
The landing page is static and delivered via CloudFront, and that's what most people will be hitting. The application won't even see that traffic at all.
As for on premise: I'll be self-hosting analytics here and also logs from the application and servers. Why put them on expensive compute in Cloud when I can just do it here locally on a cheap quad core with 16GB of RAM and TBs of NVMe storage? It's a no brainer really.
So you have to pick your weapon correctly. For this project, here are the weapons I'm selecting: AWS EC2, ACM, ALB, Route53, CloudFront, S3; YouTube; on-premise hardware for analytics and logs.
That seems overkill for just hosting 2 static files (the go binary and the html file). Why not just use github or something to host those 2 files for you for free?
The Go binary is a custom web server for handling access to the book. This will be similar to how a few other book authors have handled access: a link you click in an email (like a one-time sign in token) that gets you access. The Go binary is also responsible for receiving and resolving Stripe Links web hook calls.
The book itself is made up of hundreds of pages, images and more. It's all built using MkDocs + Material.
The custom workflows meant I needed a small, custom app.
I have a small book I'm going to be releasing soon. It's going to be self published as it's an entirely online mixed media book (text, videos, quizzes, etc.) and I'm going to be packing it all into a Go binary (minus the videos, those will be on YouTube) to make deployments insanely easy.
(The binary will be less than 50MB in size - smaller than most Docker images. It can also be made to run on any OS I care about without a third party tool. Just sayin'.)
I have a 100/100 fiber line here at the office with an SLA. I have plenty of hardware too. I could self host it here, but instead I'm going hybrid.
It's simply too easy to spin up an EC2 instance fronted by an ALB, TLS being handled by ACM and DNS by Route53, all "as code" (Terraform is my weapon of choice.) I can buy that instance as a reserved instance and pay up front for the year too, reducing its cost by 45-50%.
Then I can attach that instance to an AutoScaling Group with a minimum of '1'. If I get traffic influx it will scale out to meet the demand at per-hour costs. It's more expensive but it shouldn't be for long.
If the (static) instance goes down the ASG brings one back up at "full fat" per-hour fees... but at least I'm up and running.
The landing page is static and delivered via CloudFront, and that's what most people will be hitting. The application won't even see that traffic at all.
As for on premise: I'll be self-hosting analytics here and also logs from the application and servers. Why put them on expensive compute in Cloud when I can just do it here locally on a cheap quad core with 16GB of RAM and TBs of NVMe storage? It's a no brainer really.
So you have to pick your weapon correctly. For this project, here are the weapons I'm selecting: AWS EC2, ACM, ALB, Route53, CloudFront, S3; YouTube; on-premise hardware for analytics and logs.