Good point. Ideally, what we would need to do is
provide the right tools to
developers to create services, which can then be placed "strategically"
around DCs (in cooperation with Ops, ofc).
Yes. As an organization we should provide good tools that allow
developers to create services. I do fail to understand the
"strategically" around DCs part though.
For v1, however, we plan to
provide only logical separation (to a certain extent) via modules which can
be dynamically loaded/unloaded from RESTBase.
modules ? Care to explain a bit more ? AFAIK RESTBase is a revision
storage service and to be honest I am fighting to understand what
modules you are referring to and the architecture behind those
modules.
In return, RESTBase will
provide them with routing, monitoring, caching and authorisation out of the
box. The good point here is that this 'modularisation' eases the transition
to a more-decomposed orchestration SOA model. Going in that direction,
however, requires some prerequisites to be fulfilled, such as [1].
While revision caching can very well be done by RESTBase (AFAIK, that
is one reason it is being created for), authorization (It's not
revision authorization, but generic authentication/authorization I am
referring to) and monitoring should not be provided by RESTBase to any
service. Especially monitoring. Services (whatever their nature)
should provide discoverable (REST if you like, as I suspect you do)
endpoints that allow monitoring via third party tools and not depend
on an another service for that. My take is that there should be a
swagger manifest that describes a basic monitoring framework and
services should each independently implement it (including RESTBase)
I am also a bit unclear on the routing aspect. Care to point out an up
to date architectural diagram ? I have been told in person that the
one
https://www.npmjs.com/package/restbase is not up to date so I
can't comment on that.
--
Alexandros Kosiaris <akosiaris(a)wikimedia.org>