4 ms·

> why use a CDN when you can use canonical features for deployment (Go embedd, Java jar etc) and serving (HTTP cache headers)? * different work profiles (strea

> why use a CDN when you can use canonical features for deployment (Go embedd, Java jar etc) and serving (HTTP cache headers)? * different work profiles (streaming large amounts of compressed data vs small JSON requests/replies) means that different software is more optimal for each -- an application thread usually is a lot more powerful and does a lot more (and thus is slower in the general case) than an nginx thread * you're using your own compute on your own dime to do what your service provider is probably offering to do for cheaper * bloats the image size -- there is a productivity difference between working with a 150MB image and a 1GB one (debugging, easily diffing changes) Admittedly, these aren't problems for a one man startup or a very low traffic website, but these things do eventually matter as your system grows in size.

dgb23 4y ago
As for the first two: I would assume that you’d put nginx or some other reverse proxy (or a network of proxies) in front of your application server anyway. With the appropriate headers and configuration you would have the same kind of performance characteristics and resource utilization. Am I missing something here? As for the last point: you have 1GB of stuff in either case. And all of that stuff needs to be looked at. The difference is really the deployment: do you prefer to move everything in a single piece or would you rather make individual, fine grained deployments? Either has advantages and disadvantages. I’m not sure how Go let’s you inspect embedded files in a binary though. There might be gotchas. An archive is probably more transparent and more general tools can be used.
- viraptor 4y ago
  At some point the image size does start to matter. Both for local convenience and for the time of deployment. Also serving only the current version's assets will cause failures during a restart. If you have more than one container, there's a chance the page request will hit the new one, but the resource request will hit the old version - without the needed asset. And once you hash your assets, you normally only deploy a couple of extra files, not the whole 1gb. I don't get why people would want to keep them embedded (apart from convenience for a third party who will run it)

dgb23 4y ago

As for the first two: I would assume that you’d put nginx or some other reverse proxy (or a network of proxies) in front of your application server anyway. With the appropriate headers and configuration you would have the same kind of performance characteristics and resource utilization. Am I missing something here? As for the last point: you have 1GB of stuff in either case. And all of that stuff needs to be looked at. The difference is really the deployment: do you prefer to move everything in a single piece or would you rather make individual, fine grained deployments? Either has advantages and disadvantages. I’m not sure how Go let’s you inspect embedded files in a binary though. There might be gotchas. An archive is probably more transparent and more general tools can be used.

viraptor 4y ago
At some point the image size does start to matter. Both for local convenience and for the time of deployment. Also serving only the current version's assets will cause failures during a restart. If you have more than one container, there's a chance the page request will hit the new one, but the resource request will hit the old version - without the needed asset. And once you hash your assets, you normally only deploy a couple of extra files, not the whole 1gb. I don't get why people would want to keep them embedded (apart from convenience for a third party who will run it)