Cloud ibrido e multicloud con OTOKO®

Più cloud. Un piano chiaro.

I sistemi vicini alla produzione restano on-premise, le nuove applicazioni vengono eseguite nel cloud e alcuni servizi provengono da un ulteriore fornitore. Scenari di questo tipo richiedono un'architettura che superi i confini tra gli ambienti. OTOKO® collega data center, Azure, Telekom T Cloud e altri ambienti, chiarendo al tempo stesso chi è responsabile dei percorsi dei dati, degli accessi e dei guasti.

Di cosa ci occupiamo per voi

Cloud ibrido e multicloud

Pianificazione, attuazione e gestione operativa concordata a cura di OTOKO®

Immagine simbolica · non raffigura un sito di un fornitore

Cosa affidate a OTOKO®

I sistemi distribuiti devono funzionare nel loro insieme.

Una piattaforma aggiuntiva non risolve automaticamente le dipendenze tra le applicazioni. Dati distribuiti possono comportare tempi di risposta più lunghi, traffico dati aggiuntivo e nuove fonti di errore. Per questo verifichiamo prima quali componenti dovrebbero restare insieme e quale scopo di business abbia la distribuzione.

Cosa ci affidate

L'integrazione comprende la configurazione concordata di rete e accessi, nonché i test dei percorsi dei dati coinvolti. Si aggiungono il coordinamento della gestione operativa e dell'escalation oltre i confini tra fornitori, e una documentazione delle dipendenze residue. Anche un eventuale cambio successivo viene valutato in termini di esportazione dei dati e impegno necessario.

I servizi nel dettaglio

Ambito del servizio

Collegare i percorsi dei dati e definire le responsabilità.

Innanzitutto si valuta una distribuzione sensata delle applicazioni. Seguono i collegamenti e le procedure operative condivise. Le dipendenze e l'impegno necessario per un eventuale cambiamento restano parte della valutazione, anche se l'assetto attuale rimane inizialmente invariato.

Individuare la collocazione più adatta per ogni applicazione

I flussi di dati e i tempi di risposta aiutano a decidere dove un'applicazione dovrebbe essere eseguita. Per i componenti correlati vengono verificate le dipendenze. Lo scenario target motiva poi quali parti restano in locale e quali possono essere distribuite in modo sensato su altri ambienti.

Ciò che resta al vostro team per proseguire

Un'assegnazione dei workload con flussi di dati documentati e confini architetturali.

Attuazione tecnica

Workload placement e percorsi dei dati

Latenza, volume di dati e dipendenze determinano dove le applicazioni possono essere eseguite in modo efficace. Verifichiamo quali componenti dovrebbero restare insieme e quali possono comunicare tramite interfacce definite. L'ubicazione dei dati viene considerata sull'intero percorso di elaborazione.

Collegare siti e cloud

Le connessioni devono funzionare anche quando le condizioni cambiano. Dopo aver configurato i percorsi di rete e le regole di accesso previsti, testiamo quindi gli effetti di un'interruzione. In questo modo diventa chiaro quali applicazioni sono interessate e quale reazione sia necessaria a livello operativo.

Ciò che resta al vostro team per proseguire

Un piano di connessione con casi di test per l'esercizio normale e per i guasti.

Attuazione tecnica

VPN, connessioni private e DNS

Le connessioni ricevono routing, risoluzione dei nomi e regole di accesso concordati. ExpressRoute è un'opzione di Azure; le connessioni a Telekom e ad altri cloud vengono pianificate in base all'offerta concreta. I guasti e la larghezza di banda disponibile fanno parte della valutazione.

Organizzare la gestione operativa condivisa

Con più fornitori, un guasto non deve rimanere bloccato tra le diverse responsabilità. I canali di notifica, la responsabilità sugli accessi e il coordinamento delle modifiche vengono definiti insieme. La documentazione operativa indica chi si occupa di un incidente e quali altre parti coinvolgere.

Ciò che resta al vostro team per proseguire

Una matrice delle responsabilità e procedure di accesso ed escalation concordate.

Attuazione tecnica

Identità e gestione operativa trasversale

Chiariamo come utenti e sistemi accedono ai servizi e chi approva le modifiche. Monitoraggio ed escalation devono estendersi oltre i confini di più piattaforme. Un piano operativo condiviso rende visibili le responsabilità di IT interna, provider cloud e OTOKO®.

Pianificare fin da ora un cambio futuro

Un eventuale cambio di fornitore dipende dai formati dei dati, dalle modalità di esportazione e dai servizi utilizzati. Queste dipendenze vengono rilevate e valutate in termini di impegno. Consideriamo inoltre il traffico dati corrente e i compiti operativi aggiuntivi, in modo che la distribuzione resti giustificabile sul piano economico.

