6 ms·

The big question is: Do you need that kind of functionality? I agree that very large and complex infrastructures have their place - the problem is just that the

The big question is: Do you need that kind of functionality? I agree that very large and complex infrastructures have their place - the problem is just that they import a ton of complexity and usually cost a lot. People are always suprised when they see a minimal webserver instance on a ten year old debian [0] handling tens of thousands of requests, without issue. It might go down once a decade because the disk failed, but it cost 1200$ to run over that decade. I don't think that's the perfect way, but modern infrastructures love to include a lot of complexity when it's not needed. The problem is that including something is very easy and the cost is only payed once it breaks. Also, hardware is really cheap (you might not think so, but if you compare it to western IT salaries, it is). [0] I know outdated instances with no update strategy are not really a benchmark, but I encourage you to go out and ask people what their container base image upgrade strategy is - the situation really did not change that much.

_vertigo 4y ago
Kind of depends on what you’re building, right? Avoiding building new features in order to limit complexity is probably a good idea in select cases but not in others. Using more complex, purpose-built technology over standard boilerplate is often very cost-efficient, but only if you run at a scale where the additional complexity is worth the savings…
fipar 4y ago
> The big question is: Do you need that kind of functionality? I agree that very large and complex infrastructures have their place - the problem is just that they import a ton of complexity and usually cost a lot. I think that's the key. Most of us aren't Google/Facebook/whatever. Yet lots of people want to mimic those. A simple stack with a relation database on a single machine still goes a long way. In fact, it goes a lot longer way today than it did 20 years ago. It's ok to scale when you need to, but I think premature scaling is the wrong way to go, especially since most things never get to FB/Google/etc size.
- bluepizza 4y ago
  I understand trying to keep complexity low. But I don’t understand how a relational database would be less complex than a simple key value store. Every time this argument pops up, I end up wondering if it’s really about architectural complexity, or if it’s about sticking with the old and known.
  - _vertigo 4y ago
    A lot of relational databases offer a better (or more useful) consistency model than k-v stores, assuming your data isn’t just a bunch of keys and values. Having to worry about consistency can significantly your worsen complexity of your application code.
    - bluepizza 4y ago
      MongoDB is complex, that’s true. But DynamoDB or GCP Bigtable are pretty simple.
      - pjmlp 4y ago
        Simple indeed, they don't even offer anything that matches SQL flexibility.
        bluepizza 4y ago
        Exactly my point. If the argument is to avoid unnecessary complexity, then how come a SQL database is the better choice?
        pjmlp 4y ago
        Because not having proper query language turns simple wishes into complex solutions.
        icod1 4y ago
jcelerier 4y ago
> tens of thousands of requests, a raspberry pi can pretty much serve 100k req. / second. An average dev laptop should be able to handle 1M req. / second without much issues
- Cpoll 4y ago
  > a raspberry pi can pretty much serve 100k req. / second I appreciate the sentiment, but my intuition says that number is too high. What would that look like? I can't picture nginx or haproxy serving up a static 'hello world' response at that volume on a Pi3. And if you do anything with a slow-ish 3rd party API you're probably going to hit the TCP socket limit before you can respond to 100k/s. Legitimately curious about whether my intuition is wrong. I don't have an unused Pi handy to test it myself. Edit: It's possible you're citing https://levelup.gitconnected.com/serving-100k-requests-second-from-a-fanless-raspberry-pi-4-over-ethernet-fdd2c2e05a1e https://levelup.gitconnected.com/serving-100k-requests-secon... ? Pretty interesting article in any case, especially this claim: > This test pitted a native C++ server against a scripted Node.js one, so of course the outcome was given. Well, not really. If I run the same test using µWebSockets.js for Node.js, the numbers are a stable 75k req/sec (for cleartext). That’s still 8.5x that of Node.js with Fastify and just shy of 75% of µWebSockets itself. Edit 2: Doing a bit more research and finding some other benchmarks online, it seems like 100k with µWebSockets is plausible. I recant my skepticism.
- Sebb767 4y ago
  > a raspberry pi can pretty much serve 100k req. / second. An average dev laptop should be able to handle 1M req. / second without much issues Depends on what you do. It's quite easy to hit these numbers with a low number of static pages, but apps that can easily work with static pages usually don't have DevOps people. That's why I went with thousands, to have a reasonable number for an app that actually does some complex processing.
- blizdiddy 4y ago
  That doesnt seem right. https://www.diva-portal.org/smash/get/diva2:1439759/FULLTEXT01.pdf https://www.diva-portal.org/smash/get/diva2:1439759/FULLTEXT... According to this paper, looks like 1000s of requests is more realistic, both for pi and laptop.
nine_k 4y ago
The thing is that sometimes you do. At my current company we're at cusp when we need to address scalability to able to grow as a business, and the business is growing. It took several years to get to this point, but here we are. I prefer simplicity as much as the next guy, but at some moment it becomes simpler overall to use cloud services controlled by k8s than to maintain large amounts Ansible scripts and Jenkins jobs. With that, by the way, comes an inevitable untangling of various parts in the software, and simplification of it. To be fast you need the processing path to be simple.
arinlen 4y ago
> The big question is: Do you need that kind of functionality? What functionality? Automated unit tests to ensure you're not shipping code that is so broken that it even breaks basic invariants? Automated integration tests that ensure you're not shipping code that fails to call other components/services? UI tests to ensure that your latest commit didn't made your prod service unusable for the end user? Performance tests that help you determine if your latest change doesn't suddenly exhaust your computational resources in peak demand?
TheCoelacanth 4y ago
The people paying my salary sure seem to think that we do need it.

