7 ms·

You're going to understand where the cool kids come from once your single dedicated server goes down or can't handle the load any more. As soon as you try to sc

by Mo3 4y ago

You're going to understand where the cool kids come from once your single dedicated server goes down or can't handle the load any more. As soon as you try to scale horizontally or become highly available and start to think about how to do it you end up falling into the same rabbit hole. > If you also use containers you even get quite a bit of flexibility and agility. Yeah... and then the only difference is between a single host and multiple hosts. Guess which one Kubernetes is for? With all due respect and no offense intended, your perspective sounds a lot like "I've never attempted to scale so I can't understand the problems" > can get away with not knowing basic sysadmin stuff I promise you that the knowledge you need for your single dedicated server is also needed for k8s clusters, and I definitely can't imagine anyone who can maintain a k8s cluster but can't maintain a single linux host. It's more like that scaling horizontally comes with exponentially more difficult problems than what you're used to or have heard of. Obviously the billing is an issue but that doesn't negate the whole concept. They should definitely implement better expense controls. A simple hard cap to activate if you want would fix this for good.

nojito 4y ago
Most people don't need to scale and even running 5x redundant servers is cheaper than a comparable cloud solution.
- 300bps 4y ago
  Running Lambda, I get a million calls per month for free. Then it's 20 cents per million calls. Just curious - have you really researched cloud solutions or did you just compare the price of hosting EC2 instances in AWS vs having your own server? Because that's not what cloud is about.
  - nojito 4y ago
    And? I don't think you are aware of how cheap metal is these days. Plus the OP has already decided that free tiers don't work.
    - deleted 4y ago
      [deleted]
  - eropple 4y ago
    So I'm actually in the process of doing Lambda versus persistent costing right now for a new project, where it's heavily load-based and very spiky, but the work on each packet of information is actually very lightweight. The tricky part here in AWS is not Lambda, which is pretty reasonable in general--the pitfalls I'm seeing are around data storage. DynamoDB is stealthily very expensive, either provisioned or on-demand. Right now I'm converging on lambdas for compute and RDS/S3 for storage, but what really makes AWS shine for this use case more than anything else is SQS. SQS is so good and that there isn't a great, easily deployed (sorry, RabbitMQ) option for exactly what it does is a real push towards AWS. (GCP Cloud PubSub is close enough, but I know AWS way better than I do GCP.) If I didn't need this, and I felt confident managing RabbitMQ as a queueing solution, I don't think AWS would be a compelling solution because $60 in Hetzner nodes, in a HA configuration, could do a lot of work. (If this thing works I'll need an on-prem solution anyway, so I'll probably have to build that too--but that's "good problems to have".)
    - Mo3 4y ago
      DynamoDB is not required to use cloud functions. You can either use regular RDS like you said, Aurora or even just your own EC2-based cluster (all of these you can attach to the VPC the functions are attached to as well) and there's a lot of nice developments going on like Cloudflare D1. Totally agree on SQS, knowing PubSub as well I'd say they're pretty much on the same level. All the interconnectedness is where cloud platforms shine
      - eropple 4y ago
        To clarify, I mentioned DynamoDB because it has a unit-costs model rather than an amortized-over-time cost model, and when you can harness that (and then focus on a simplified COGS model) you can do very well.
    - gunapologist99 4y ago
      NATS and NSQ are better than SQS if you can deploy them yourself. ZeroMQ is a great option as well, but it probably will require some major brain changes, since it doesn't fit most people's mental model of what a queuing server looks like.
  - horsawlarway 4y ago
    > Running Lambda, I get a million calls per month for free. Then it's 20 cents per million calls. And you are overpaying by a significant chunk. My raspberry pi - the old cheap one - can handle 10 million requests a day without breaking a sweat. If I push it, I can get up around 90 million requests a day without too much effort (it's only about 1 request/ms) I really don't think most devs understand how fucking cheap hardware that's comparable to these services is. Now - you might be using a host of other valuable features that your cloud provider gives you (things like edge servers near your customers, or truly significant outbound network traffic flows, or a very robust multi-region setup, or disk backing of some sort, etc). But generally speaking - you ARE overpaying for cpu cycles in the cloud. It's not really up for debate.
    - Mo3 4y ago
      Of course you are paying more for AWS than for a damn raspberry pi.
      - horsawlarway 4y ago
        You say this like it's obvious that AWS is better. There are certainly cases where AWS can be better (ease of edge networks and multi-region availability come to mind) But outside of a very small set of cases (most of which are when companies are victims of their own success - which is actually a wonderful problem to have) what's the compelling reason to actually use AWS if "Of course I am paying more" for it? In my opinion, if you can still run your db on a single machine - you don't fucking need the cloud yet. That covers a pretty large chunk of businesses. Most of the "cloud" is convincing business that could self-host their entire stack on a raspberry pi in a basement that they should be spending thousands on cloud compute costs a year. Fuck - the most damning evidence is simply how much fucking money these companies are making from upselling you cpu cycles that they're getting mostly for free. For the 4th quarter of 2021, amazon reported a profit of 5.2 billion on ~18 billion in revenue from AWS.
        deleted 4y ago
        [deleted]
  - deleted 4y ago
    [deleted]
