Tim, I like Varnish's vcl flexibility, but not the debugging aspects. Still, +1, but could you elaborate on how you see:
* Services communicate with each other - via varnish as well or directly? * Do you see routing varnish layer as non-caching, only to forward request to the second tear service-specific varnish instance that will actually perform caching? * Will there be any problems separating services into separate, non mutually trusted clusters? * service management - varnish would only indicate overall health of the service. What about service-specific real time monitored values (if needed), logs, controlling service instances. Any thoughts on generalizing that infrastructure?
Lastly, semi related - my service will also need a node.js lib to access MW api. How should we manage common libs like that?
Thanks! On Feb 6, 2015 4:15 AM, "Tim Starling" tstarling@wikimedia.org wrote:
On 04/02/15 16:59, Marko Obrovac wrote:
For v1, however, we plan to provide only logical separation (to a certain extent) via modules which
can
be dynamically loaded/unloaded from RESTBase. In return, RESTBase will provide them with routing, monitoring, caching and authorisation out of
the
box.
We already have routing, monitoring and caching in Varnish. That seems like a good place to implement further service routing to me.
< https://git.wikimedia.org/blob/operations%2Fpuppet/4a7f5ce62d9cdd1ace20ca6c4...
It's simple to configure, has excellent performance and scalability, and monitoring and a distributed logging system are already implemented.
It doesn't have authorisation, but I thought that was going to be in a separate service from RESTBase anyway.
-- Tim Starling
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l