continON viene messo in esercizio come un tutt’uno. Ciò che cambia è di chi sia il terreno su cui poggia.
Funziona come un insieme di servizi containerizzati su un cluster Kubernetes, distribuiti tramite una pipeline di rilascio controllata. Questo non cambia da una messa in esercizio all’altra. Cambia invece di chi è il cluster, chi detiene il nome host pubblico e il relativo certificato, e chi ne risponde quando una macchina richiede attenzione. Questa pagina riguarda proprio questa linea di demarcazione.
- Gestito per suo conto
- L’ambiente funziona su un’infrastruttura gestita da noi. Il cluster, il nome host pubblico con il relativo certificato e l’applicazione di ogni release sono a nostro carico.
- Su un’infrastruttura sotto il suo controllo
- Lo stesso carico di lavoro viene messo in esercizio su un cluster di proprietà della sua organizzazione o da essa noleggiato. La licenza attiva il prodotto là dove lei lo colloca; le macchine, il nome host e la loro gestione spettano a lei.
Quattro confini, dall’esterno verso l’interno.
Il perimetro pubblico
Gestito per suo conto Deteniamo noi il nome host e il relativo certificato.
Su un’infrastruttura sotto il suo controllo La sua organizzazione detiene il nome host e il relativo certificato.
Un servizio è raggiungibile dall’esterno solo se gli è stato assegnato esplicitamente un nome host pubblico con un certificato. Tutto ciò che non ne ha ricevuto uno è raggiungibile all’interno dell’ambiente e da nessun’altra parte – è l’impostazione predefinita, non un’opzione che qualcuno si è ricordato di attivare.
Cosa lo attraversaTraffico del browser verso le applicazioni che hanno un nome host. Nient’altro.
L’ambiente
Gestito per suo conto Gestiamo noi il cluster e applichiamo le release.
Su un’infrastruttura sotto il suo controllo Il suo team gestisce il cluster; le release vengono comunque fornite come unità controllata e versionata.
Un cluster che esegue i servizi del prodotto. Le release vi vengono applicate dalla pipeline di distribuzione anziché a mano: i repository delle applicazioni contengono il proprio codice sorgente e nient’altro, e non possono modificare dove o come il prodotto viene messo in esercizio. Su questa separazione poggia il controllo delle modifiche, e vale in entrambe le collocazioni.
Cosa lo attraversaImmagini rilasciate, applicate dalla pipeline. Chiamate in uscita che il prodotto effettua verso i sistemi che lei ha collegato.
Il prodotto
Detenuto daIdentico in entrambi i casi.
Le applicazioni, l’unico server di autorizzazione presso cui ogni applicazione effettua l’accesso, il modello di organizzazione e posizioni, le definizioni dei Builders e il livello dati condiviso. È lo stesso software in entrambe le collocazioni – non esiste un’edizione cloud né un’edizione ridotta da installare in sede.
Cosa lo attraversaNulla di nuovo. Un record che passa da un’applicazione all’altra resta entro questo confine.
I record della sua organizzazione
Detenuto daSuoi in entrambi i casi.
Ogni record è circoscritto all’organizzazione a cui appartiene, e un file di licenza cifrato – convalidato al caricamento, con il nome dell’organizzazione, il tipo di messa in esercizio e una scadenza – decide quali applicazioni esistano per quell’organizzazione.
Cosa lo attraversaSolo ciò che un’identità autenticata è autorizzata a leggere o scrivere, in base al posto che quell’identità occupa.
Spostare l’involucro non sposta nulla di tutto questo.
- Il modello di accesso
- Gruppi di autorizzazioni collegati alle posizioni nell’organigramma, non agli account. Vedere
- La licenza
- Lo stesso file cifrato, convalidato al caricamento, che regola l’accesso agli stessi moduli. Vedere
- I meccanismi di integrazione
- Le stesse query salvate sulle sue origini e lo stesso archivio di credenziali per organizzazione. Vedere
- Il modello organizzativo
- Le stesse unità, posizioni e posti a cui fa capo ogni altra parte del prodotto. Vedere
Ciò che questa pagina non afferma.
- Obiettivi di disponibilità, backup e ripristino vengono concordati per ogni singolo incarico. Questa pagina non indica alcun valore di uptime, e il modello di messa in esercizio non implica di per sé alcun livello di servizio.
- Se il cluster è suo, la sua gestione – capacità, applicazione delle patch all’host, monitoraggio e backup del suo database – resta di competenza della sua organizzazione.
- continON viene fornito come un unico carico di lavoro containerizzato. Non è offerto come servizio gestito sulla piattaforma propria di un provider cloud terzo, e questa pagina non ne presenta alcuno.
Cosa tiene insieme la piattaforma
Porti i suoi vincoli infrastrutturali.
Una sessione di lavoro su dove si troverebbe l’ambiente, chi deterrebbe il nome host, che cosa gestirebbe il suo team e che cosa gestiremmo noi – prima di firmare qualsiasi cosa.