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.