Thanks so much, yeah its a lot broader than we initially thought it would be, but we love backend programming a lot so its a joy to work on it, (most of the time).
For the security concerns, at a policy level we're currently going through getting SOC II compliance. In the future we will be progressing for fedramp complaince as well, but we haven't started on that.
Regarding read access risks, the client has complete control in their account for giving us exactly what access they want/are able to via IAM. Additionally, right now our application is multi-tennant behind the scenes, however early on Matt and I saw that we will need to offer single tennant solution for increased data privacy, so we've designed the system with that in mind and its not a major lift for us to provide a single tenant and isolated environment within any region which data needs to reside in. It just hasn't come up as a concern for us yet.
As an aside, we had some background working with government agencies where this was a major concern for them and single tenant region localized storage was frequently table stakes for deals.
For GDPR, we don't store or process PII. Which sounds kind of insane saying it out loud but its true. We integrate with end payment providers like Stripe and AWS marketplace, where all we're reporting with is a UUID which is associated in their platform to the end customer's billing info, which we never need to see or touch.
Now it is possible that someone could manually enter client PII into the platform in which case we would need to deal with that, but it has yet to come up. If it did, we have API endpoints which can delete all data pertaining to specific clients by request.
I suspect in the future that this will change (we may start persisting PII), and we will need to have a more cohesive strategy for dealing with right to be forgotten, but in the near term it hasn't come up.
One followup: have you considered handling the actual usage calculation and aggregation? One use case that comes to mind is accepting API request logs from (CloudFlare|CloudFront|Logstash), processing them, and directly deriving billing from those. That moves the entire process outside of a system your customer has to touch (in cases where complex application-layer knowledge isn't needed). One less thing for a potential customer to worry about (and removes one of the reasons to need read access to a database in many cases).
> have you considered handling the actual usage calculation and aggregation?
So for aggregation we definitely do some of that work already, we enable clients to aggregate their raw data with a few different methods, like via running a total, average or count, over any arbitrary time frame.
For us doing the actual calculation of the dimensions at a specific time, we haven't thought about it, but we're always interested in building more so we might be able to prototype something.
Your specific example though is sounds like another way of metrics to be pushed into our platform, this really wouldn't be that big of a problem for us to implement, and we even floated the idea around of us exposing a stream that clients could push data to which we would process.
Given that the logs would be in an open standard format, we could definitely do that and it sounds like a good idea. :) Thanks for the suggestion.
For the security concerns, at a policy level we're currently going through getting SOC II compliance. In the future we will be progressing for fedramp complaince as well, but we haven't started on that.
As an aside, we had some background working with government agencies where this was a major concern for them and single tenant region localized storage was frequently table stakes for deals.For GDPR, we don't store or process PII. Which sounds kind of insane saying it out loud but its true. We integrate with end payment providers like Stripe and AWS marketplace, where all we're reporting with is a UUID which is associated in their platform to the end customer's billing info, which we never need to see or touch.
Now it is possible that someone could manually enter client PII into the platform in which case we would need to deal with that, but it has yet to come up. If it did, we have API endpoints which can delete all data pertaining to specific clients by request.
I suspect in the future that this will change (we may start persisting PII), and we will need to have a more cohesive strategy for dealing with right to be forgotten, but in the near term it hasn't come up.