Architettura di riferimento e ambiente di runtime
Ciò che viene realizzato nel cloud del cliente: l'ingresso, il cluster Kubernetes a tre nodi distribuito su diverse zone, il database gestito con il relativo standby, l'archiviazione a oggetti, l'uscita, il vault isolato dalla rete e i parametri di dimensionamento.
Ogni implementazione viene progettata una sola volta rispetto alla stessa architettura di riferimento. Le differenze tra i cloud (prodotti di connettività, gestione delle chiavi, motori di database) diventano quindi scelte di configurazione anziché riprogettazioni.
| Progetto | Costruire | Operare | Innovare |
|---|---|---|---|
| Un unico modello di dati e un unico motore di contabilizzazione per ogni evento finanziario. | Servizi containerizzati su un cluster Kubernetes a tre nodi con bilanciamento del carico. | Registrazioni immutabili e tracciabilità completa fin dalla progettazione. | ASK agisce tramite le API proprietarie di TRANXACT. |
| Progettato per essere multi-entità, multi-valuta e multi-regione. | Un database gestito a scelta del cliente, dimensionato per garantire un'elevata disponibilità. | Live DR in una seconda regione operativa e backup isolati dalla rete di serie. | Una coda di azioni consapevole del ruolo che impara cosa è importante. |
Cosa c'è all'interno di una regione?
| Componente | Che cos'è | Note |
|---|---|---|
| Bilanciatore di carico e WAF | Ingresso HTTPS su erp.<dominio cliente>; TLS 1.2 o superiore; protezione DDoS. | L'unico punto di accesso pubblico. |
| Endpoint privato / bilanciatore di carico interno | Ingresso per traffico privato tramite VPN, connessione privata o peering. | Presente quando si utilizza l'accesso privato. |
| cluster Kubernetes | Almeno tre nodi worker distribuiti nelle zone di disponibilità, con TLS end-to-end. | Gestisce il web e le API, il motore di pubblicazione, l'operatore ASK, i worker e i job. |
| Database gestito | Un server primario con un server di standby HA sincrono in un'altra zona. | Motore e cilindrata sono a discrezione del cliente. |
| Archiviazione degli oggetti | Documenti e allegati, con gestione delle versioni e replicati in tutte le regioni. | I documenti non risiedono nel database. |
| Uscita NAT | Traffico in uscita consentito solo verso una lista di destinazioni autorizzate. | Banche, tasse e fatturazione elettronica, buste paga, email, il motore di intelligenza artificiale. |
| volta con intercapedine d'aria | Un account separato contenente backup immutabili, scrivibili una sola volta. | La produzione può spingere solo verso quello e nient'altro. |
I nodi di lavoro sono distribuiti tra le zone in modo che la perdita di un nodo o di una zona non comprometta la capacità di servire gli utenti. La guida illustra dove viene eseguito ciascun servizio e su quale nodo; la loro assegnazione è gestita dallo scheduler.
Al di fuori del gruppo
- Il motore AI per ASK — disponibile nei livelli premium, balanced o economy, oppure tramite la chiave personale del cliente (BYOK).
- Servizi esterni: banche, tasse e fatturazione elettronica, buste paga, piattaforme di business intelligence e dati, posta elettronica.
- Utenti remoti e mobili, che accedono tramite il provider di identità del cliente.
- La rete aziendale del cliente: utenti d'ufficio, provider di identità, sistemi legacy e di produzione, raggiungibili tramite VPN o collegamento privato quando si utilizza una connettività privata.
La connettività privata è opzionale. Quando tutto l'accesso avviene tramite HTTPS, la VPN/collegamento privato e il bilanciatore di carico interno non vengono creati.
Le manopole di regolazione della taglia
- Dimensione del nodo.
- Numero di nodi: minimo tre.
- Motore del database e dimensioni.
- La regione Live DR.
- Il numero di ambienti.
Tutto il resto costituisce l'architettura di riferimento ed è identico per ogni cliente. Consultare la sezione "Prima del contratto" per i livelli di utilizzo che definiscono i valori iniziali.
Configura, non personalizzare
Lo stesso principio regola ciò che viene eseguito nel cluster. Un requisito che va oltre lo standard viene soddisfatto, in quest'ordine: tramite configurazione (low-code/no-code, aggiornato con la piattaforma); tramite un'integrazione attraverso le API TRANXACT che viene eseguita al di fuori del cluster; e solo successivamente, dopo una revisione di sicurezza e ingegneristica, tramite codice o un agente all'interno del cluster, che, se approvato, viene tollerato e supportato dal cliente. Il codice rifiutato viene eseguito al di fuori del cluster. Il capitolo X del manuale elenca le attività per ciascun risultato.
Tutto ciò che è realizzabile tramite configurazione non deve essere trasformato in codice personalizzato. La configurazione si evolve con ogni nuova versione della piattaforma; il codice personalizzato no.