Ciò che resta al vostro team per proseguire

Un approccio di uscita documentato, con le dipendenze residue e le stime dell'impegno.

Attuazione tecnica

Portabilità e pianificazione dell'uscita

Container e Infrastructure as Code possono favorire la ripetibilità, ma non rendono automaticamente i servizi intercambiabili. Rileviamo le dipendenze specifiche della piattaforma, l'esportazione dei dati e l'impegno necessario per il cambio. Anche il trasferimento dati continuo e i compiti operativi duplicati rientrano nella valutazione dei costi.

Pianificazione e attuazione nel dettaglio

Più ambienti richiedono una visione comune dell'applicazione.

Le architetture cloud ibride e multi-cloud possono collegare i sistemi esistenti a nuove possibilità. Comportano tuttavia interfacce aggiuntive sul piano tecnico e operativo. Verifichiamo quindi prima lo scopo della distribuzione e definiamo di conseguenza l'interazione tra gli ambienti.

Ricavare dalle dipendenze il luogo di esercizio adeguato

Un sistema non può essere collocato in modo sensato senza conoscerne i percorsi dei dati. Un'applicazione gestita localmente può essere strettamente collegata a un database, a un collegamento con macchinari o alla gestione degli utenti. Se singole parti vengono trasferite, i tempi di risposta e la dipendenza dalle connessioni possono diventare più rilevanti. Consideriamo quindi insieme quali componenti dovrebbero restare uniti e quali possano effettivamente essere gestiti separatamente. L'uso desiderato di più fornitori viene valutato rispetto a questi requisiti, anziché essere dato per scontato come obiettivo in sé.

Lo scenario target tiene conto sia del beneficio per il business sia dell'impegno aggiuntivo. Ambienti diversi possono richiedere procedure di accesso, strumenti e competenze specifici. Fanno parte della valutazione anche il traffico dati continuo e la gestione delle interfacce condivise. La decisione documenta perché un'applicazione resti in un determinato luogo o debba esservi trasferita. Nasce così un'architettura che resta verificabile in caso di modifiche successive e la cui distribuzione si spiega con i requisiti delle vostre applicazioni.

Testare i collegamenti sulla base di processi aziendali completi

Una connessione di rete riuscita non dimostra ancora che l'applicazione funzioni completamente attraverso questa connessione. Risoluzione dei nomi, diritti degli utenti, accessi ai dati e interfacce esterne possono richiedere ulteriori presupposti. Durante l'attuazione, i percorsi di comunicazione necessari vengono quindi rilevati e configurati insieme. Successivamente i referenti tecnici e di business verificano i processi rilevanti. Così si può stabilire se l'ambiente non solo sia raggiungibile, ma svolga anche effettivamente i compiti previsti nelle nuove condizioni.

Viene inoltre valutato cosa accade in caso di interruzione. Quali componenti restano utilizzabili, quali operazioni restano in attesa e quali dati devono essere riconciliati in seguito? Le risposte determinano quali procedure siano necessarie nella gestione operativa. Test e documentazione rendono visibili i limiti dell'architettura scelta. Dove un comportamento desiderato non viene raggiunto, occorre prendere una decisione consapevole su adattamento, misure aggiuntive o limitazione residua. Questa decisione fa parte del collaudo dell'integrazione.

Pianificare anche la responsabilità e un possibile cambio futuro

In caso di anomalia che coinvolge più ambienti, spesso non è subito chiaro quale parte ne sia la causa. Senza canali di notifica concordati, le diverse parti possono allora rimandarsi a vicenda la responsabilità. Stabiliamo quindi insieme chi prende in carico un incidente, quali informazioni sono necessarie e come vengono coinvolti altri soggetti. Viene inoltre descritto il coordinamento in caso di modifiche, in modo che un intervento in un ambiente non abbia effetti inosservati su altre applicazioni o sedi.

Un eventuale cambio futuro viene valutato sulla base di dipendenze concrete: esportazione dei dati, servizi utilizzati, configurazione e adattamenti necessari all'applicazione. Utilizzare più fornitori non significa automaticamente che un'applicazione possa essere spostata dall'uno all'altro senza difficoltà. Questi limiti vengono documentati e il possibile impegno viene inquadrato. Il vostro team riceve così una base chiara per le decisioni future e può valutare quale preparazione sarebbe necessaria per un trasferimento o per il consolidamento del panorama IT.

Così collaboriamo

Voi conoscete la vostra attività.
Noi ci occupiamo del lavoro cloud concordato.

