> 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 <akosia...@wikimedia.org> _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
