5 ms·

It's like they don't understand that (seemingly) forgotten archiectural principle of the internet which says that the "intelligence" goes in the ends: i.e. the

by bsedlm 5y ago

It's like they don't understand that (seemingly) forgotten archiectural principle of the internet which says that the "intelligence" goes in the ends: i.e. the leaves are smart, the nodes are as dumb as pipes. Thus they insist on making the nodes (the servers) smart and the clients (leaves) dumb.

stephc_int13 5y ago
This is true from a technical perspective, and this is probably why the web is still not perfectly sound from an engineering point of view. But from a business perspective, there is huge value in dumb clients (not for the end-user)
razorfen 5y ago
It’s the first I’d heard of this axiom. Can you give an example of that in a real architecture? I think about a central server with multiple terminals on a network. There the node is the beefy boi and the terminals are just I/O devices. Kind of similar to what MightyApp is doing - except with fewer privacy concerns :)
- tsimionescu 5y ago
  But no one uses that architecture anymore. To the extent that you have a terminal on a remote server, you use it to configure the server, from your own thick client.
  - freeopinion 5y ago
    Is it true that chromebooks outsell other laptops?
- dunkelheit 5y ago
  https://en.wikipedia.org/wiki/End-to-end_principle https://en.wikipedia.org/wiki/End-to-end_principle It is not an axiom though, but rather an architectural guideline that comes with its own set of trade-offs and must be applied judiciously.
vidarh 5y ago
There's an ongoing tension here between software getting complex enough to be slow and people wanting to move computation to servers. The problem with that, of course, is that the clients inevitably gets faster, and cheaper, and software gets pushed to the leaves again. We're carrying around what used to be super computers. This is also why I would be very cautious about investing in something that bets on offloading computation from clients: If you time it right, it could be huge for a while, but you're betting against advances in the speed and cost of computation. The same advances you'll rely on to scale and drive down costs. As such it feels to me like they're playing a game of musical chairs.
- stephc_int13 5y ago
  Yes, this is a seemingly never-ending cycle. 1. Software is too heavy, let's push it on the server 2. Dumb client gets faster 3. Servers cost money, let's use the unused CPU cycles on the client 4. Bloatware happens, go back to 1.
- gwright 5y ago
  I think you are leaving out the data story. It is very difficult to push data to the edges, you can easily run into volume or consistency problems. No surprise that this means that there is no single solution. Complexity sometimes makes sense at the edges and sometimes make sense in the core. It just depends. I think we have a lot to learn about building systems that give us the flexibility to move things around as needed. Plan 9 was interesting from that point of view because it gave a way for edge resources and core resources to be composed via 9P at any place in the network.
  - vidarh 5y ago
    I don't buy that data is a technical problem. It's a business problem in as much as holding users data hostage is central to a lot of business plan. All of the data in my Google account, for example, fits on a microsd card. Of course I want backups of it, and so I don't want to actually store it on a single microsd card, but the point is that this doesn't require much logic at the core. You can push processing to the edge while using a storage service. But you can push storage services towards the edge too. For a lot of data we already employ near write-once for the core of the data, which is ideally suited for synchronisation schemes over fully connected centralised storage. Your e-mail, and things like Google Photos are good examples. Consistency is less of a challenge than it might seem. It's a challenge if you're frequently disconnected from the network for extensive periods of time and might access and modify data from multiple disconnected devices in that period (note modify, not augment and create something new, which is easy to accommodate). But supporting that is very different from supporting mostly-local computation.
freeopinion 5y ago
I think the "architectural principle of the internet" is not what you suggest. Years ago, I pushed as much work onto the client as possible to reduce the workload on my servers. Now, people complain if you push too much work onto their phones. They want the server to do the heavy lifting so the app can be more responsive on their low-powered mobile client. "The internet" doesn't define how much weight each end of a connection should bear. It doesn't really even dictate that there are only two ends. Should a webapp have a braindead REST api with a select, insert, update, delete for each table of the underlying db model and have the client make 1000 nested calls to the server to render the simplest thing? Or should the server api be much more sophisticated so that a single api call can provide all the information required for the render? There's no one right answer just because "internet".

