This one dev is literally on call 365 days a year and can never be away from a computer on vacation. If he leaves, the project has no one.
How is that not a problem? Surely you can see that this isn’t reasonable for anyone who wants to run a business, or any employee who doesn’t want the website to be their life.
> If the system has a problem during the night, the users will wait until the morning.
> It just looses a bit of money and users are grumpy for a day
If you’re running a website where extended outages are no big deal and you don’t care about lost revenue, then it’s not really a valid comparison to the typical business website.
Your situation is unique, not a model by which other companies should follow.
> If you’re running a website where extended outages are no big deal and you don’t care about lost revenue, then it’s not really a valid comparison to the typical business website.
I think you're severely underestimating how many businesses make a significant amount of money from their website, but doesn't actually have full-time developer available. An extended outage would cause significant revenue loss, but it's typically not a problem because outages are surprisingly rare when you (1) have a very stable traffic pattern and (2) you don't spend a lot of time adding features and refactoring. Pretty much every cloud outage we've seen was caused by a human configuration error, not fault machines.
> I think you're severely underestimating how many businesses make a significant amount of money from their website, but doesn't actually have full-time developer available.
No, I’m well aware. But there’s a simple solution to this problem: Don’t try to run and maintain your own servers. Pay a little extra to use cloud hosting and let it be someone else’s problem.
I take issue with these calls to setup and maintain your own custom solutions and servers, while also suggesting that the cost of engineering and maintaining such a custom setup should be ignored.
Running your own servers and not having developers is a recipe for an endless stream of contracting invoices that are going to cost far, far more than just using a hosted cloud solution.
I'd be on board with "pay a little extra to rent dedicated servers", but "move to one of the big-three cloud providers" doesn't sound like a sound financial decision for the case presented.
> But there’s a simple solution to this problem: Don’t try to run and maintain your own servers. Pay a little extra to use cloud hosting and let it be someone else’s problem.
But that's only if it IS a "problem" in the first place. You have defined it as such, although Bitecode themselves said that for them, it simply isn't. (To paraphrase: "If the site is down, then it's down; so what? We'll fix it when we're in the office again.")
Just plain ignoring whether something is "a problem" or not is hardly being "well aware".
> An extended outage would cause significant revenue loss, but it’s typically not a problem
This just seems like a bad decision from a business perspective. You are willing to endure a significant outage that will cost a lot of money but not pay to prevent it? Machines can and will fail.
It seems it's criminal to run a service on the cheap, there must be a terrible human being behing it.
Well no, the dev is not attached 365 days on its computer.
A freelancer is hired part time for the duration of the vaccations. It cost a full dev salary for one month, taking in consideration training time, that's all.
> If you’re running a website where extended outages are no big deal and you don’t care about lost revenue, then it’s not really a valid comparison to the typical business website.
Most services can actually go down once a month, and be a viable business. You are not google or facebook.
In fact, most human service goes down for days: bakeries, lawyers, teachers, plumbers.
The fact your think internet services should be up all time is only in your head. Humans adapt perfectly.
It's not that a big deal. Most of our softwares are not as important as we want to think.
If you really want a 99.99999% up time, you going to increase your service quality by 10%, and your service cost by 1000000%.
The funny thing is, the downtime of ourservice has not being more than github's downtime in the last few years. So honestly the freelacer is mostly hired to have drinks on the house. Because monolythes are very reliable in the first place.
> Your situation is unique, not a model by which other companies should follow.
Every situation is unique, I never, ever stated it was " a model by which other companies should follow". You did.
There is no such thing as "a model by which other companies should follow". You must adapt to the situation and goals. Engineering is about compromises.
My post is simply stating the reality that you can get very far with good old tech.
And a lot of projects don't need the cloud, or high availability. Yet they pay premium for it.
> A freelancer is hired part time for the duration of the vaccations. It cost a full dev salary for one month, taking in consideration training time, that's all.
You pay a full dev salary for one month every time someone wants to take a break?
It’s baffling that anyone can read an article about someone spending $400/month on cloud services and then start proposing things like this as an alternative.
Engineering labor is expensive. Cloud is surprisingly cheap once you factor in engineering costs.
One month part time once a year as an additional cost is way, way cheaper than anything else.
> Cloud is surprisingly cheap once you factor in engineering costs.
No, it's not, since you need somebody qualified to operate it. And such qualificatied employees is very expensive. And you will need them on call anyway, since it will break, just in different way than a bunch of private servers.
I'd argue the cloud would be more expensive, even if hosting were not, because you need a more expensive team to run it.
He never said they don't care about lost revenue. I am willing to guess they considered the lost revenue, weighed it against the cost of having someone on-call 24/7, and considered that the lost revenue was cheaper.
If you look at how frequently sites like Reddit used to have downtime, it doesn't seem to matter too much for consumer products. Having half a day downtime once a year might be completely acceptable.
You can host on AWS and still get hours-long downtime, as has happened recently.
Whether the cost of trying to add another 9 to your uptime is worth the marginal benefit is for each company to decide. Each 9 gets exponentially more expensive. A lot of companies who think otherwise actually can afford (and will, sooner or later, be forced) to be down once in a while.
If the system has a problem during the night, the users will wait until the morning.
The world doesn't stop because a streaming service is down for a few hours. It's not a medical service, or something thousands of businesses rely on.
It just looses a bit of money and users are grumpy for a day because they had to wait until they could access new content.
It's ok.