/
Arch Lunch: 2019-10-31

Arch Lunch: 2019-10-31

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)