Considerazioni e pattern di hosting cloud
per ISV (Independent Software Vendor)
Gli ISV (Independent Software Vendors) richiedono servizi di piattaforma e infrastruttura sicuri, scalabili e affidabili per ospitare le applicazioni. Ancor più delle organizzazioni IT (Information Technology) che gestiscono un sistema di back office nel cloud, gli ISV devono fare i conti con operazioni da eseguire 24 ore su 24, 7 giorni alla settimana, distribuzioni in varie aree geografiche, pattern dinamici di traffico dei clienti con esigenze di scalabilità elastica e le sfide alla sicurezza derivanti dall'esposizione delle applicazioni alla rete Internet pubblica.
Un ISV che passa o opera su uno o più provider cloud hyperscale ha a disposizione una serie di scelte e pattern importanti da considerare. È meglio adottare una strategia lift-and-shift in base alla quale l'applicazione viene migrata così com'è o utilizzare una migrazione cloud come un'opportunità per riprogettare in un'impostazione cloud nativa e potenzialmente iniziare a sfruttare i servizi PaaS gestiti di un provider? Un'implementazione cloud può trasformare le impostazioni HA (High Availability) e DR (Disaster Recovery) offrendo la possibilità di sfruttare i domini di errore nel datacenter, i domini di disponibilità nell'area o le interconnessioni tra più aree? Quali strumenti ti offre il provider cloud per proteggere dati, rete interna, host/container di computazione, nonché le interazioni con i clienti? Infine, stai distribuendo l'applicazione come SaaS multi-tenant o in una configurazione single-tenant per ognuno dei tuoi clienti?
Oltre a centinaia di applicazioni che Oracle ha spostato in OCI, il nostro team di Cloud Engineering ha aiutato decine di ISV a pianificare e, successivamente, eseguire la migrazione a OCI. Questo microsito fornirà linee guida e presenterà modelli di hosting distinti per gli ISV.
Esamineremo vari argomenti tenendo conto dei diversi approcci all'adozione di Oracle Cloud.
Questo microsito non è pensato per essere letto in modo lineare. Il diagramma sottostante rappresenta visivamente il flusso che puoi seguire attraverso questo sito in base al tuo profilo. Dopo aver completato questa introduzione, leggi la sezione Il nostro processo e poi, a seconda dell'attuale modello di hosting, scegli la sezione Nato nel cloud o On-Premise/Colocation. Consulta poi la sezione SaaS multi-tenant o SaaS single-tenant a seconda del modello di distribuzione dell'applicazione. Infine, a tutti si consiglia di leggere le sezioni comuni Preoccupazioni trasversali e Riepilogo.
Il nostro processo
- Nato nel cloud
- On-premise/Colocation
- Modello di distribuzione delle applicazioni multi-tenant
- Modello di distribuzione delle applicazioni single-tenant
Molti provider ISV SaaS sono "nati nel cloud", il che suona come "cloud nativi", ma non è sempre così. Nato nel cloud indica, in genere, il desiderio di non essere più associati ai sistemi legacy, ma basarsi sui principi di progettazione delle applicazioni moderne. La progettazione delle applicazioni moderne rappresenta la guida a livello di architettura che incorpora i principi descritti come applicazione a 12 fattori. Non si tratta dello stesso concetto di architettura cloud nativa, ma vi è strettamente correlato. Per coloro che cercano un approfondimento sul cloud nativo da una prospettiva Oracle, è opportuno rivedere i Pattern nativi del cloud, un e-book incentrato sulla progettazione cloud nativa.
Indipendentemente dal fatto che l'applicazione SaaS sia generata seguendo una progettazione delle applicazioni moderne o i principi cloud nativi, ci sono alcuni fattori chiave in comune:
- Intenzione di seguire i principi di sviluppo delle applicazioni moderne
- Intenzione di concentrarsi sull'applicazione e non sull'infrastruttura
- Time-to-value ridotto per le funzioni
- Distribuzioni continue, affidabili e ripetibili
- Separazione dai sistemi visti come "legacy" o sistemi di un singolo fornitore
- Intenzione di costruire, gestire e sostenere un'architettura moderna
- Intenzione di operare in modo flessibile come il cloud computing consente
Gli ISV che hanno iniziato con questi obiettivi in genere hanno un'architettura di servizio separata. I componenti dell'applicazione nel loro carico di lavoro sono distribuibili in modo indipendente, spesso come container, e l'architettura dell'applicazione è costruita per gestire la continuità dell'applicazione in caso di errori dei componenti. Le applicazioni devono non solo gestire la coerenza dei dati, ma anche la disponibilità dell'applicazione.
A seconda dell'architettura di runtime scelta, gli ISV probabilmente avranno integrato monitoraggio e notifiche nel controllo dell'infrastruttura. OCI fornisce servizi a supporto di:
- Eventi Cloud CNCF con il servizio eventi cloud
- CNCF OpenTracing, che fa parte della nostra Cloud Observabilty and Management Platform fornisce una completa interoperabilità con Cloud Functions (serverless) e il servizio Notifiche che, oltre a semplificare la gestione del ciclo di vita per la flotta di server, agevola i task di governance.
La comunicazione tra componenti in genere implementa un pattern asincrono in base al quale i componenti producono e rispondono agli eventi piuttosto che a istruzioni dirette. OCI offre il servizio Streaming, un servizio di streaming serverless compatibile con Kafka, spesso utilizzato per gestire questa comunicazione. Il vantaggio di questo approccio è la protezione dei componenti durante un errore, per cui il raggio di azione viene ridotto mediante l'utilizzo di accodamenti o instradamenti intelligenti.
Un'ulteriore separazione si ottiene separando le applicazioni dall'infrastruttura. L'abilitazione dell'elasticità viene spesso ottenuta utilizzando meccanismi di scalabilità automatica forniti dal provider di servizi cloud (CSP). La scalabilità automatica potrebbe essere a livello di container utilizzando Oracle Kubernetes Engine (OKE), il livello di raggruppamento delle istanze o a livello di gruppo di server.
Con il tempo, alcune applicazioni SaaS iniziano a differenziarsi dall'architettura basata su standard originariamente pianificata, poiché i team iniziano a sfruttare i servizi PaaS nativi forniti da un singolo CSP. Ecco alcuni esempi: uso di un servizio di gestione dati che è esclusivo di un singolo cloud, inclusione di una chiamata API diretta a una piattaforma NoSQL specifica del fornitore senza adeguati layer di astrazione nell'implementazione per la sostituzione futura, uso di IDE che generano codice specifico del fornitore. Per garantire la portabilità del cloud, gli ISV devono fare attenzione a bilanciare la praticità di un servizio di piattaforma con la minaccia di accordi esclusivi con i fornitori che potrebbe verificarsi se il servizio non è indipendente dal fornitore. Molti ISV hanno iniziato un percorso di rimodernizzazione delle applicazioni, con l'obiettivo di avere un vera e propria impronta multicloud. A tale scopo, stanno riesaminando gli stretti punti di contatto con le tecnologie di un singolo fornitore o monouso.
Nel tempo, potrebbe esserci una deviazione nella configurazione dell'infrastruttura. La maggior parte degli ISV adotta un approccio Infrastructure as Code (IaC) e OCI supporta gli strumenti standard del settore, ma fa un passo avanti: OCI Resource Manager, un servizio Terraform gestito, può essere utilizzato per monitorare, tracciare e riparare la deviazione nell'infrastruttura.
Un'implementazione Lift-and-Shift consiste nel migrare nell'infrastruttura Oracle Cloud (OCI) i carichi di lavoro di produzione in esecuzione on-premise o in una struttura di colocation. In alcuni casi, è possibile che si desideri usufruire dei servizi cloud nativi offerti all'interno di OCI per arricchire le applicazioni. Questa attività di spostamento e miglioramento (Move and Improve) è un altro motivo convincente per passare a OCI. Nelle sezioni seguenti verrà descritto il processo Lift-and-Shift e verranno esaminate alcune considerazioni relative alla strategia Move and Improve, laddove necessario.
Questo scenario è ideale per gli ISV che desiderano beneficiare di una spesa in conto capitale ridotta e delegare alcune complessità operative relative a disponibilità, sicurezza e prestazioni a un provider di servizi cloud (CSP) come Oracle. In genere, un ISV implementerà una delle seguenti strategie:
- Lift and Shift: migra le applicazioni on-premise o in colocation in OCI
- Move and Improve: migra le applicazioni on-premise o in colocation in OCI, quindi, le arricchisce sfruttando i servizi cloud nativi o migrando i database verso offerte basate su cloud.
È sempre possibile combinare queste strategie in cui alcuni carichi di lavoro vengono spostati così come sono, mentre altri vengono modificati per sfruttare i servizi gestiti OCI (PaaS).
Lift and Shift
La strategia di migrazione cloud Lift and Shift consiste nello spostare l'applicazione on-premise in OCI in modo che la distribuzione risultante sia molto simile alla distribuzione on-premise. Il primo passo di questo processo consiste nell'identificare carichi di lavoro/applicazioni che consentiranno di esercitare le capacità di OCI e raggiungere obiettivi strategici. Abbiamo molte modalità di hosting tra cui poter scegliere a seconda della residenza dei dati, della latenza e dei requisiti di connettività. Avrai accesso al portfolio completo di OCI, indipendentemente da quale dei seguenti tipi di hosting scegli.
| Tipo di hosting | Descrizione |
|---|---|
| Cloud pubblico | Ampia piattaforma di servizi IaaS, PaaS e SaaS |
| Government Cloud (realm soggetti a restrizioni) | Ampia piattaforma di servizi IaaS, PaaS e SaaS distribuiti in un realm soggetto a restrizioni per gli enti del settore pubblico |
| Area dedicata Cloud@Customer | Ampia piattaforma di servizi IaaS, PaaS e SaaS distribuiti nel data center |
| Infrastruttura Roving Edge | Ampia piattaforma di servizi IaaS, PaaS e SaaS implementati in dispositivi Oracle RED (Oracle Roving Edge Device) rinforzati che offrono servizi di cloud computing e storage ai margini delle reti e in posizioni disconnesse |
| Oracle Cloud VMWare | Sposta i carichi di lavoro basati su VMware nel cloud o estendi il tuo VCenter on-premise per includere il cloud senza riprogettare le applicazioni o riorganizzare le operazioni. |
Durante la progettazione della tua architettura cloud, tieni presente che Oracle supporta una vasta gamma di opzioni di connettività di rete che ti consentiranno di progettare una soluzione di cloud ibrido che abbina le risorse OCI ai componenti in esecuzione all'interno del data center o una soluzione multicloud che interconnette la tua impronta OCI con quella di un altro provider di servizi cloud. Entrambi questi approcci sono molto comuni e possono essere utili per agevolare la migrazione delle dipendenze dei carichi di lavoro per le applicazioni esistenti in esecuzione on-premise o in altri ambienti di fornitori cloud, per soddisfare i requisiti di residenza dei dati, gli SLA IT o altri requisiti.
OCI consente questa comunicazione sulla rete Internet pubblica tramite una VPN IPSec o utilizzando una connettività dedicata (FastConnect). Nella tabella seguente vengono descritte alcune caratteristiche di ognuno di questi approcci:
| Metodo | Latenza | Costo | Affidabilità | Sicurezza |
|---|---|---|---|---|
| Rete Internet pubblica | Variabile | Variabile | Variabile | Meno sicuro |
| VPN IPSec | Variabile | Variabile | Variabile | Il traffico è cifrato, ma il tunnel passa attraverso la rete Internet pubblica |
| OCI FastConnect | Bassa e prevedibile | Prevedibile | Più affidabile | Massima sicurezza: il traffico attraversa una connessione privata |
Inoltre, mentre l'interconnessione da cloud a cloud è possibile tra OCI e qualsiasi altro cloud che utilizza le tecnologie sopra riportate, Oracle ha una partnership con Microsoft Azure per fornire un'interconnettività produttiva a bassa latenza tra i due cloud in molte aree del mondo.
Oracle dispone di numerosi partner specializzati nell'automazione della migrazione a OCI da qualsiasi serie di fonti, inclusi cloud pubblici della concorrenza e ambienti on-premises virtualizzati/non virtualizzati. L'elenco completo dei fornitori di migrazione è disponibile nel nostro Marketplace con esempi rilevanti come Rackware e ZConverter.
Quando si prende in considerazione la migrazione del database Oracle da altri cloud o ambienti on-premise, Oracle offre una serie di strumenti per facilitare la migrazione offline o senza tempi di inattività/live. Questi strumenti diversificati includono: migrazione ZDM (Zero Downtime Migration), migrazione DMS (OCI Database Migration), GoldenGate, DataPump, RMAN e altri. La scelta dello strumento dipende dalle caratteristiche del database di origine e di destinazione e dall'ambiente operativo. Per ulteriori dettagli, consultare la Pagina di arrivo della migrazione cloud del database di OCI.
Move and Improve
La strategia di migrazione al cloud Move and Improve consiste nell'arricchire o sostituire un servizio esistente con un'offerta cloud. Man mano che il tuo team procede attraverso il processo di identificazione dei candidati idonei per la migrazione al cloud, prendere in considerazione le opportunità di arricchire o sostituire i servizi dovrebbe essere una priorità. Ad esempio, puoi migliorare le applicazioni on-premise esistenti eseguendo la migrazione del database on-premise che supporta un'applicazione mission-critical al nostro Database Cloud Service gestito, il nostro primo Autonomous Database autogestito o Exadata Cloud Service che è la piattaforma più veloce per eseguire i database Oracle nel cloud.
Inoltre, l'adozione dell'infrastruttura Oracle Cloud garantisce l'accesso a un intero e vario portfolio di servizi.
- Data Science Cloud che include tecnologie come Machine Learning, AI, Big Data Service
- Software di tecnologie applicate che include tecnologie come Assistenti digitali e Blockchain
- Sviluppo di applicazioni che include tecnologie come Container Engine for Kubernetes, APEX (Low Code), Visual Builder Studio (CI/CD) e Mobile Hub
- Servizi di sicurezza che includono tecnologie come WAF, Identity & Access Management, Cloud Guard e Access Security Broker
- Analytics Cloud
Un modello di distribuzione multi-tenant per i fornitori SaaS utilizza software in esecuzione su un'infrastruttura condivisa per supportare i singoli clienti finali ISV (tenant).
I dati del cliente sono in genere archiviati in una serie di tabelle condivise e tutti i livelli dell'applicazione sono a conoscenza dell'identificativo univoco di un cliente. L'applicazione stessa è progettata per essere compatibile con più client. L'applicazione stessa è in genere anche responsabile della gestione degli abbonamenti utente. Inoltre, l'infrastruttura deve essere classificata in gruppi di server in base al numero di clienti, transazioni e normative che devono essere supportate.
Perché scegliere questo modello
Un modello multi-tenant offre vantaggi all'ISV (Independent Software Vendor). Si ottengono molti vantaggi in termini di efficienza durante l'utilizzo delle economie di scala fornite in un modello multi-tenant. Poiché la composizione del gruppo di server è ben nota, ci sono efficienze acquisite nella gestione e nel monitoraggio dell'infrastruttura. L'avvio di una nuova area di servizio è semplice: basta eseguire il codice di automazione dell'infrastruttura, quindi distribuire l'applicazione. Il set di infrastrutture comune fornisce anche una "soluzione unica" per il monitoraggio.
I clienti hosted in computazione, storage e database comuni generano una strategia di distribuzione delle applicazioni più semplice. Gli ISV che utilizzano questo modello, in genere, avranno un'unica codebase che produce una distribuzione più facile degli aggiornamenti in tutta la base di clienti. Molti ISV che utilizzano questo modello consentono ai clienti di eseguire l'opt-in delle nuove funzioni con l'utilizzo dei flag delle funzioni.
Naturalmente, tutti questi benefit possono anche comportare degli svantaggi. Poiché il supporto a clienti con requisiti specifici di residenza dei dati implica una strategia di distribuzione regionale, potrebbero verificarsi scenari in cui i requisiti aziendali dei clienti impediscano di ospitarli negli stessi server di un'azienda concorrente. A seconda dell'architettura dell'applicazione, i client possono essere esposti a uno scenario di tipo "noisy neighbor". Quando un gruppo di server si satura, l'ISV deve decidere se eseguire la migrazione del cliente a un gruppo di server più recente e meno utilizzato o espandere la capacità del gruppo esistente.
Una delle conseguenze indesiderate del supporto corretto del modello SaaS multi-tenant è la necessità che l'architettura dell'applicazione sia ben pensata e pianificata a un livello superiore rispetto a un'architettura single-tenant. Controlli dell'accesso adeguati e modelli di segregazione dei dati devono essere progettati nel framework dell'applicazione fin dall'inizio e gli ISV devono assicurarsi di avere le competenze ingegneristiche interne per realizzare tutto questo.
Oracle può aiutarti a colmare il divario coinvolgendo i nostri architetti cloud per consigli su come modernizzare la tua applicazione e ottimizzarla per il successo del cloud. I nostri architetti collaborano con altri ISV in ogni ambito di attività e possono contribuire alla tua trasformazione cloud con l'esperienza nella gestione di problemi simili e best practice.
Isolamento del gruppo di server
Un costrutto chiave del modello multi-tenant è un ambiente condiviso per i tenant hosted. In qualità di ISV, devi assicurarti che l'applicazione SaaS sia stata progettata per separare e proteggere adeguatamente i dati dei clienti durante il runtime. Devi anche essere in grado di gestire, monitorare e preservare adeguatamente gli eventi che si verificano nei vari gruppi di server che ospitano la tua applicazione.
È possibile che siano previsti requisiti specifici per tenere i clienti di aree specifiche lontani dai clienti di altre aree (o aree secondarie). Questo tipo di segregazione può essere ottenuto distribuendo i carichi di lavoro nella combinazione di aree e compartimenti OCI. Un esempio al riguardo potrebbe essere un fornitore SaaS negli Stati Uniti che vende servizi rivolti sia al mercato sanitario che a quello manifatturiero generale. Il venditore potrebbe usare costrutti regionali e a livello di compartimento per separare tali carichi di lavoro e fornire capacità differenziate (ad esempio, conformità HIPPA/HITRUST per i carichi di lavoro del settore sanitario).
Un'evoluzione naturale per gli ISV che hanno iniziato con un modello multi-tenant è sviluppare l'offerta per garantire un migliore isolamento dei dati dei clienti. In genere, questa evoluzione avviene prima a livello di dati e il database Oracle supporta un modello multi-tenant che consente di incorporare pluggable database indipendenti in un singolo container database.
Un modello di distribuzione single-tenant utilizza software in esecuzione in un'infrastruttura dedicata per supportare i singoli clienti finali ISV. A differenza di un modello multi-tenant in cui più clienti condividono gli stessi cicli di computazione e uniscono i dati all'interno di tabelle di database comuni, un modello single-tenant si basa su VM di computazione distinte, database distinti e infrastruttura di supporto distinta (load balancer, code di messaggi e così via) per ogni cliente.
Perché scegliere questo modello
Un modello single-tenant offre molti vantaggi all'ISV (Independent Software Vendor). Ogni cliente/tenant hosted in computazione, storage e database separati rappresenta un caso più chiaro per la separazione dei problemi sia dal punto di vista della sicurezza che delle prestazioni: il cliente "A" non può influenzare il cliente "B" né attraverso azioni dannose né utilizzando inavvertitamente più risorse rispetto alla quota corretta. Inoltre, il raggio di azione per un guasto catastrofico è più piccolo; il guasto di un singolo componente (ad esempio, database o coda di messaggi) potrebbe avere impatto su un singolo cliente anziché sull'intera applicazione SaaS. Ogni tenant ha il proprio ambiente distinto personalizzato con funzioni e patch specifiche che creano un modello di distribuzione altamente incentrato sul cliente.
Naturalmente, tutti questi benefit possono anche comportare degli svantaggi. Ogni benefit derivato, ad esempio, dalla fornitura di ambienti incentrati sul cliente può essere compensato dall'onere aggiuntivo della gestione della configurazione e dall'aumento delle attività di monitoraggio e manutenzione. Molti altri benefit di questo approccio si concretizzano in un modello multi-tenant, sebbene richiedano progettazione e implementazione più rigorose dell'applicazione SaaS dell'ISV.
Alla fine, a un ISV non resta altro che decidere se investire o meno in un ambiente multi-tenant abilitando la propria applicazione SaaS. Questa scelta dipende in gran parte dall'avere o meno le competenze di ingegneria del software in-house per farlo. In caso contrario, può scegliere di affidarsi alle capacità di compartimentazione intrinseche fornite dalla piattaforma software e/o dal provider di cloud hyperscale. Ogni ISV deve operare questa scelta in base alla propria situazione specifica.
Oracle può aiutarti a prendere queste decisioni coinvolgendo i nostri architetti cloud per consigli su come modernizzare la tua applicazione e ottimizzarla per il successo del cloud. I nostri architetti collaborano con altri ISV in ogni ambito di attività e possono contribuire alla tua trasformazione cloud con l'esperienza nella gestione di problemi simili e best practice.
Isolamento del tenant
Un costrutto chiave del modello single-tenant è un ambiente isolato per ogni tenant. Un ISV desidera fornire risorse dedicate a livello di computazione, rete, storage, messaggistica e database per ogni cliente. Questa operazione deve essere eseguita in modo che tali risorse siano separate l'una dall'altra sia dal punto di vista del runtime che da quello della gestione.
OCI fornisce una funzione esclusiva chiamata compartimenti che garantisce una solida separazione logica tra qualsiasi risorsa OCI. È possibile posizionare un intero ambiente del cliente, inclusi rete, computazione e così via, all'interno di un compartimento e scrivere policy OCI che controllano l'accesso a queste risorse. Attraverso l'utilizzo di queste due funzioni principali di OCI, è possibile separare efficacemente il cliente "A" dal cliente "B" e impedire la contaminazione incrociata di risorse, gestione o informazioni. I compartimenti sono gerarchici, quindi hai la possibilità di annidare i compartimenti e puoi modellare impostazioni complesse dei clienti utilizzando questo approccio; ad esempio, immagina un cliente realistico con più divisioni che desidera una determinata segregazione tra le business unit pur continuando a mantenere alcune risorse aziendali comuni.
Sebbene il modello di compartimento fornisca le garanzie più solide per la segregazione, esistono alcuni approcci intermedi che possono essere utilizzati a determinati livelli dell'applicazione per migliorare l'utilizzo delle risorse pur facendo affidamento su un metodo non personalizzato per la separazione dei tenant. Ad esempio, invece di creare un sistema di database separato per ogni tenant, puoi sfruttare le capacità multi-tenant del database Oracle per implementare un singolo container database con più schemi collegabili. Questo approccio riduce il sovraccarico di più cluster di database e, al contempo, consente al database di applicare la separazione anziché forzare una riscrittura dello schema dell'applicazione. Oracle Database-as-a-Service virtual machine e Bare Metal supporta la modalità multitenancy pronta all'uso come Autonomous Dedicated Database che può essere utilizzato per i carichi di lavoro più impegnativi.
L'uso di questo approccio intermedio non è supportato solo a livello dati. Se la tua applicazione è gestita in container, puoi sfruttare Container Engine for Kubernetes (OKE) di Oracle per distribuire più container cliente in un'unica infrastruttura. Per gestire la separazione dei tenant, utilizza quindi i tipi di dati primitivi Kubernetes nativi come gli spazi di nomi, il controllo dell'accesso basato su ruoli (RBAC), i segreti e le quote di risorse. Proprio come con il database, invece di riscrivere l'applicazione per renderla riconoscibile dal tenant, è sufficiente sfruttare le capacità dei servizi cloud sottostanti.
Scopri perché gli ISV scelgono Oracle Cloud
Gli ISV garantiscono maggior valore ai propri clienti con l'ampia gamma di servizi e supporto di OCI.
Preoccupazioni trasversali
Forse sei un ISV "Nato nel cloud" che sta creando un'infrastruttura SaaS single-tenant sfruttando le capacità innate del tuo ambiente iperscalabile. Forse hai iniziato on-premises e stai migrando la tua applicazione SaaS multi-tenant perché risieda esclusivamente nel cloud. O forse la tua attività è una permutazione di questi approcci. Indipendentemente dal percorso seguito, ogni ISV che opera nel cloud deve occuparsi di problemi trasversali importanti come sicurezza, osservabilità, continuità aziendale e automazione. Nelle sezioni seguenti, esaminiamo qual è la posizione di Oracle per affrontare queste sfide funzionali e differenziarsi dalla concorrenza.
Sicurezza, governance e conformità
L'approccio di Oracle prevede che la sicurezza sia sempre "attiva" per impostazione predefinita, nonché semplice e prescrittiva. Inoltre, riteniamo che i clienti non debbano scegliere tra costi e sicurezza e sforzarsi di fornire tutti i servizi correlati alla sicurezza gratuitamente o a basso costo con partner che forniscono alternative attraverso il nostro marketplace. La nostra convinzione è che i clienti non subiscano violazioni perché non esistono strumenti per prevenire le vulnerabilità, ma perché tali strumenti sono troppo costosi o troppo difficili da utilizzare per la maggior parte delle organizzazioni.
Oracle ritiene che la sicurezza sia una responsabilità condivisa tra il provider cloud e l'ISV. Forniamo alcune capacità di base, come la virtualizzazione di rete isolata e l'hardware root-of-trust, e le incrementiamo con strumenti e servizi che l'ISV può utilizzare per personalizzare la postura della sicurezza. Gli ISV interessati a ottenere una panoramica delle nostre offerte di sicurezza dovrebbero iniziare esaminando la nostra pagina di arrivo della sicurezza e l'architettura della sicurezza cloud.
La sicurezza di base inizia con la nostra implementazione consolidata di identity & access management (IAM) che unifica i controlli dell'accesso basati sui ruoli con un framework di policy intuitivo. Questa capacità copre un'ampia gamma di argomenti, tra cui utenti, gruppi, federazione di identità e autorizzazione del principal di istanze/risorse. Sebbene non sia coperto da IAM, un altro concetto di sicurezza di base riguarda il networking definito dall'utente attraverso l'uso di regole, gruppi ed elenchi di sicurezza di rete.
Quando inizi a sviluppare un'architettura tecnica sicura nell'infrastruttura Oracle Cloud (OCI), un buon punto di partenza è il Center for Internet Security (CIS), un'organizzazione indipendente dal fornitore che cataloga le best practice di sicurezza. CIS ha sviluppato un benchmark sicuro per le applicazioni OCI e Oracle ha sviluppato un'automazione che consente agli ISV di implementare le raccomandazioni CIS attraverso Terraform.
OCI fornisce una serie di altri servizi di sicurezza fondamentali che includono:
- Gestione delle chiavi di cifratura e dei segreti
- Scansione di host, container e vulnerabilità di rete
- Gestione delle API & funzionalità di sicurezza come la protezione DDoS, il controllo dell'accesso API e l'integrazione dell'identità
- Capacità Web Application Firewall (WAF) che supportano l'intelligence sulle minacce, policy di conformità della sicurezza e gestione dei bot adattivi
- Servizio bastion che consente ai clienti di fornire un accesso ristretto e limitato nel tempo alle risorse private
- Servizio di certificati che consente storage e gestione dei certificati PKCS (Public Key Cryptography).
Passando ad altri aspetti dello stack, una caratteristica unica di OCI sono le Zone di massima sicurezza che impostano e applicano automaticamente le policy di sicurezza in OCI. Ciò consente di applicare la sicurezza dichiarativa utilizzando best practice di sicurezza e fornisce un approccio proattivo piuttosto che reattivo alla sicurezza per le risorse più strategiche.
Infine, nessuna storia sulla sicurezza è completa senza la gestione della postura della sicurezza fornita da Cloud Guard per tutto l'ambiente OCI e da Data Safe per i carichi di lavoro del database. Entrambi i servizi sono forniti gratuitamente ai clienti OCI e garantiscono che le risorse configurate in modo errato e le attività non sicure vengano rapidamente rilevate e risolte in modo automatizzato senza recipe di sicurezza pronte all'uso o inviando dati ai sistemi SIEM/SOC.
Osservabilità
Tutte le organizzazioni richiedono la capacità di raccogliere approfondimenti sulle prestazioni del proprio patrimonio cloud allo scopo di supportare le operazioni e la pianificazione IT futura. Gli ISV, in particolare, hanno bisogno di capacità più avanzate poiché in genere eseguono applicazioni personalizzate che spesso richiedono una strumentazione più approfondita per le prestazioni delle applicazioni. Inoltre, gli ISV possono eseguire i propri carichi di lavoro su scala cloud con una base di consumer esterni 24 ore su 24, 7 giorni su 7, che richiede livelli di tempo di attività più elevati rispetto a un tipico sistema di back office.
A livello di base, OCI fornisce il nostro servizio di Monitoraggio che consente approfondimenti in tempo reale sulle prestazioni dei carichi di lavoro in OCI e offre metriche pronte all'uso relative a stato e prestazioni. Gli utenti possono configurare allarmi per rilevare e rispondere alle anomalie. Questo servizio è abbinato al nostro servizio Logging di base che rende visibili i log OCI oltre ai log generati dai tuoi carichi di lavoro. Eventuali condizioni o problemi identificati attraverso uno dei suddetti servizi possono essere gestiti dal nostro servizio Notifiche che fornisce un sistema di pubblicazione-sottoscrizione ad alta disponibilità e bassa latenza che invia avvisi a funzioni serverless (per la correzione automatica), posta elettronica o partner di consegna di messaggi come SMS, Slack e PagerDuty.
Passando ad altri aspetti dello stack, Oracle fornisce una serie di servizi basati su machine learning (ML) che forniscono analitica più approfondita nelle aree di log, prestazioni delle applicazioni, prestazioni del database e operazioni. Logging Analytics consente di monitorare, aggregare, indicizzare e analizzare tutti i dati di log e utilizzare ML per rilevare cluster di problemi e anomalie in modo visivo. Application Performance Monitoring è un servizio conforme agli standard (OpenTracing & OpenMetrics) che consente il monitoraggio sintetico, il tracing distribuito e l'analisi dell'esecuzione delle transazioni di applicazioni personalizzate, incluso il supporto nativo per la telemetria dei microservizi derivati da ambienti Kubernetes/docker offerti da molti ISV. Database Management fornisce capacità di monitoraggio per le flotte del database Oracle e Ops Insights che consente agli amministratori di scoprire problemi di prestazioni, prevedere il consumo e pianificare la capacità utilizzando l'analitica ML. Le organizzazioni possono utilizzare queste capacità per prendere decisioni basate sui dati e ottimizzare l'uso delle risorse, evitare in modo proattivo le interruzioni e migliorare le prestazioni.
Tutte queste capacità di osservabilità sono fornite come servizi integrati in OCI e vantano generosi "livelli gratuiti" che consentono all'ISV di utilizzare i servizi in scenari limitati e poi passare a un maggiore utilizzo in base ai successi iniziali.
Continuità aziendale
I requisiti di continuità aziendale di un ISV, spesso, possono essere più rigorosi di quelli di un'organizzazione ISV tradizionale. Mentre i tempi di inattività per un sistema di back office tradizionale come un sistema di gestione del capitale umano (HCM) o di pianificazione delle risorse aziendali (ERP) possono essere problematici, la maggior parte degli ISV non può tollerare interruzioni anche temporanee dei propri sistemi rivolti ai clienti che sono la linfa vitale della loro attività. A tale scopo, concetti come High Availability (HA) e disaster recovery (DR) sono estremamente importanti e gli ISV devono sfruttare al massimo le capacità fornite da OCI in queste aree.
High Availability
Un'area OCI è un'area geografica localizzata composta da uno o più domini di disponibilità, ciascuno composto da tre domini di errore. La funzione High availability è garantita da una ridondanza dei domini di errore all'interno dei domini di disponibilità.
Un dominio di disponibilità è uno o più data center situati all'interno di un'area. I domini di disponibilità sono isolati l'uno dall'altro, tolleranti agli errori ed è improbabile che si guastino contemporaneamente. Poiché i domini di disponibilità non condividono l'infrastruttura fisica, ad esempio alimentazione o raffreddamento, o la rete del dominio di disponibilità interna, è improbabile che un errore su un dominio di disponibilità influisca sulla disponibilità degli altri.
Un dominio di errore è un raggruppamento di hardware e infrastruttura all'interno di un dominio di disponibilità. Ogni dominio di disponibilità contiene tre domini di errore. I domini di errore ti consentono di distribuire le istanze in modo che non si trovino sullo stesso hardware fisico all'interno di un singolo dominio di disponibilità. Di conseguenza, un errore hardware imprevisto o una manutenzione dell'hardware di computazione che interessa un dominio di errore non influisce sulle istanze in altri domini di errore.
Tutti i domini di disponibilità in un'area sono connessi tra loro da una rete a bassa latenza e larghezza di banda elevata. Questa interconnessione prevedibile e cifrata tra domini di disponibilità fornisce i componenti di base sia per entrambe le funzioni high availability e disaster recovery.
Puoi progettare soluzioni in più aree, più domini di disponibilità o più domini di errore, a seconda della classe di errori da cui vuoi proteggerti.
OCI offre anche molte capacità e opzioni che puoi adottare per proteggere le tue risorse di rete, i sistemi di storage e le risorse di database da errori localizzati. Un ottimo punto di partenza è leggere il Playbook della soluzione High Availability di OCI Architecture Center nella sua interezza per scegliere il modello operativo appropriato.
Disaster recovery
Con il termine "disaster" si intende qualsiasi evento che mette a rischio le applicazioni: dalle interruzioni di rete ai guasti delle apparecchiature fino alle catastrofi naturali. Un piano di disaster recovery (DR) ben organizzato consente un rapido recupero da situazioni catastrofiche e di continuare a offrire servizi agli utenti. Le capacità DR di OCI si basano sulle ampie funzionalità HA discusse nella sezione precedente.
Quando si esamina la propria strategia DR, è necessario considerare innanzitutto l'obiettivo del tempo di ripristino (RTO) e l'obiettivo del punto di ripristino (RPO). L'obiettivo RTO è il tempo previsto entro il quale una determinata applicazione deve essere ripristinata dopo che si è verificata un'emergenza. In genere, più le applicazioni sono strategiche, minore è l'RTO. L'RPO è il periodo successivo al verificarsi di una calamità per il quale l'applicazione può tollerare la perdita di dati prima che l'evento avverso inizi ad avere ripercussioni sull'azienda.
Successivamente, è necessario determinare il tipo di scenario di emergenza che si desidera adottare. Stai cercando di proteggerti da errori delle applicazioni, errori della rete, guasti del data center, interruzioni regionali o da tutti questi eventi? La risposta a questa domanda, combinata con i valori RTO/RPO, guiderà la tua strategia DR.
OCI fornisce indicazioni per la creazione di architetture tolleranti alle calamità a livello di computazione, rete, storage, applicazione e database. Puoi utilizzare questi strumenti per creare un'architettura attiva-attiva in cui le tue applicazioni funzionano contemporaneamente in due aree e un errore nell'area "a" può essere gestito dall'area "b", uno scenario di backup a caldo in cui viene avviata un'area secondaria pronta per sostenere il traffico in caso di guasto dell'area primaria, uno scenario di backup a freddo in cui potrebbe essere necessaria una mescolanza di passi manuali e/o automatizzati per ripristinare le operazioni aziendali o una combinazione ibrida dei due.
Un ottimo punto di partenza è leggere il Playbook della soluzione disaster recovery di OCI Architecture Center nella sua interezza per scegliere il modello operativo appropriato.
Budget e quote
In qualità di ISV con un'applicazione SaaS in esecuzione che sfrutta i compartimenti OCI per l'isolamento, potresti prendere in considerazione alcuni tipi di dati primitivi correlati per aiutare te e i tuoi clienti a gestire meglio le risorse. Ogni tenancy OCI viene in genere preconfigurata con un determinato limite annuo di capitale e, sebbene le eccedenze non comportino alcuna penalità, la maggior parte degli ISV preferisce mantenere uno stretto controllo sull'utilizzo delle risorse.
Gli ISV dovrebbero iniziare analizzando le quote di compartimenti come strumento per suddividere le risorse a livello di tenancy tra i vari compartimenti. Utilizzando questo tipo di dati primitivo, risorse comuni come CPU e blocchi di storage o risorse più specializzate come GPU ed Exadata possono essere allocate tra i compartimenti per assicurarsi che nessun tenant ottenga un'allocazione di risorse fuori misura e che determinate risorse specializzate siano allocate nei posti giusti.
Le quote operano sulle risorse cloud. Quando si controllano le allocazioni di spesa, gli ISV dovrebbero dare un'occhiata ai budget OCI. Questa capacità consente di impostare budget di uso in ogni compartimento e di ricevere avvisi quando un budget si avvicina a un limite relativo o ha superato un limite assoluto. L'uso di questa funzione può aiutare gli ISV a gestire la spesa tra più clienti e favorire previsioni riguardo all'esigenza di una crescita futura delle risorse.
Chargeback
Sebbene ogni ISV valuti il proprio servizio SaaS in modo diverso, un input comune in molti modelli di determinazione dei prezzi è il concetto di costo del venduto (COGS). Se non si conosce l'importo speso per creare e distribuire un prodotto, è difficile sapere come valutarlo in modo equo e come variare quel prezzo tra i diversi consumatori.
Un servizio SaaS ha molti input di prezzo, inclusi i costi per l'engineering e il marketing, ma un componente chiave è il costo dell'hosting cloud. Questa è un'area in cui l'Analisi dei costi di OCI può aiutare fornendo visualizzazioni dinamiche di utilizzo tra i tenant dei clienti segmentati per compartimenti e/o tag di registrazione costi. L'uso di questi strumenti può rivelarsi utile per capire quanto stai spendendo per ospitare ogni cliente e se è necessario modificare i prezzi offerti.
Se hai bisogno di dati più granulari di quelli forniti dalle nostre visualizzazioni, puoi esportare i dati sull'uso completi a livello granulare in un formato leggibile da un computer per ulteriori analisi, utilizzando uno strumento a tua scelta. E, se ti capita di operare in un ambiente cloud ibrido, puoi utilizzare liberamente uno strumento di terze parti multicloud come CloudHealth per eseguire un'analisi unificata.
Automazione dell'infrastruttura
Pochissime organizzazioni costruiscono manualmente i propri ambienti. Gli ISV hanno riconosciuto il valore dell'orchestrazione dell'infrastruttura e della gestione della configurazione attraverso l'uso di strumenti Infrastructure-as-Code (IaC) come Terraform, Ansible, Puppet e così via. Sebbene rappresenti la soluzione ideale indipendentemente dalle dimensioni dell'organizzazione, dall'impronta tecnica o dall'approccio di distribuzione, IaC è particolarmente fondamentale per gli ISV in crescita che espandono costantemente la propria presenza regionale e la propria base installata. Senza automazione, le spese generali di manutenzione si ridimensioneranno in modo esponenziale e diventeranno difficili da gestire.
OCI fornisce supporto per una serie di strumenti di automazione standard del settore che ti permetteranno di implementare una strategia di automazione indipendente dal cloud. Tra questo è incluso il supporto produttivo per HashiCorp Terraform, Ansible e Chef. Poiché OCI espone tutte le proprie funzionalità tramite SDK e CLI, è facile da integrare con qualsiasi numero di altri strumenti, come Puppet.
Inoltre, OCI si basa sulle capacità di Terraform offrendo un servizio gestito chiamato Resource Manager. Questo servizio, offerto gratuitamente ai clienti OCI, consente di eseguire Terraform all'interno dei confini del modello di sicurezza basato su policy di OCI e fornisce gestione dello stato, modelli, ricerca automatica delle risorse e integrazione GitHub/GitLab pronti all'uso.
Automazione del ciclo di vita del software
Gli ISV utilizzano strumenti di compilazione e distribuzione automatizzati per trasferire il proprio codice attraverso il ciclo di vita dello sviluppo software. Quando si prende in considerazione un modello di distribuzione single-tenant, una solida automazione diventa ancora più importante in quanto una singola distribuzione può essere distribuita a centinaia di istanze di tenant. Inoltre, queste distribuzioni spesso devono essere eseguite in modo continuo per eliminare i tempi di inattività e devono essere sufficientemente flessibili per gestire personalizzazioni basate su diramazioni specifiche per i singoli clienti.
OCI supporta la stragrande maggioranza degli strumenti CI/CD leader di settore sul mercato. Indipendentemente dal tipo in uso, vale a dire Jenkins, Jenkins-X, Spinnaker, TravisCI, GitHub Actions, CircleCI o altri, è probabile che nell'ecosistema software ci sia un utente che utilizza il tuo strumento preferito con OCI.
Inoltre, OCI fornisce un servizio DevOps facile da usare. Si tratta di una piattaforma end-to-end di integrazione e distribuzione continua (CI/CD) per gli sviluppatori. Gli ISV possono utilizzare questo servizio per creare, testare e distribuire facilmente software su OCI, nonché per gestire il codice sorgente con repository Git privati e hosted.
Conclusione
Oracle riconosce che ogni ISV ha alle spalle una storia, un ambiente di origine, un'architettura tecnica, un modello di distribuzione e requisiti aziendali e tecnici esclusivi. Non esiste una soluzione "unica per tutti" per il passaggio all'infrastruttura Oracle Cloud (OCI) in grado di ignorare tutti questi fattori unici e di non prenderli in considerazione quando si sfruttano le capacità OCI.
Un componente chiave del nostro approccio "di alta qualità" alla migrazione ISV è una combinazione del nostro processo di interazione che riunisce architetti, consulenti aziendali e tecnici specializzati che contribuiscono alla progettazione della tua soluzione cloud, oltre all'uso di servizi Cloud Lift per lavorare fianco a fianco con te e trasferire il tuo carico di lavoro in OCI.
Ciò che rende Oracle unico nello spazio ISV è la nostra volontà e il nostro desiderio di impegnarci con i clienti a livello strategico, go-to-market (GTM), architetturale e di implementazione e di far collaborare i nostri esperti con i tuoi per definire insieme le tue esigenze nel cloud.