GoTo PartnerCloud Inception

Reason to deploy a  cloud native deployment

• 1 Click deployment of EF-CX tenant

Bigger Picture

External components for-example mongo, minio, redis and postgreSQL are deployed using replication while using the local disk as  the storage mechanism.

Sign-Up

A user signs up form  with 

• username
• Password
• email

and is returned with a customer ID

Process 

The user given a progress bar which will run below given schedulers at the backend.

• region
• namespaced EF-CX deployment 
• instantiation of 
  • tenant ID in KeyCloak
    • with central postgreSQL DB 
      • running in pgpool env with
        • a minimum of 1K connections available
        • PV size of 250 GiB
  • mongo
    • Option-1 
      • 1 single MongoDB cluster ( 1 master, all else slaves )
      • consistency 
        • 1 master always available
        • DR can survive upto 1 node in the whole cluster
      • average size of the customer data
      • retention of the customer's data
      • retention policy
      • management is expensive
      • administration is hectice
      • single point of failure
      • easy to setup with Local-Volume based storage ( no need for a Cloud native Storage ) 
      • Backup and restores are 
        • overall performance 
        • restoration of the cluster may take time.
    • Option-2
      • 1 single instance per Tenant ( Using MongoDB operator )
      • Requires Cloud Enabled Storage ( longhorn, OpenEBS  or Rook )
      • manageability
      • administration ( more sort of automated administration is handy with operator style )
      • backups and restoration is easy
  • redis
    • Option-1
      • Redis Operator based deployment
      • independently covered and managed
      • requires Cloud Native Storage ( Longhorn, OpenEBS or Rook ) ( another option is to use local-disk of the node as always )
      • performance degradations covered because another client may have messed up the their own redis instnace.
      • Backup/recovery-- do we really need to backup redis data PV ??? discuss 
      • Node Failures are covered when 
        • Node where the redis instance was running, fails, the cluster spins up the same instance on another available node with possibilities of 
          • if using local storage – the re-birth will be flash blank
          • if using Cloud native – will emerge from where it crashed.
    • Option -2
      • Deploy as a Redis Cluster ( possibly with Centinel ) 
      • One Central EndPoint for the whole cluster
      • Requires at least 5 nodes ( a minimum of 3 , but recommended 5 )
      • One large database ( with centinel only 1 large database is possible ) but solution is guarentee to run 
      • Node failure survivals  
        • can survive until last node
      • Backup/restore – discuss
    • Option-3
      • Deployed as 1 Master with 1 Slave approach
      • Can be either per tenant or Central
      • Supports multiple database
      • can be namespaced ( local to tenant ) 
      • requies at least 2 nodes
    • Option-4
      • 1 single instance of the redis will be enough ( manually driven )
  • ActiveMQ/Artemis in a central Pool
    • preferred single instance per tenant