swatcoder 4y ago
I'm not trying to dismiss the value there is in having highly scalable cloud architectures available to the projects that need them, but a huge proportion of projects will never need them. Most projects don't even actually suffer for modest downtime, although you can achieve AWS-comparable downtime even without AWS/Google/Azure-style "cloud" architecture. It can make a huge difference in operating and engineering costs to know which bucket your project fits in. Good architectural foresight can even let you smoothly move from one to other if unexpected growth or a pivot indicate that it's warranted. Engineering is about understanding the scope/scale of problems, not about being dogmatic or getting caught up in problems that don't apply.
digianarchist 4y ago
I was thinking more of when the unpatched Ubuntu 12.04 is exploited via an SSH 0day and the server is used to host a Citibank phishing website.
zamadatix 4y ago
For 99% of projects you're never going to hit the point a single server (or group of servers if you truly need redundancy for some level of uptime) can't handle the load. For the other 1% that end up needing that scale I have a hard time accepting it's actually better to start building for massive scale day 1 instead of day 1000.
- Mo3 4y ago
  This is such a narrow perspective. It’s not always about load, most applications can benefit from some level of redundancy and using AWS etc doesn’t equal a massive scaling operation forced upon you. In fact, the other options would. I'll give you some common examples. You have a script that needs to run, without fail, at a certain time every day. You have an endpoint that is mission-critical and even a second of downtime would cause insane manual workload. You have an endpoint that needs to have as little end-user latency as physically possible. These are all real examples from my work in fintech. The solution to all of them is a few dollars in cloud functions in Lambda and Lambda@Edge. Now imagine having to provision, orchestrate and maintain dozens of dedicated hosts all by yourself, simply for these handful scripts. The expense of employee time alone would make it absolutely idiotic to go that route and if anything this would equal massive scale day - but even worse, because you didn't even plan for it beforehand.
  - tluyben2 4y ago
    I work in fintech (banking and payments) and most of our clients aren’t even allowed to host on aws; they have to go for a local provider because aws doesn’t have a hosting hub in their country. Not sure what part you work in but this has never been a problem in the past 20 years with just servers, switches, load balancers etc. I prefer aws over metal for these kind of setups, but for many other cases I definitely do not; just a dedi or a vps with docker or k8s and/or something like openfaas is enough for almost all startups and beyond. Making it literally impossible to make mistakes like OP. And when needed maybe failover or load balancing.
    - Mo3 4y ago
horsawlarway 4y ago
> With all due respect and no offense intended, your perspective sounds a lot like "I've never attempted to scale so I can't understand the problems" With all due respect, I don't think you've ever actually put together a local cluster. A simple 4 machine k8s cluster sitting literally on dirt in my basement can scale out to the equivalent of thousands of dollars of AWS spend a month. I broke even on the initial purchase outlay for my workloads in less than a year. The problems are almost never scaling the web servers. The problem is scaling the infrastructure that those servers need to be useful. Generally - your DB is the first pain point, your network is the next. If you can run it in a container, that service probably isn't the bottleneck for scaling, it's going to be whatever is providing the persistent disk for that service, and the network between the two. Both of those things happen to also be fairly expensive to scale in the cloud as well.
- Mo3 4y ago
  > With all due respect, I don't think you've ever actually put together a local cluster. I have, and still do. It's neither redundant nor highly available. The power source isn't, the internet connection isn't and it's also located in my basement and not multiple regions. > The problems are almost never scaling the web servers. The problem is scaling the infrastructure that those servers need to be useful. There you go.. > Both of those things happen to also be fairly expensive to scale in the cloud as well. No. [0] [0]: https://i.ibb.co/TKmB9HX/image.png https://i.ibb.co/TKmB9HX/image.png
  - horsawlarway 4y ago
    With regards to your image... so what? Virtual networking equipment is virtual - I too can spin up hundreds of subnets for nothing. My internal transfer costs are also.... drumroll... zero. (ok - technically, at some point I bought a 10gbs switch and 500ft of ethernet cable) Lets talk about what it costs you put data back out onto the net, or into a different region. Then lets compare long term storage costs. Because that shit is only cheap in the "hobbiest" range. Outside of that, outbound data and storage is fucking expensive in the cloud.

