Un unico design, utilizzato per ogni cliente. Le differenze specifiche del cloud – il prodotto di connettività, il servizio chiave, il motore del database – sono scelte di configurazione, non riprogettazioni. È questo che permette di creare un ambiente partendo dal codice in cinque giorni lavorativi.
Leggere l'immagine dall'alto
- Utenti e integrazioni accedono a un unico nome, erp.<dominio del cliente>, e raggiungono un bilanciatore di carico con un WAF tramite HTTPS, TLS 1.2 o superiore. È l'unico punto di accesso pubblico.
- Almeno tre nodi worker, uno per zona di disponibilità, eseguono l'interfaccia web e API, il motore di pubblicazione, l'operatore ASK, i worker e i job. La perdita di un nodo o di un'intera zona comporta una riduzione della capacità di servizio per gli utenti.
- Il database gestito, con motore e dimensioni a scelta del cliente, dispone di una copia di backup sincrona in un'altra zona. Un guasto in una zona non comporta alcuna perdita di dati: RPO ≈ 0.
- I documenti e gli allegati risiedono in un archivio di oggetti versionato, non nel database.
- Il traffico in uscita passa attraverso il NAT verso una lista di mittenti consentiti: banche, tasse e fatturazione elettronica, buste paga, email, il motore di intelligenza artificiale. Nient'altro.
- I backup vengono inviati in un'unica direzione a un vault isolato dalla rete, in un account separato.
L'endpoint privato e il bilanciatore di carico interno sono rappresentati con una linea tratteggiata perché esistono solo quando si utilizza l'accesso privato. Con l'accesso solo HTTPS non vengono creati.
Cinque manopole, e nient'altro
Dimensione del nodo; numero di nodi, minimo tre; motore e dimensione del database; regione di Live DR; numero di ambienti. Tutto il resto è l'architettura di riferimento.
Configura, integra e solo dopo scrivi il codice.
Un requisito che va oltre lo standard viene soddisfatto tramite configurazione, se possibile, aggiornabile con la piattaforma. In caso contrario, tramite integrazione con le API di TRANXACT in esecuzione al di fuori del cluster. Solo in tal caso, dopo una revisione da parte del team di sicurezza e ingegneristico, si prende in considerazione l'implementazione di codice o di un agente all'interno del cluster; se approvato, viene tollerato e supportato dal cliente, altrimenti viene eseguito esternamente.
Non è previsto l'accesso diretto al database per il cliente: questa opzione è contrassegnata come non disponibile (DB_3.1.09). La creazione di report e l'integrazione avvengono tramite API ed estrazioni TRANXACT, motivo per cui uno strumento di BI viene connesso tramite API o estrazione pianificata, mai tramite accesso al database.
Il team di Business Intelligence di Calderwood richiede un utente di sola lettura per il proprio data warehouse. La risposta è un'estrazione pianificata tramite collegamento privato: la riga BI nel loro elenco di interfacce è "mantieni, estrazione pianificata, collegamento privato".
Provalo Un nodo di lavoro nella zona 2 si guasta durante la chiusura di fine mese di Calderwood. Cosa succede agli utenti e questo incide sul rispetto dell'SLA?
I suoi pod vengono riprogrammati sui nodi nelle zone 1 e 3, dimensionati per gestire il carico; il database non viene influenzato a meno che la zona 2 non contenga il primario, nel qual caso si verifica un failover sullo standby sincrono con RPO ≈ 0. Questo incide sull'SLA solo se la disponibilità mensile non raggiunge l'obiettivo di livello.