_vertigo 4y ago

Kind of depends on what you’re building, right? Avoiding building new features in order to limit complexity is probably a good idea in select cases but not in others. Using more complex, purpose-built technology over standard boilerplate is often very cost-efficient, but only if you run at a scale where the additional complexity is worth the savings…

fipar 4y ago

> The big question is: Do you need that kind of functionality? I agree that very large and complex infrastructures have their place - the problem is just that they import a ton of complexity and usually cost a lot. I think that's the key. Most of us aren't Google/Facebook/whatever. Yet lots of people want to mimic those. A simple stack with a relation database on a single machine still goes a long way. In fact, it goes a lot longer way today than it did 20 years ago. It's ok to scale when you need to, but I think premature scaling is the wrong way to go, especially since most things never get to FB/Google/etc size.

bluepizza 4y ago
I understand trying to keep complexity low. But I don’t understand how a relational database would be less complex than a simple key value store. Every time this argument pops up, I end up wondering if it’s really about architectural complexity, or if it’s about sticking with the old and known.
- _vertigo 4y ago
  A lot of relational databases offer a better (or more useful) consistency model than k-v stores, assuming your data isn’t just a bunch of keys and values. Having to worry about consistency can significantly your worsen complexity of your application code.
  - bluepizza 4y ago
    MongoDB is complex, that’s true. But DynamoDB or GCP Bigtable are pretty simple.
    - pjmlp 4y ago
      Simple indeed, they don't even offer anything that matches SQL flexibility.
      - bluepizza 4y ago
        Exactly my point. If the argument is to avoid unnecessary complexity, then how come a SQL database is the better choice?
        pjmlp 4y ago
        Because not having proper query language turns simple wishes into complex solutions.
        icod1 4y ago

jcelerier 4y ago

> tens of thousands of requests, a raspberry pi can pretty much serve 100k req. / second. An average dev laptop should be able to handle 1M req. / second without much issues

Cpoll 4y ago
> a raspberry pi can pretty much serve 100k req. / second I appreciate the sentiment, but my intuition says that number is too high. What would that look like? I can't picture nginx or haproxy serving up a static 'hello world' response at that volume on a Pi3. And if you do anything with a slow-ish 3rd party API you're probably going to hit the TCP socket limit before you can respond to 100k/s. Legitimately curious about whether my intuition is wrong. I don't have an unused Pi handy to test it myself. Edit: It's possible you're citing https://levelup.gitconnected.com/serving-100k-requests-second-from-a-fanless-raspberry-pi-4-over-ethernet-fdd2c2e05a1e https://levelup.gitconnected.com/serving-100k-requests-secon... ? Pretty interesting article in any case, especially this claim: > This test pitted a native C++ server against a scripted Node.js one, so of course the outcome was given. Well, not really. If I run the same test using µWebSockets.js for Node.js, the numbers are a stable 75k req/sec (for cleartext). That’s still 8.5x that of Node.js with Fastify and just shy of 75% of µWebSockets itself. Edit 2: Doing a bit more research and finding some other benchmarks online, it seems like 100k with µWebSockets is plausible. I recant my skepticism.
Sebb767 4y ago
> a raspberry pi can pretty much serve 100k req. / second. An average dev laptop should be able to handle 1M req. / second without much issues Depends on what you do. It's quite easy to hit these numbers with a low number of static pages, but apps that can easily work with static pages usually don't have DevOps people. That's why I went with thousands, to have a reasonable number for an app that actually does some complex processing.
blizdiddy 4y ago
That doesnt seem right. https://www.diva-portal.org/smash/get/diva2:1439759/FULLTEXT01.pdf https://www.diva-portal.org/smash/get/diva2:1439759/FULLTEXT... According to this paper, looks like 1000s of requests is more realistic, both for pi and laptop.

nine_k 4y ago

The thing is that sometimes you do. At my current company we're at cusp when we need to address scalability to able to grow as a business, and the business is growing. It took several years to get to this point, but here we are. I prefer simplicity as much as the next guy, but at some moment it becomes simpler overall to use cloud services controlled by k8s than to maintain large amounts Ansible scripts and Jenkins jobs. With that, by the way, comes an inevitable untangling of various parts in the software, and simplification of it. To be fast you need the processing path to be simple.

arinlen 4y ago

> The big question is: Do you need that kind of functionality? What functionality? Automated unit tests to ensure you're not shipping code that is so broken that it even breaks basic invariants? Automated integration tests that ensure you're not shipping code that fails to call other components/services? UI tests to ensure that your latest commit didn't made your prod service unusable for the end user? Performance tests that help you determine if your latest change doesn't suddenly exhaust your computational resources in peak demand?

TheCoelacanth 4y ago

The people paying my salary sure seem to think that we do need it.