by Mo3 4y ago

nojito 4y ago

Most people don't need to scale and even running 5x redundant servers is cheaper than a comparable cloud solution.

300bps 4y ago
Running Lambda, I get a million calls per month for free. Then it's 20 cents per million calls. Just curious - have you really researched cloud solutions or did you just compare the price of hosting EC2 instances in AWS vs having your own server? Because that's not what cloud is about.
- nojito 4y ago
  And? I don't think you are aware of how cheap metal is these days. Plus the OP has already decided that free tiers don't work.
  - deleted 4y ago
    [deleted]
- eropple 4y ago
  So I'm actually in the process of doing Lambda versus persistent costing right now for a new project, where it's heavily load-based and very spiky, but the work on each packet of information is actually very lightweight. The tricky part here in AWS is not Lambda, which is pretty reasonable in general--the pitfalls I'm seeing are around data storage. DynamoDB is stealthily very expensive, either provisioned or on-demand. Right now I'm converging on lambdas for compute and RDS/S3 for storage, but what really makes AWS shine for this use case more than anything else is SQS. SQS is so good and that there isn't a great, easily deployed (sorry, RabbitMQ) option for exactly what it does is a real push towards AWS. (GCP Cloud PubSub is close enough, but I know AWS way better than I do GCP.) If I didn't need this, and I felt confident managing RabbitMQ as a queueing solution, I don't think AWS would be a compelling solution because $60 in Hetzner nodes, in a HA configuration, could do a lot of work. (If this thing works I'll need an on-prem solution anyway, so I'll probably have to build that too--but that's "good problems to have".)
  - Mo3 4y ago
    DynamoDB is not required to use cloud functions. You can either use regular RDS like you said, Aurora or even just your own EC2-based cluster (all of these you can attach to the VPC the functions are attached to as well) and there's a lot of nice developments going on like Cloudflare D1. Totally agree on SQS, knowing PubSub as well I'd say they're pretty much on the same level. All the interconnectedness is where cloud platforms shine
    - eropple 4y ago
      To clarify, I mentioned DynamoDB because it has a unit-costs model rather than an amortized-over-time cost model, and when you can harness that (and then focus on a simplified COGS model) you can do very well.
  - gunapologist99 4y ago
    NATS and NSQ are better than SQS if you can deploy them yourself. ZeroMQ is a great option as well, but it probably will require some major brain changes, since it doesn't fit most people's mental model of what a queuing server looks like.
- horsawlarway 4y ago
  > Running Lambda, I get a million calls per month for free. Then it's 20 cents per million calls. And you are overpaying by a significant chunk. My raspberry pi - the old cheap one - can handle 10 million requests a day without breaking a sweat. If I push it, I can get up around 90 million requests a day without too much effort (it's only about 1 request/ms) I really don't think most devs understand how fucking cheap hardware that's comparable to these services is. Now - you might be using a host of other valuable features that your cloud provider gives you (things like edge servers near your customers, or truly significant outbound network traffic flows, or a very robust multi-region setup, or disk backing of some sort, etc). But generally speaking - you ARE overpaying for cpu cycles in the cloud. It's not really up for debate.
  - Mo3 4y ago
    Of course you are paying more for AWS than for a damn raspberry pi.
    - horsawlarway 4y ago
      You say this like it's obvious that AWS is better. There are certainly cases where AWS can be better (ease of edge networks and multi-region availability come to mind) But outside of a very small set of cases (most of which are when companies are victims of their own success - which is actually a wonderful problem to have) what's the compelling reason to actually use AWS if "Of course I am paying more" for it? In my opinion, if you can still run your db on a single machine - you don't fucking need the cloud yet. That covers a pretty large chunk of businesses. Most of the "cloud" is convincing business that could self-host their entire stack on a raspberry pi in a basement that they should be spending thousands on cloud compute costs a year. Fuck - the most damning evidence is simply how much fucking money these companies are making from upselling you cpu cycles that they're getting mostly for free. For the 4th quarter of 2021, amazon reported a profit of 5.2 billion on ~18 billion in revenue from AWS.
      - deleted 4y ago
        [deleted]
