6 ms·

One of the more ridiculous comments I’ve ever seen on HN. It might be the most ridiculous. I’m guessing you can build AWS in a weekend and it would only cost a

One of the more ridiculous comments I’ve ever seen on HN. It might be the most ridiculous. I’m guessing you can build AWS in a weekend and it would only cost a few thousand or less in hardware costs, and you can host it all on your cable connection.

ocdtrekkie 6y ago
> I’m guessing you can build AWS in a weekend No, but a service on my NUC has better uptime than a service on AWS, and costs less, so why would I want to build AWS?
- judge2020 6y ago
  Because your service neither could handle a million concurrent users tomorrow nor a power outage. Those probably aren't your requirements, but they are for most companies.
  - pjmlp 6y ago
    Only a tiny portion of companies ever reach a million concurrent users tomorrow, nor have plans to reach them, having enough to pay the bills is already quite good. A power outage can be dealt just like in the old days with a UPS unit.
  - ocdtrekkie 6y ago
    I absolutely have a UPS in my basement. Considering how little runs on it, it's pretty cheap to get a long runtime out of it too. A lot of things I see with millions of concurrent users aren't actually monoliths: Sure, Facebook needs to handle that. But most cloud apps would better be run where each tenant/business/team operates an Intel NUC in their basement, instead of the developer using the cloud as a way to force rent-seeking behavior.
    - ithrow 6y ago
      Not having to deal with hardware is nice, and I don't think having datacenter grade internet access in your basement is realistic for most.
      - jonfw 6y ago
        Do you need datacenter grade? Fiber can probably serve a lot of requests per second
        tutfbhuf 6y ago
        Unless your fiber has an outage, then you want redundancy, multiple independent uplinks that is. And if your whole region has a problem, which is more likley to happen than one might think, then you want a multi-region setup e.g. us-west-1 and us-east-2, and then we can start to calculate the numbers of nines, unless your username is ocdtrekkie, he can beat AWS with a single NUC while he is sleeping.
    - tutfbhuf 6y ago
      Many big things started out in a garage, with very simple solutions like your little UPS powered NUC.
      - jon-wood 6y ago
        Including Google. Who have now hit a point where that's no longer sustainable, and developed a set of best practices to ensure reliability beyond what you can expect from a NUC in the basement.
  - KaiserPro 6y ago
    > Because your service neither could handle a million concurrent users tomorrow nor a power outage. SRE here. 92% of all companies can't handle this either.
  - unionpivo 6y ago
    > million concurrent users sure, but 99% of sysadmins/devops/SRE/whatever will never work on anything that has million concurrent users. Most startup will never reach million concurrent users. And if they do, investors will happily shuffle as much money as you need to make your site work at that scale. Hell even million monthly users is a nice milestone that most projects never reach, and that usually translates to couple of thousand concurrent request (peak), that average laptop could handle.
paganel 6y ago
> I’m guessing you can build AWS in a weekend The OP did mention "scale" in his/her comment, the very great majority of projects now being started won't get to AWS's size hence they won't need to use AWS's way of doing things (or Google's, or Facebook's).
- tybit 6y ago
  Funnily enough AWS' way of doing things is quite different to Google's and I think there are pros and cons to both. Google's way is SRE as mentioned here, and I don't have experience to say more there. However, at least in my bubble of the world, AWS's way of "you build it, you run it" is quite popular (and quite effective IMO) for small companies up to any scale.
  - jon-wood 6y ago
    The Google SRE approach isn't that different. You can ship systems that don't follow the SRE playbook, SRE just aren't going to take on-call for it. If you want a different team to be on-call for your application though, there are baseline standards that you have to comply to, and if you breach those standards down the line they're going to hand the pager back to you until you're up to scratch.
  - saranagati 6y ago
    AWS does have something similar to SRE’s though, at least in terms of skill sets. AWS has system development engineers (sysdevs) and systems engineers. When we made the role of SysDev we specifically chose not to call it SRE because we didn’t want people to think of it as a google style SRE. The intent of SysDev is to create and maintain the internal, non-customer facing services. This includes writing code and creating services that maintain the reliability of the service/system. It’s usually related to the infrastructure in some way, whether it’s servers or networking but also expands to understanding how all the different sub systems of the AWS product work together. The core difference here between sysdevs and SREs is that SREs often take over a product from an SWE team once it’s reliable and maintain / improve it. Sysdevs create an internal product and maintain it through the life of it. Of course in AWS not all orgs follow the intent and often implement the role differently.

