Al momento disponiamo di un'app Web MVC .Net con un database back-end del server SQL e due servizi Web che eseguono periodicamente alcune attività di elaborazione nel database.
Sto pensando di confezionare questa app per il cloud, in cui un client la "istanzia" come un intero pacchetto. Questo processo allocare automaticamente i pezzi necessari per eseguire l'intera cosa, vale a dire il sito, il database e gli altri due servizi.
Ho letto parecchio sull'azzurro e sto attraversando un periodo molto difficile per capire l'intero processo di sviluppo, test e implementazione, quindi aggiornare e applicare le modifiche alle distribuzioni esistenti. Sono abituato ad avere il controllo di tutti i pezzi. Per prima cosa mi piace avere tutto in locale sulla mia workstation. Usiamo git e abbiamo il nostro repository autogestito. Trovo strano avere un ambiente di sviluppo su un computer cloud remoto. Penso che il codice sorgente sia una delle risorse più preziose di un'azienda insieme ai dati (i dati in più).
Nell'attuale ambiente costruiamo le app manualmente (so che è lungi dall'essere ideale, automatizzeremo questo processo e per ora non sono preoccupato) e lo implementeremo semplicemente copiando la nuova versione di top of the old uno. Facciamo anche backup, ricompiliamo le stored procedure di database e applichiamo script che massaggiano i dati, cambiano le strutture delle tabelle o aggiungono indici e così via. Ci sono alcuni tempi di fermo assegnati mentre gli aggiornamenti sono fatti. Prima di implementare in produzione, vengono implementati negli ambienti di integrazione e test.
In che modo tutto questo si traduce in un'architettura azzurra?
Ecco il mio modello mentale:
- Lo sviluppo e l'integrazione sono fatti a livello locale.
- Il software è confezionato localmente come SAAS e caricato nel cloud. Presumo che il cloud avrà un manifest che include tutte le risorse di cui l'app ha bisogno e le assegnerà quando l'app viene creata la prima volta nel cloud. Questo processo dovrà essere testato nel cloud da noi.
- Come per gli aggiornamenti, gli aggiornamenti dovrebbero essere applicati dal client alle distribuzioni esistenti. Immagino che un'altra opzione sarebbe quella di creare una nuova istanza e migrare i dati da quello vecchio. Vedo gli aggiornamenti come pacchetti che possono essere rilasciati sulle distribuzioni esistenti e svolgeranno determinate attività, proprio come un software di installazione che esegue un aggiornamento su una versione precedente. Gli aggiornamenti sarebbero stati testati anche nel cloud.
Suppongo che l'app possa avere tempi di inattività minori. Mi rendo conto che altre app potrebbero non avere questo lusso, ma non voglio andare lì ora.
Ad ogni modo, è fattibile nel mondo azzurro? Qualcosa dovrebbe essere fatto in modo diverso? E come si carica in questo modello?
Grazie
Un aggiornamento: stavo riflettendo su di esso e immagino che un altro modello sarebbe stato costruire un'app monolitica che avrebbe permesso agli utenti di registrarsi per il servizio (proprio come un'app di posta elettronica) e allocare le risorse di conseguenza. Suppongo che in questo caso il modello di ricarica sia più semplice. Il rovescio della medaglia è che l'app dovrebbe essere progettata per essere multi-tenant e avrebbe una serie di sfide. Sono ancora confuso su come l'intero ciclo di sviluppo di test- > funzionerebbe in questo caso.