Ciao Laura, buongiorno.

laurar181 ha scritto:

Per avvicinarci a passi pensavamo di prendere i server virtuali.

Effettivamente, procurarti una macchina virtuale in cui ospitare un'istanza di SQL Server è la soluzione che ti offrirebbe la migliore compatibilità con il tuo sistema esistente. Semplicemente, installi SQL Server nella macchina virtuale oppure scegli dalla galleria una VM in cui è già preinstallato. Puoi addirittura portarti la tua licenza grazie al programma di license mobility.

Tuttavia, devi anche pensare al futuro.

laurar181 ha scritto:

non ho in sede un sistemista

Se scegli per la macchina virtuale, avrai l'onere di tenere aggiornato il sistema e farlo scalare nel momento in cui non risultasse più adeguato al volume di richieste.
In quest'ottica, è vero che hai più controllo sul sistema ma è anche vero che le questioni sistemistiche che dovrete affrontare vi distrarranno dallo sviluppo e dal mantenimento dell'applicazione.
Offrire alta disponibilità, ad esempio, è una questione che dovrete affrontare per evitare che la manutenzione al sistema causi dei down ai vostri clienti.
http://azure.microsoft.com/it-it/documentation/articles/virtual-machines-manage-availability/

L'alternativa è usare SQL Azure, che è un database-as-a-service costruito con scalabilità e alta disponibilità in mente, che ti permetterà di rispondere in maniera rapida e semplice quando la clientela aumenterà.
In questo caso hai a disposizione un servizio che ti permette di sfruttare tutta l'elasticità del cloud: vai a pagare solamente quello consumi, a differenza di una macchina virtuale che ha un costo fisso e non è mai realmente ritagliata intorno alle effettive necessità hardware. E quindi ora capisci perché è difficile rispondere a questa domanda.

laurar181 ha scritto:

su cosa devo andare? più memoria? più CPU?

Se scegli Sql Azure, non devi porti questi problemi perché non ti vengono fatturate RAM e CPU, ma le effettive DTU, ovvero i consumi calcolati con una unità di misura che tiene conto anche dell'accesso al disco. Se hai queries che fanno dei table scans o che usano degli indici molto frammentati, andrai a spendere un pochino di più rispetto a queries più ottimizzate. Dato che è tutto segnato nel pannello di Azure, avrai l'opportunità di monitorare il reale consumo e ottimizzare i costi al migliorare dell'applicazione.

Per scalare, non dovrai aumentare le caratteristiche hardware di una macchina (anche perché non hai alcuna macchina da amministrare), ma aggiungere partizioni o altri database, in base a come vuoi ripartire i dati dei tuoi clienti.

Per esempio, potresti decidere di mettere in un unico database tutti i dati dei clienti che hanno sottoscritto con te il contratto base, mentre offrire un database dedicato a quelli che pagano di più perché hanno un contratto premium.

C'è molta documentazione a proprosito. Ecco un articolo da cui iniziare:
http://azure.microsoft.com/en-us/documentation/articles/sql-database-elastic-scale-get-started/

Trovi anche dei video su Channel9, tipo questo.
http://channel9.msdn.com/Shows/Data-Exposed/Azure-SQL-Database-Elastic-Scale

Lo scorso 23 aprile si è anche svolto un evento per la community in cui si è discusso della Data Platform di Azure e delle peculiarità di Sql Server usato in una VM oppure come servizio.
Non riesco a trovare una registrazione in italiano, ma qui ci sono le slides.
http://www.communitydays.it/content/downloads/18/6_slides.zip

In ultimo: se scegli Sql Azure devi prima assicurarti che il tuo database sia compatibile, infatti non supporta tutte le funzionalità di un'installazione "normale" di SQL Server. Ecco un elenco riassuntivo delle caratteristiche non supportate.
https://msdn.microsoft.com/en-us/library/azure/ee336281.aspx

Io però ti consiglio di usare questo tool, che ti indicherà se il tuo db è adeguato ad essere migrato su Sql Azure.
https://sqlazuremw.codeplex.com/

Leggi tutto molto accuratamente. Prendere una scelta informata oggi ti può far risparmiare tempo e soldi in futuro, ancor più se il tuo business cresce velocemente.

Per l'applicazione web: stessa cosa. Non devi necessariamente procurarti una macchina virtuale ma puoi pubblicarla su un web role e poi sfruttare la scalabilità automatica per sopperire ai picchi di richieste, quando si verificano.

ciao,
Moreno

---

Modificato da BrightSoul il 01 maggio 2015 11.09 -

laurar181 ha scritto:

Io non so se lavori in una azienda che sviluppa software oppure se lavori in una azienda che sviluppa software ma capisce i tempi di realizzazione e studio.

Ho lavorato in entrambe. Esperienza triste con la prima.

laurar181 ha scritto:

Se mi muovo a oggi verso Sql Azure devo rivedere molti punti della mia applicazione anche se si lavora con Entity Framework.
Stesso discorso per il webroot.

Forse i punti da rivedere non sono tanti quanti sembrano, ma... quali sono le alternative? Voglio dire: se anche ti sposti su una macchina virtuale di Azure, non avrai comunque realizzato un sistema in alta disponibilità. Avrai semplicemente spostato il problema da A a B.
Neanche Azure, infatti, ti può garantire che il servizio sarà continuativo in quelle condizioni. Hai bisogno di almeno due macchine in un Availability Set per poter beneficiare del 99,95% di uptime promesso dal contratto di servizio. E per gestire le macchine, hai bisogno anche di un minimo di competenze sistemistiche.

