User:Clouserw/AMO/Decoupling Services

From MozillaWiki
Jump to: navigation, search
Draft-template-image.png THIS PAGE IS A WORKING DRAFT Pencil-emoji U270F-gray.png
The page may be difficult to navigate, and some information on its subject might be incomplete and/or evolving rapidly.
If you have any questions or ideas, please add them as a new topic on the discussion page.

Proposal to decouple services from AMO

AMO is moving out of our datacenters and onto AWS. Due to its lengthy history there are several moving pieces which make up AMO. Some of those moving pieces are the Services:

  • (VAMO): source1 / URLs, source2 / URLs
  • (SAMO): URLs are here
    • Some minor exceptions aside, SAMO is primarily two URLs: /api/ and /discovery/, both of which are simply rewrites to the same URLs on AMO. It doesn't make sense to write the URLs on AMO and then use SAMO to just display them again. The proposal below will suggest eliminating SAMO completely, aside from supporting legacy redirects to the new API URLs.
  • (blocklist): URLs are here, code is mostly here

Engineering Considerations

  • Engineering Estimate
  • Some (all?) of these services have been highly optimized. We should load test and make sure we don't let performance drop to an unacceptable level.
  • VAMO
    • We will no longer email exceptions. This will use Sentry like everything else.
    • The development team can decide if it's most effective to keep and separate or not.
  • SAMO
    • This domain was originally built to give us some extra flexibility. We could enable longer caching times, leverage the front end cache easily, and take down AMO as needed without affecting our services. Times have changed since then and AMO is robust enough to handle the services so SAMO is unneeded.
    • Most of the services here will run fine on AMO, we just need to reverse the redirect so it goes SAMO->AMO instead of vice versa.
  • Blocklist
    • I don't think this actually has any FKs in the database. This is probably the easiest thing to move out into it's own system. I'll write the estimate assuming we'd do that.
    • I'd suggest we write consumer pages which consume the API Fx uses.

Q & A

  • AMO brings a lot of legacy with it which complicates the versioncheck script. Separate files per OS, Beta add-ons, preliminary versions, weird statuses like STATUS_LITE_AND_NOMINATED, strict compatibility or lack thereof. This is a great opportunity to clean this code up by removing minimally used features.
  • has some special cases in it for update checks with persona IDs. Can we deprecate this functionality?
  • Does Paypal do anything with SAMO? I don't think it does, but need verification.
  • Will SAMO/install.php continue to work without the domain?