4 ms·
How often does it happen that working containers suddenly fail like that though and it's critical to shave the minutes? I appreciate proxying does give you sl
by fulafel 6y ago
How often does it happen that working containers suddenly fail like that though and it's critical to shave the minutes?
I appreciate proxying does give you slightly better reaction time but this has to be weighed against the costs and outages caused by the complexity in the proxying.
Re you app.example.com scenario: I was not thinking of serving the static assets and frontend code from the individual services, but rather having eg your SPA know about the different endpoints and serving the resources from their own service which would be stable.
Re the memcached angle - the static serving can have caching by whatever mechanism and the API endpoints can also use memcached all they want, with at least as good control granularity as in the proxy case. But if you were thinking about a caching reverse proxy, I think that would be more prone to poisoning the cache with error replies than having the endpoints do their caching individually.
Again, think of all the failure prone machinery you can elide in this scenario.
- cestith 6y agoReasonable rules for something like HAProxy are not at all prone to errors. Ours aren't even applied by hand. It only has to be made right when the automation module is updated, and that gets tested well before it goes to production. Varnish rules are also not that difficult, but I said nothing of caching reverse proxy. I mentioned Memcached specifically in the context of federating traffic counts across multiple non-caching proxies. Whether an application uses Memcached or not is irrelevant to the proxies.