Skip to content

Allow application developers access to information required to audit usage per tenant #2723

@mortenson

Description

@mortenson

The encryption guarantees of Jazz are really great, but not being able to introspect the data users are storing makes application development a little tricky. Specifically, since Jazz Cloud or other hosting providers charge based on usage, but there is no way to audit or limit usage per tenant in an application, you just kind of have to accept that any client can point any frontend at your Jazz instance and do whatever they want with no ("in-Jazz") limitations on kinds of schema or size of data.

I have a two ideas for this, but don't have a feeling that one way is better than another:

Land Authenticated Sync and document/support official ways to restrict usage

If you can enforce certain schema guarantees server-side, I think this becomes more of a documentation issue than anything else. For example, for every stored CoValue you could write to another "statistics" CoValue (ex: {tenantId, sizeBytes, coValueId, coValueType}) that the application developer has access to, and those statistics could be used for introspecting or later limiting usage. I'm not sure if my example is good or feasible, fwiw.

(How you actually block or limit users after they've hit a limit remains unclear to me, however)

Introduce strict sharding/multi-tenancy to Jazz Cloud

You could view this as a load balancing problem, where you could keep Jazz the same but document or support sharding per "tenant". This could probably be done today with user-provided infra on top of Jazz, but I'm kind of curious what it would look like as an explicit feature in Jazz Cloud. (ex: maybe API keys can be viewed more as tenant IDs, and Jazz Cloud developers would come up with a middleware that handles key creation/limit setting per API key?)

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions