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(a)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/4a7f5ce62d9cdd1ace20ca6c…
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(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l