3 ms·

> The entire team is composed of half of one dev. Who is on-call 24/7/365, never takes vacation ever, and is always available to fix the website? It’s weird h

> The entire team is composed of half of one dev. Who is on-call 24/7/365, never takes vacation ever, and is always available to fix the website? It’s weird how much HN hates jobs with on-call requirements, but every time cloud services come up the solutions always involve forcing someone to be permanently on call to save a few hundred dollars per month in hosting costs.

BiteCode_dev 5y ago
Nobody is on call 24H. 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.
- PragmaticPulp 5y ago
  > Nobody is on call 24H. 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.
  - kijin 5y ago
    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.
  - wongarsu 5y ago
    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.
  - judofyr 5y ago
    > 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.
    - PragmaticPulp 5y ago
      > 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.
      - CRConrad 5y ago
        > No, I’m well aware. No, apparently not. > 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".
      - BiteCode_dev 5y ago
        > pay a little extra The whole idea is that it's not a little extra, but 2 orders of magnitude.
  - BiteCode_dev 5y ago
    You keep moving the goal post. 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.
    - PragmaticPulp 5y ago
      > 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.
      - BiteCode_dev 5y ago
  - gunapologist99 5y ago
    > 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 does the cloud solve this?
- bserge 5y ago
mjburgess 5y ago
I think it's bizarre you're giving cloud marketing material to a person, whose in a position to know their own situation, as-if you were describing their situation. Like.. what are you expecting to happen? You'll just gaslight them into thinking they dont know how their business works?
- PragmaticPulp 5y ago
  I’m discussing the linked article, which is what this comment section is for and it’s what the parent commenter was comparing to.
jerf 5y ago
"forcing someone to be permanently on call" The company I work for has a lot of stuff in the cloud. We seem to have quite a few position's worth of people permanently on call. The percentage of "data center"-type on-call situations has perhaps gone down somewhat since moving into the cloud, but it has not gone to zero, and it was never the majority of problems anyhow. It seems like you're sneaking the idea in that if they would just pay a lot more money, the person on call wouldn't have to be on call. I'd like to know what cloud you're using, because it doesn't seem to be any of the ones I know of. If your service is critical to your business or project, you've got someone on some sort of call (maybe not overnight call, which is the really rough bit), period, or you've got a business that can disappear at any second.

BiteCode_dev 5y ago

Nobody is on call 24H. 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.

PragmaticPulp 5y ago
> Nobody is on call 24H. 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.
- kijin 5y ago
  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.
- wongarsu 5y ago
  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.
- judofyr 5y ago
  > 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.
  - PragmaticPulp 5y ago
    > 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.
    - CRConrad 5y ago
      > No, I’m well aware. No, apparently not. > 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".
    - BiteCode_dev 5y ago
      > pay a little extra The whole idea is that it's not a little extra, but 2 orders of magnitude.
- BiteCode_dev 5y ago
  You keep moving the goal post. 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.
  - PragmaticPulp 5y ago
    > 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.
    - BiteCode_dev 5y ago
- gunapologist99 5y ago
  > 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 does the cloud solve this?
bserge 5y ago

mjburgess 5y ago

I think it's bizarre you're giving cloud marketing material to a person, whose in a position to know their own situation, as-if you were describing their situation. Like.. what are you expecting to happen? You'll just gaslight them into thinking they dont know how their business works?

PragmaticPulp 5y ago
I’m discussing the linked article, which is what this comment section is for and it’s what the parent commenter was comparing to.

jerf 5y ago

"forcing someone to be permanently on call" The company I work for has a lot of stuff in the cloud. We seem to have quite a few position's worth of people permanently on call. The percentage of "data center"-type on-call situations has perhaps gone down somewhat since moving into the cloud, but it has not gone to zero, and it was never the majority of problems anyhow. It seems like you're sneaking the idea in that if they would just pay a lot more money, the person on call wouldn't have to be on call. I'd like to know what cloud you're using, because it doesn't seem to be any of the ones I know of. If your service is critical to your business or project, you've got someone on some sort of call (maybe not overnight call, which is the really rough bit), period, or you've got a business that can disappear at any second.