Services/AppsInTheCloud

Supporting Apps in Services

The Services team exists to build and support products/services for Mozilla. As part of the consumer launch for Apps, we need to deliver server-side support for storing/sharing some key data for use by Apps clients (web and native). To deliver on this, we need to identify requirements, and options to fulfil those requirements. This is an attempt to define and document those requirements.

Data Types and Use Cases

Application Receipts

Description

• Receipts are used to allow users to use purchased apps.
• Provided at purchase time, required at install (and launch?) for apps
• Generally additive only, minimal (any?) modifications, no deletes
  • Deletes may be supported in a full-on user account deletion.
• Must be recoverable in all situations, even after a password reset.

Dataloss implications

• It is possible to recover/recreate receipts from the market itself, but is likely to be difficult and/or incomplete if a user uses multiple app stores.
• Users will be unable to install purchased apps on additional devices.
• Rich clients could be written to restore data to the server, if no data is present, as there will likely be a local cache.

Downtime implications

• Users will be unable to purchase/obtain new applications
• Users will be unable to install new apps on additional devices

Device States

Description

• Device-specific, locally-stored data with server mirroring.
• Covers install state, enabled state, and any other relevant metadata
• May be written to from other clients (web, native) to allow remote installs
• Must be readable from all clients (web, native)
• Can be recreated by the client if needed

Dataloss implications

• As long as the device still has the data, it can re-create remote state easily.
• If server data and device are both gone, the user will need to re-select from list of purchased apps (Application Receipts)

Downtime implications

• Remote installs/changes will not happen
• Some dashboard features may be inoperable (if there's a "see what's installed where" feature)

Potential Solutions

Option A

High-level description

• Receipts and Device State stored behind new, custom API.
• No encryption at all, heavily reliant on infrasec policy/tools
• Aiming for 99.999%, durable, georedundant. Dataloss is an irrecoverable state.

Risks

• We have none of this deployed right now

Cost / Timeline

• Cost is highest (more 9s, more $$$)
• Timeline is TBD

Option B

High-level description

• Receipts and Device State stored using simple storage API/spec (what we use for Sync)
• Encryption optional via key wrapping
• New infrastructure for the API, with higher durability/uptime targets than core Sync
• 99.9% uptime with backups
• Longer-term option to deploy even better infra/implementations to get closer to true HA.

Risks

• Possible future divergence between storage API reqs for Sync and Apps
  • Almost certainly solvable, but worth discussing concrete concerns

Cost / Timeline

• Incremental to current Sync HW/deployment overhead
• Infrasec may/may not be a problem, depending on how soon BID key wrapping is available

Option C

High-level description

• Receipts are stored in a HA+durable backing store (this is mostly additive and low volume)
  • Launch target looks like replicated MySQL with backups, 99.9%
  • Longer term release looks more like a geodistributed key/value store with much higher durability, geo-distributed synchronous writes
  • Data is not encrypted, but is low value without BID assertions.

• Device States are just another Sync engine.
  • Future use cases (install on remote devices) create the potential for abuse, we can do better
  • Has reconciliation and real-time-ish heuristics already built in
  • Leverages existing infrastructure and code to deliver the feature
  • Availability/durability less of a concern, client can rebuild server state if needed.

Risks

• same as Option A for the Receipts piece.

Cost / Timeline

• Receipts can launch with a deployment of the simple storage API, using existing hardware, and build out/switch over to a better infrastructure once it's up and running. As we're storing very little in truly HA/durable storage, costs will be lower, and more directly tied to Marketplace traffic/success.
• Device States leverage existing infra, minimal marginal cost beyond client implementation, and that should be less than building a full custom network client.