I'm looking at starting a new project for myself that I'd like to grow to a good size and it has been really interesting trying to figure out whether I should go cloud-first when it comes to hosting it. I've talked to friends who specialise in the area and the general conclusion I have come back to time and again is that simply renting a server to host it is going to be cheaper than using cloud services.

That is really interesting to me - it has been hard to figure out the right architecture because any search for good practice leads to thousands of content-free articles of marketing dross so finding trustworthy sources has largely been a matter of asking people who know - but it does explain why there is such a push for Cloud everything - it is presumably far more profitable for the companies hosting it.

From what I can tell, it is useful if you are likely to have very bursty traffic and you want to be able to scale out when a lot of requests come in then scale back afterwards. Running a server capable of handling those bursts is likely to be more expensive, but if you're expecting steady traffic levels then expect higher costs for equivalent cloud services.

Is this right? I'm still trying to figure out how I can best make this work, but that's what I have gathered so far.

Yes, a single dedicated server could typically serve millions of users without breaking sweat. That provided your services are not doing any stupid things.

However, investors are unlikely to back such a setup, as they often have preconceived notions. They might ask, "What if a marketing campaign is hugely successful and you suddenly gain 100 million users? How will you scale up?" or "What if your server malfunctions?" or "You'll need to employ a full-time dev ops team."

The responses to these concerns are straightforward. Firstly, such a user surge is rare, and if it does occur, there's a chance that your service hasn't been tested in the cloud for such scenario and could fail regardless. Simply adding more machines isn't a solution; your entire application architecture must be designed to handle such a scenario from the beginning. Cloud or not, this requirement doesn't change.

In case of server failure, having a failover system is essential. Setting this up isn't too complex, and cloud systems can fail too, often with less control on your part.

Regarding the need for a dev ops team, even a small team can be more cost-effective than using the cloud.

However, convincing investors to support self-hosting is challenging. They prefer having a third party, like a cloud provider, to hold accountable if things go wrong, rather than their direct investment.

Traffic patterns typically fluctuate, often resembling a sawtooth wave, depending on the service. Therefore, your servers need to be equipped to handle these peak periods.

Thank you ChatGPT for chiming in.

@breakfast: You nailed it: Fear. Uncertainty. Doubt; Fear. Of. Missing. Out.

All the fear leads to FUBAR, which I won't break out here.

You might want to read this [1]Troy Hunt of Have I been pawned . This is an article about bursty traffic and scaiing

[1] https://www.troyhunt.com/10-things-i-learned-about-rapidly

The answer is... it depends.

Is your project going to be truly "steady traffic" 24x7, or does it have steady traffic only during the day? If you design for the cloud you could use much smaller servers and scale out as needed. Migrate to a bigger server instance size? Piece of piss.

Also, what happens if your power goes out for several hours? Are you going to keep a UPS?

Have you factored in the cost of electricity for this server?

When you say "simply renting a server" do you mean at a colo, or in your own premises?

Even with a colo, you are risking a long outage if they have a flood / fire / something you haven't thought of. So, you're gonna need two which are geographically apart.

If your project is down for a week, are all your customers going to disappear and go somewhere else? Or will they not care?

I, personally would not dream of hosting something myself unless it was very small, and I don't care about down time or very big, and not at all bursty. I actually can't think of a small project that I would host myself, but I guess there might be some.

Cloud just takes away so many headaches. They have top class security (Not Azure though). Three AZs if you want it. Backups are super easy. Power supply is reliable. Database administration is super easy. As much bandwidth as you can handle. You can go "serverless" with FaaS, at least for some jobs / workloads, which means you can scale to zero.

OTOH, it can be a confusing nightmare and they seem to release dozens of new services every month. IAM can be particularly mind blowing. If you want to even just list the tags on an EC2 snapshot with Python, you'll end up digging into some horrid JSON queries. Oh, and cost CAN get way out of control if you don't keep on top of thing. It's just too easy to spin up a new xyz and forget to shut it down. But there are LOTS of things you can do to keep cost down.

Far too much.

In the beginning, developers wrote programs and operators changed tapes and emptied the printer when they weren't on the phone to the service engineer. Then along came minicomputers with the implication that you could do away with operators and the programmers could mind the machines and apply the occasional system update: never quite worked in production environments.

Cloud operations are vastly - and, often, gratuitously - more complex. It's no longer enough to know how one vendor does things, but several. And the domain-specific languages that are used for "infrastructure as code" are just glaring examples of the old [1]xkcd truism.

And none of this stuff stays still - look at best practice two years ago and a lot of it has since changed, along with a growing number of deployment environments offering different characteristics and all, of course, distinctly managed. If you were really trying to stay on top of this stuff, what else would you get done?

And security is a real nightmare and because it's completely opaque to the hosting environment it's effectively off by default so it only takes one microservice to fail to validate an access token and you've got a potential incident.

And a lot of outfits think that "devops" once more means it's something that programmers can manage in their spare time.

There aren't that many people in the world who are sufficiently close to the coalface that they're completely au fait with the current status of the tools - and they're probably too busy developing them to do much else.

In short, it's all far too complex for the average business to manage with the staff they have or are likely to be able to recruit or afford. There will be places that need to tinker with the plumbing to get the best result, but for this technology to be usable in the majority of situations, it has to Just Work out of the box.

[1] https://xkcd.com/927/

Isn't this just progress?

150 years ago, your local blacksmith and carpenter (might be the same person) could put together a working vehicle. You can still have that now, if you want. But you'll need a horse, and it'll take you a long time to get to Manchester instead of just jumping in the car and going up the M6.

OTOH, if you want a modern car it's going to take a team of hundreds (or thousands) to design and build it. And it's fucking complex.

But we choose the car (or train or plane) over the horse and cart because it's so much more efficient.

Isn't that the same thing with DevOps and Cloud Native, compared to building a server by hand?

As an aside, there aren't THAT many Infrastructure as Code systems. Pretty much everyone uses Terraform, and you've got AWS CloudFormation, Azure ARM and GCP Deployment Manager. I don't count Puppet/Chef/Ansible as they are really primarily Config Management.

Having said that, my job as a DevOps Engineer (or SRE or Platform Engineer) is SO much harder than it was just 10 years ago, as a humble Systems Administrator. (which was already quite hard at times, but in a different way). I no longer have to worry much about inodes and mapping out filesystems and disk blocks, or fsck, or VxFS drivers but I do have to build CI/CD systems and mangle YAML / JSON in weird esoteric ways.