- deleted 4y ago
  [deleted]

swatcoder 4y ago

I'm not trying to dismiss the value there is in having highly scalable cloud architectures available to the projects that need them, but a huge proportion of projects will never need them. Most projects don't even actually suffer for modest downtime, although you can achieve AWS-comparable downtime even without AWS/Google/Azure-style "cloud" architecture. It can make a huge difference in operating and engineering costs to know which bucket your project fits in. Good architectural foresight can even let you smoothly move from one to other if unexpected growth or a pivot indicate that it's warranted. Engineering is about understanding the scope/scale of problems, not about being dogmatic or getting caught up in problems that don't apply.

digianarchist 4y ago

I was thinking more of when the unpatched Ubuntu 12.04 is exploited via an SSH 0day and the server is used to host a Citibank phishing website.

zamadatix 4y ago

For 99% of projects you're never going to hit the point a single server (or group of servers if you truly need redundancy for some level of uptime) can't handle the load. For the other 1% that end up needing that scale I have a hard time accepting it's actually better to start building for massive scale day 1 instead of day 1000.

Mo3 4y ago
This is such a narrow perspective. It’s not always about load, most applications can benefit from some level of redundancy and using AWS etc doesn’t equal a massive scaling operation forced upon you. In fact, the other options would. I'll give you some common examples. You have a script that needs to run, without fail, at a certain time every day. You have an endpoint that is mission-critical and even a second of downtime would cause insane manual workload. You have an endpoint that needs to have as little end-user latency as physically possible. These are all real examples from my work in fintech. The solution to all of them is a few dollars in cloud functions in Lambda and Lambda@Edge. Now imagine having to provision, orchestrate and maintain dozens of dedicated hosts all by yourself, simply for these handful scripts. The expense of employee time alone would make it absolutely idiotic to go that route and if anything this would equal massive scale day - but even worse, because you didn't even plan for it beforehand.
- tluyben2 4y ago
  I work in fintech (banking and payments) and most of our clients aren’t even allowed to host on aws; they have to go for a local provider because aws doesn’t have a hosting hub in their country. Not sure what part you work in but this has never been a problem in the past 20 years with just servers, switches, load balancers etc. I prefer aws over metal for these kind of setups, but for many other cases I definitely do not; just a dedi or a vps with docker or k8s and/or something like openfaas is enough for almost all startups and beyond. Making it literally impossible to make mistakes like OP. And when needed maybe failover or load balancing.
  - Mo3 4y ago

horsawlarway 4y ago

> With all due respect and no offense intended, your perspective sounds a lot like "I've never attempted to scale so I can't understand the problems" With all due respect, I don't think you've ever actually put together a local cluster. A simple 4 machine k8s cluster sitting literally on dirt in my basement can scale out to the equivalent of thousands of dollars of AWS spend a month. I broke even on the initial purchase outlay for my workloads in less than a year. The problems are almost never scaling the web servers. The problem is scaling the infrastructure that those servers need to be useful. Generally - your DB is the first pain point, your network is the next. If you can run it in a container, that service probably isn't the bottleneck for scaling, it's going to be whatever is providing the persistent disk for that service, and the network between the two. Both of those things happen to also be fairly expensive to scale in the cloud as well.

Mo3 4y ago
> With all due respect, I don't think you've ever actually put together a local cluster. I have, and still do. It's neither redundant nor highly available. The power source isn't, the internet connection isn't and it's also located in my basement and not multiple regions. > The problems are almost never scaling the web servers. The problem is scaling the infrastructure that those servers need to be useful. There you go.. > Both of those things happen to also be fairly expensive to scale in the cloud as well. No. [0] [0]: https://i.ibb.co/TKmB9HX/image.png https://i.ibb.co/TKmB9HX/image.png
- horsawlarway 4y ago
  With regards to your image... so what? Virtual networking equipment is virtual - I too can spin up hundreds of subnets for nothing. My internal transfer costs are also.... drumroll... zero. (ok - technically, at some point I bought a 10gbs switch and 500ft of ethernet cable) Lets talk about what it costs you put data back out onto the net, or into a different region. Then lets compare long term storage costs. Because that shit is only cheap in the "hobbiest" range. Outside of that, outbound data and storage is fucking expensive in the cloud.