Arch Lunch: 2019-10-31

Owned by Nimisha Asthagiri (Deactivated)
Last updated: Oct 31, 2019

Action Items

  • Type your task here, using "@" to assign to a user and "//" to select a due date

Topics

  • 4 Working group Ownership, backlogs for working groups - do they own and work on stuff?  Can they?
    • Where do we track issues? Is there a consistent scheme for libraries/services/frontends? Do we need one?
    • Background:
      • Arch-FED team changes
      • Question on FedX working group
    • Spotify Guild model - akin to our working group model
    • DEPR working group - using meeting time as a working session
    • Are working groups the technical stewards at edX?  Or the owning squads?
  • 5 Arch Backend Priorities
    • Arch Lunch voting (out of 14 folks)
    • (5) A Scaling our Microservices architecture (standardization, inter-service communication)
      • standardization/consistency
        • common libraries for authn, authz, 
        • updating authn across services
        • config
        • caching guidelines
      • scaling communication
        • eventing framework
        • async versus not
    • (2) B API practices
      • Up-to-date API Conventions doc
      • API Versioning questions
      • Direction/future of API Gateway
      • Location of business logic
    • (6) C Multi-Environment (Prod, Stage, Sandbox, etc) Testing & Configuration (Data inconsistency)
      • Note: Devops team is working on Kubernetes for multi-environment
        • DevOps is focusing on production, but need to consider other environments (not doing as much right now)
      • Automated tooling to identify discrepancies across environments
    • Should just happen
      • Observability
        • Note: Engagement theme invested time to analyze their SLAs and took action to implement alerts for them
  • 3 Permissioning across non-edxapp IDAs (nothing or superuser)
  • 6 Ownership
    • Current Pain Points
      • Multiple ownership locations: Google Doc, Wiki (S&E + FED), openedx.yml, Codeowners
    • What do you want to see coming out of it
      • Need a reliable way to keep it up-to-date
      • Person discoverability - who do I ask if I'm curious about this
      • Accountability - required upgrades, flaky tests
        • Holding engineering owners (as technical stewards) accountable
      • Resourcing and prioritization across product work & ownership work
      • Zero "Default" owners (individuals who defacto get pulled in when something isn't owned)