by bsedlm 5y ago

stephc_int13 5y ago

This is true from a technical perspective, and this is probably why the web is still not perfectly sound from an engineering point of view. But from a business perspective, there is huge value in dumb clients (not for the end-user)

razorfen 5y ago

It’s the first I’d heard of this axiom. Can you give an example of that in a real architecture? I think about a central server with multiple terminals on a network. There the node is the beefy boi and the terminals are just I/O devices. Kind of similar to what MightyApp is doing - except with fewer privacy concerns :)

tsimionescu 5y ago
But no one uses that architecture anymore. To the extent that you have a terminal on a remote server, you use it to configure the server, from your own thick client.
- freeopinion 5y ago
  Is it true that chromebooks outsell other laptops?
dunkelheit 5y ago
https://en.wikipedia.org/wiki/End-to-end_principle https://en.wikipedia.org/wiki/End-to-end_principle It is not an axiom though, but rather an architectural guideline that comes with its own set of trade-offs and must be applied judiciously.

vidarh 5y ago

There's an ongoing tension here between software getting complex enough to be slow and people wanting to move computation to servers. The problem with that, of course, is that the clients inevitably gets faster, and cheaper, and software gets pushed to the leaves again. We're carrying around what used to be super computers. This is also why I would be very cautious about investing in something that bets on offloading computation from clients: If you time it right, it could be huge for a while, but you're betting against advances in the speed and cost of computation. The same advances you'll rely on to scale and drive down costs. As such it feels to me like they're playing a game of musical chairs.

stephc_int13 5y ago
Yes, this is a seemingly never-ending cycle. 1. Software is too heavy, let's push it on the server 2. Dumb client gets faster 3. Servers cost money, let's use the unused CPU cycles on the client 4. Bloatware happens, go back to 1.
gwright 5y ago
I think you are leaving out the data story. It is very difficult to push data to the edges, you can easily run into volume or consistency problems. No surprise that this means that there is no single solution. Complexity sometimes makes sense at the edges and sometimes make sense in the core. It just depends. I think we have a lot to learn about building systems that give us the flexibility to move things around as needed. Plan 9 was interesting from that point of view because it gave a way for edge resources and core resources to be composed via 9P at any place in the network.
- vidarh 5y ago
  I don't buy that data is a technical problem. It's a business problem in as much as holding users data hostage is central to a lot of business plan. All of the data in my Google account, for example, fits on a microsd card. Of course I want backups of it, and so I don't want to actually store it on a single microsd card, but the point is that this doesn't require much logic at the core. You can push processing to the edge while using a storage service. But you can push storage services towards the edge too. For a lot of data we already employ near write-once for the core of the data, which is ideally suited for synchronisation schemes over fully connected centralised storage. Your e-mail, and things like Google Photos are good examples. Consistency is less of a challenge than it might seem. It's a challenge if you're frequently disconnected from the network for extensive periods of time and might access and modify data from multiple disconnected devices in that period (note modify, not augment and create something new, which is easy to accommodate). But supporting that is very different from supporting mostly-local computation.

freeopinion 5y ago

I think the "architectural principle of the internet" is not what you suggest. Years ago, I pushed as much work onto the client as possible to reduce the workload on my servers. Now, people complain if you push too much work onto their phones. They want the server to do the heavy lifting so the app can be more responsive on their low-powered mobile client. "The internet" doesn't define how much weight each end of a connection should bear. It doesn't really even dictate that there are only two ends. Should a webapp have a braindead REST api with a select, insert, update, delete for each table of the underlying db model and have the client make 1000 nested calls to the server to render the simplest thing? Or should the server api be much more sophisticated so that a single api call can provide all the information required for the render? There's no one right answer just because "internet".