Support Multi Tenancy

[etschelp]

As this topics tends to pop up in various discussions I started to write down some thoughts on what changes are needed in the BPA to make this happen if we want to.

https://hackmd.io/@AN7LHuEORQSPrOdHz3SrEA/BJ9Fb4vR_

[swcurran]

@amanji and @esune -- please take a look at this, given your experience. Haven't looked yet, but need to be sure that the endorser capabilities are covered. That is likely needed in BPA with/without agency design.

[esune]

I don't have access to the HackMD document, getting a 403 error.

[etschelp]

I updated the URL, its public now

[esune]

I looked at the document, looks good to me. There is no mention of endorsing transactions though: @etschelp let me know if you need an overview of how that works and what type of workflows and other services you would need to setup and orchestrate.

The other thing I added a comment for in the document is that each tenant will require BOTH the agency admin-api-key AND their token to operate. This is not great in my opinion, and needs to be abstracted so that tenants only need to deal with one key. We have added a "proxy" that hands out generated api-keys and binds them to a tenant's token, and builds the right request internally when needed in order to not hand out the main admin key to everyone.

A goo resource to poke at is aries-vcr-issuer-agency as we have implemented all of the above (one interpretation of it, at least).

[frank-bee]

Great that you started with a document, @etschelp
Maybe we need a chapter at the beginning of the document what we want to achieve.
For me it is still not clear. If it is just about resource consumption of a potential BPA SaaS solution, I would phrase also the Issue like this. In this case we really need numbers :
How many BPAs do we need in a SaaS solution?
How much resources ( RAM / CPU) does a BPA really need minimally?
Is the Java overhead of the backend really that big that we need to get rid of our microservice architecture?

Maybe - if at all - it is enough to allow multiple tenants on "one big acapy" ( the database would be anyway hosted in a DBM and not in a single pod like now in the default config of the our chart)?

Don't get me wrong. It is really good to have an overview about potential technical hurdles to switch from micro services to silos.
But asking the question if we need that I find crucial.