Non dovete organizzare da soli ogni passaggio tecnico. Mettiamo per iscritto compiti e decisioni e coinvolgiamo il vostro team dove servono le sue conoscenze o la sua approvazione.

Valutare insieme i percorsi dei dati

Le dipendenze e i requisiti di tempo di risposta determinano una distribuzione sensata. Da questi elementi deriviamo le connessioni necessarie e le interfacce operative.

Il vostro contributo: Illustrate i processi aziendali critici e indicate i responsabili degli ambienti coinvolti.

Testare l'integrazione nel suo complesso

Collegamenti e accessi vengono configurati e verificati come percorsi applicativi completi. Viene inoltre considerato il comportamento in caso di interruzione.

Il vostro contributo: Coinvolgete i rispettivi team di sistema nei test e nella valutazione degli impatti.

Superare i confini tra fornitori nella gestione operativa

I canali di notifica e il coordinamento delle modifiche vengono documentati per tutte le parti coinvolte. Le dipendenze residue restano visibili per le decisioni successive.

Il vostro contributo: Confermate i referenti e i percorsi di escalation per ciascun ambiente coinvolto.

Sala riunioni nell'ufficio OTOKO® di Colonia

Scenario di progetto esemplificativo

Produzione in loco, portale clienti nel cloud

Ecco come potrebbe presentarsi un progetto comune. L'ambito concreto deriva dalla vostra situazione di partenza.

La situazione di partenza
I sistemi legati alla sede devono restare dove sono, mentre un portale pubblico deve poter essere sviluppato in modo flessibile.
Il nostro approccio
Delimitiamo i flussi di dati e pianifichiamo la connessione, le identità e il comportamento in caso di guasti alla connessione.
Lo scenario target
Un'architettura ibrida documentata collega i due mondi con confini di sicurezza e operativi chiaramente definiti.

Cosa ottenete

Risultati con cui
il vostro team continua a lavorare.

Matrice di collocazione con motivazione per ogni workload
Architettura di rete e di identità per tutti gli ambienti
Strategia di uscita con percorso di passaggio per ogni applicazione

Dall'interesse a un incarico concreto

Così prepariamo
il vostro progetto.

Per il primo colloquio non è necessario che questi documenti siano già completi. Chiariamo insieme cosa è già disponibile e quali informazioni dovrà integrare l'assessment.

Utile per iniziare

Sedi, reti e ambienti cloud esistenti
Flussi di dati critici e requisiti di latenza
Direttive su guasti, gestione dei dati e cambio di fornitore

Così nasce un'offerta concreta

L'offerta definisce l'ambito delle prestazioni, la collaborazione richiesta al vostro team, gli accessi necessari, i criteri di collaudo e il passaggio di consegne. I costi del fornitore, le attività di progetto e la gestione operativa continuativa vengono distinti in modo trasparente.

Parliamo dell'assessment

Prima di iniziare

Le vostre domande.
Risposte chiare.

Cosa otteniamo con Cloud ibrido e multicloud?

Matrice di collocazione con motivazione per ogni workload. Architettura di rete e di identità per tutti gli ambienti. Strategia di uscita con percorso di passaggio per ogni applicazione. Concordiamo l'ambito e i criteri di collaudo all'inizio.

Possiamo partire da un ambiente esistente?

Sì. Analizziamo le vostre applicazioni, interfacce e procedure operative esistenti e definiamo insieme le modifiche necessarie. Una ricostruzione completa non è necessariamente richiesta.

Come vengono definiti l'impegno richiesto e le responsabilità?

Dopo l'analisi dello stato attuale concordiamo i pacchetti di lavoro, le responsabilità, i criteri di collaudo e il passaggio di consegne. Ne deriva un'offerta per l'ambito concreto del progetto.

Il multi-cloud è automaticamente più resiliente ai guasti?

No. Identità, reti o database condivisi possono comunque costituire singoli punti di guasto. Fornitori aggiuntivi migliorano la disponibilità solo con un'architettura applicativa adeguata e testata.

Kubernetes elimina ogni dipendenza dal fornitore?

No. Database, storage, reti e processi operativi restano spesso specifici della piattaforma. Valutiamo la portabilità per l'intero workload.

Cloud ibrido e multicloud con OTOKO®

Quali siti e cloud devono collaborare?

Descrivete le applicazioni che oggi comunicano oltre i confini tra gli ambienti. Insieme analizziamo percorsi dei dati, tempi di risposta e responsabilità, e stabiliamo quale integrazione sia necessaria per prima.

Prenotate un primo colloquio su Cloud ibrido e multicloud

Menu

Più cloud. Un piano chiaro.