ocdtrekkie 6y ago

> I’m guessing you can build AWS in a weekend No, but a service on my NUC has better uptime than a service on AWS, and costs less, so why would I want to build AWS?

judge2020 6y ago
Because your service neither could handle a million concurrent users tomorrow nor a power outage. Those probably aren't your requirements, but they are for most companies.
- pjmlp 6y ago
  Only a tiny portion of companies ever reach a million concurrent users tomorrow, nor have plans to reach them, having enough to pay the bills is already quite good. A power outage can be dealt just like in the old days with a UPS unit.
- ocdtrekkie 6y ago
  I absolutely have a UPS in my basement. Considering how little runs on it, it's pretty cheap to get a long runtime out of it too. A lot of things I see with millions of concurrent users aren't actually monoliths: Sure, Facebook needs to handle that. But most cloud apps would better be run where each tenant/business/team operates an Intel NUC in their basement, instead of the developer using the cloud as a way to force rent-seeking behavior.
  - ithrow 6y ago
    Not having to deal with hardware is nice, and I don't think having datacenter grade internet access in your basement is realistic for most.
    - jonfw 6y ago
      Do you need datacenter grade? Fiber can probably serve a lot of requests per second
      - tutfbhuf 6y ago
        Unless your fiber has an outage, then you want redundancy, multiple independent uplinks that is. And if your whole region has a problem, which is more likley to happen than one might think, then you want a multi-region setup e.g. us-west-1 and us-east-2, and then we can start to calculate the numbers of nines, unless your username is ocdtrekkie, he can beat AWS with a single NUC while he is sleeping.
  - tutfbhuf 6y ago
    Many big things started out in a garage, with very simple solutions like your little UPS powered NUC.
    - jon-wood 6y ago
      Including Google. Who have now hit a point where that's no longer sustainable, and developed a set of best practices to ensure reliability beyond what you can expect from a NUC in the basement.
- KaiserPro 6y ago
  > Because your service neither could handle a million concurrent users tomorrow nor a power outage. SRE here. 92% of all companies can't handle this either.
- unionpivo 6y ago
  > million concurrent users sure, but 99% of sysadmins/devops/SRE/whatever will never work on anything that has million concurrent users. Most startup will never reach million concurrent users. And if they do, investors will happily shuffle as much money as you need to make your site work at that scale. Hell even million monthly users is a nice milestone that most projects never reach, and that usually translates to couple of thousand concurrent request (peak), that average laptop could handle.

paganel 6y ago

> I’m guessing you can build AWS in a weekend The OP did mention "scale" in his/her comment, the very great majority of projects now being started won't get to AWS's size hence they won't need to use AWS's way of doing things (or Google's, or Facebook's).

tybit 6y ago
Funnily enough AWS' way of doing things is quite different to Google's and I think there are pros and cons to both. Google's way is SRE as mentioned here, and I don't have experience to say more there. However, at least in my bubble of the world, AWS's way of "you build it, you run it" is quite popular (and quite effective IMO) for small companies up to any scale.
- jon-wood 6y ago
  The Google SRE approach isn't that different. You can ship systems that don't follow the SRE playbook, SRE just aren't going to take on-call for it. If you want a different team to be on-call for your application though, there are baseline standards that you have to comply to, and if you breach those standards down the line they're going to hand the pager back to you until you're up to scratch.
- saranagati 6y ago
  AWS does have something similar to SRE’s though, at least in terms of skill sets. AWS has system development engineers (sysdevs) and systems engineers. When we made the role of SysDev we specifically chose not to call it SRE because we didn’t want people to think of it as a google style SRE. The intent of SysDev is to create and maintain the internal, non-customer facing services. This includes writing code and creating services that maintain the reliability of the service/system. It’s usually related to the infrastructure in some way, whether it’s servers or networking but also expands to understanding how all the different sub systems of the AWS product work together. The core difference here between sysdevs and SREs is that SREs often take over a product from an SWE team once it’s reliable and maintain / improve it. Sysdevs create an internal product and maintain it through the life of it. Of course in AWS not all orgs follow the intent and often implement the role differently.