/
TAG Meeting 2020-09-11 - Multi-instance Roadmap

TAG Meeting 2020-09-11 - Multi-instance Roadmap

Sep 15, 2020

Participants

  • Rosh D

  • Andrew Rice

  • Jean-Francois G

  • Patrick Yoho, Innovate Edu

  • Vinaya Mayya, Ed-Fi Alliance

  • Stephen Fuqua, Ed-Fi Alliance

  • Lee Morrow, Headspring

  • Eric J

Agenda and Materials

 

Notes

  1. Multi-instance

  1.  

    1. Means connecting to one database server, not multiple database servers

    2. Could mean connecting to a cluster of database services for High Availability, however to applications it appears as one connection string

    3. Multiple ODS could be a better, more direct term as opposed to “Multi-instance”

    4. We should insert pre-cursor slides for single and shared instance modes to be comprehensive

    5. Data segregation is another term to consider in various architectures

  1. Mutli-tenacy

  1.  

    1. Multi-multiple configurations is something that one member uses

    2. Reasons:  cost savings, data  portability too -- we have the ability to just hand over a whole cloud environment/account if a district wants it

    3. Comment:  one infrastructure for version number, doesn't want one infra per version per customer

  2. Who uses what?

    1. Participant 1 – all options based on customer demand/needs

    2. Participant 2 - all options based on customer demand/needs, blue/green environments important for the future

    3. Participant 3 – Option #4 (Multiple single-instance – multiple customers, multiple APIs/DBs) and heading towards #5 (Multiple multiple-instance)

    4. Participant 4 – Option #3 (Multiple single-instance – single customer, multiple APIs/DBs) and heading towards #5 (Multiple multiple-instance)

  3. .NET Core drivers

    1. -removing MS costs, flexibility for the stack

    2.  removing MS costs, flexibility for the stack, performance increases for deployment

    3.  removing MS costs, flexibility for the stack

    4. Everyone would be starting with Docker in proper Linux containers as opposed to Linux servers

  4. Admin API discussion

    1. Keys and secrets / Application / clients

    2. Service restart and provisioning new instances up and down

    3. Comment: being able to deploy to district sites to their premises and admin centrally would be great to have w/ Admin API

    4. Lightweight approaches may be done via scripts until API available

  5. Terminology as reflected in the meeting

    1. Tool

    2. Deployment

    3. ODS

    4. What is meant by an instance?

    5. Environment

    6. Drop "tenancy" – too overloaded and confusing as what is meant

  6. Next Actions

    1. Jason: Update original PowerPoint deck to sync with terminology used on call (replace instance with ODS)

    2. Stephen:  Update diagrams in PowerPoint deck for more components as discussed on call

    3. May be helpful to have email discussion to come to common terms for Ed-Fi implementers

    4. Consider if database-only Admin App would be helpful before Admin API

    5. Consider if lightweight Admin API could be delivered for core functions of key/secret management and restarting API

    6. Scope/design Admin API for product backlog as multi-beneficial to TAG group