Se il vostro problema è la disponibilità, è inutile chiedersi di quanta RAM o CPU la macchina abbia bisogno. Se vuoi spostarti su Azure, procuratene una simile a quella che avevi su Register, ma consapevole del fatto che può andar giù allo stesso modo.

A proposito: prendersela con Register non serve a nulla, e vorrei essere schietto per metterti di fronte alla situazione: è ovvio che le macchine possano rompersi, così come dal cielo può piovere. Alla fine, se ti bagni, la responsabilità è tua per non aver portato l'ombrello.

laurar181 ha scritto:

Qui purtroppo non è così e il tutto è già venduta e deve essere pronto.

Ok, ma le cose non succedono solo perché le si desidera. Questa in cui vi trovate oggi è la conseguenza dell'aver saltato alcune fasi di pianificazione. Probabilmente avete sottostimato l'architettura necessaria a tenere in piedi un'applicazione che dia una buona esperienza d'uso ai suoi utenti.

Se al management serviva questa situazione per capire l'importanza della scalabilità e dell'alta disponibilità, allora non potevate fare diversamente. Potete allocare del personale per manutenere l'attuale installazione, e magari crearvi degli strumenti che vi mandino degli avvisi in caso di down. Altri, contemporaneamente, prepareranno un piano di migrazione verso la nuova architettura.

laurar181 ha scritto:

Parlando con dei tecnici microsoft mi consigliano di avere il data base separato dalla macchina che ospita IIS e la mia web application.

1 webserver + 1 database server per me sono due single-point of failure. Non risolvono e, anzi, potrebbero peggiorare il problema della disponibilità che state avendo ora.

ciao,
Moreno

---

Modificato da BrightSoul il 04 maggio 2015 23.27 -

ciao Laura,

laurar181 ha scritto:

Il nostro sistemista Linux ci ha detto che ci sono cloud e cloud

Certamente, ma i guasti all'hardware succedono a tutti. Facciamo per ipotesi che un servizio posto su una macchina virtuale che viene spostato da Register ad Azure ottenga un miglioramento dal 98% al 99% della disponibilità (cifre inventate).
Il 99% è comunque una percentuale bassa per un servizio che serve a pagarvi gli stipendi. Vuol dire che 1 volta su 100 fallisce. Figurati questo: ogni sera rientri stanca dal lavoro e ti capita che per più di 3 volte all'anno non riesci ad aprire la porta di casa perché la serratura non funziona. Siccome l'ora è tarda, non trovi nessuno che ti possa aiutare e sei costretta a dormire sul pianerottolo. Per 3 volte all'anno.

Lo stesso identico fastidio lo provano i clienti quando il tuo strumento (che gli serve per lavorare) non funziona. Ti assicuro che so di cosa sto parlando perché in passato mi è capitato di rispondere personalmente a questo genere di lamentele.

laurar181 ha scritto:

quando hai un cliente gold con più di 1000 domini e 5 macchine virtuali avvertire del down sarebbe stato il minimo.

Se il down era pianificato per manutenzione allora sì, sono stati sconsiderati sia per non avervi avvertito e sia per non aver eseguito il lavoro di notte o nel weekend.
Più probabilmente penso che non abbiano potuto prevedere il down, vuoi perché si è guastato un server, o perché una ruspa ha tranciato i cavi della fibra, e così via.
Anche se ti avessero avvertito, ai clienti non frega nulla del preavviso. Loro vogliono che il software funzioni e funzioni sempre. Non vogliono dormire sul pianerottolo o da un amico, ma vogliono poter entrare sempre in casa loro.

Quindi, per non subire i problemi tecnici del tuo cloud provider, spostarsi su Azure non basta, ma devi mettere il servizio in altà disponibilità, eventualmente (più avanti) pensando anche ad un piano di disaster recovery nel caso in cui si verifichino eventi eccezionali che disabilitino l'intero datacenter.

Il cloud di Azure è ottimo perché ha una risposta a tutte queste esigenze, come appunto il site recovery, che ti consentirebbe di spostare col minimo sforzo tutta l'infrastruttura in un altro datacenter nella stessa area geografica (es. europa occidentale -> europa settentrionale).

laurar181 ha scritto:

I costi di Azure sono alti

Se lo valuti rispetto ad una soluzione che ti offre solo il 99% di disponibilità, certamente può essere più costoso. Però devi tenere presente che anche perdere un cliente ha un costo, così come il vostro tempo speso a risolvere guasti frequenti o a gestire le telefonate dei clienti che urlano molto forte e molto a lungo (cit.).

Io sono di questa idea: se vuoi far star bene qualcuno, gli troverai una sistemazione con tutti i comfort necessari. Senza particolari eccessi, ma il giusto per stare sereni. Allo stesso modo, l'applicazione che mi paga da vivere merita un ambiente che gli consenta di funzionare bene. Se anche mi costasse 400 euro al mese, come un appartamento in affitto in provincia, non lo considererei un costo elevato.

ciao,
Moreno

---

Modificato da BrightSoul il 06 maggio 2015 08.25 -