În articolele precedente am prezentat motivele alegerii lui Windows Azure în faţa altor alternative ca soluţie de scalare. O altă temă a articolelor a fost procesul de migrare al unei baze de date MS SQL în SQL Azure. În articolul curent vom încheia această serie prin a prezenta cum am migrat portalul web dintr-un IIS on site în cloud-ul Azure.
Se dădea o arhitectură "clasică" de web: un portal dezvoltat în ASP.net MVC (3 şi 4) având în spate o bază de date ce rula pe MS SQL server ascunsă de Entity Framework.
Aceasta arhitectură trebuia pregatitată de "scalare" - trecută pe un sistem ce permitea deservirea unui număr mare de request-uri.
După ce am analizat mai multe opţiuni de upgrade a arhitecturii (discursul logic poate fi revăzut în articolul precedent), ne-am decis asupra SQL Azure şi Windows Azure ca platforma de migrare.
Windows Azure ne pune la dispoziţie o multitudine de servicii şi facilitaţi (de exemplu service bus, caching, mobile services etc.), însă accesul la aceste servicii ar afecta direct arhitectura sistemului nostru.
Dar în cazul nostru, nu dorim să schimbăm arhitectura ci doar să migrăm unu la unu (în măsura posibilităţilor) arhitectura existentă, chiar dacă aceasta înseamnă că nu vom profita la maxim de facilităţile oferite de Azure.
Aveam de migrat un portal alcătuit din două website-uri de front-end și o familie de directoare virtuale ce conţin servicii.
Avem nevoie de un cel puţin un WebRole - un web role este o maşină virtuală, sau o suită de maşini virtuale (în cazul scalarii) ce găzduieşte un website (sau mai multe).
Într-un cuvânt un WebRole e un server web. Traficul web direcţionat către un WebRole va fi automat împărţit (load balanced) între toate maşinile virtuale ce alcătuiesc WebRole-ul - în felul acesta se realizează scalarea - avem nevoie să servim mai multe request-uri? Mai adăugăm maşini în WebRole.
Restricţia în cadrul unui WebRole e ca toate maşinile virtuale din componenţă să fie "identice" în configuraţie - dacă am început WebRole-ul cu o maşină cu o configuraţie modestă (A) vom putea scala doar adăugând mai multe maşini cu aceeaşi configuraţie A.
Cum configuraţia maşinilor din Azure va afecta direct costurile de hosting un prim pas important este să analizăm ce configuraţie este necesară şi suficientă pentru a rula website-ul/aplicaţia noastră fără probleme, urmând ca apoi să scalăm sistemul adăugând maşini cu aceeaşi configuraţie (şi guideline - găsiţi configuraţia minimă şi scalaţi orizontal - în felul acesta aveţi mai multă flexibilitate şi optimizaţi costurile).
Analiza noastră va ţine cont de documentaţia de pe MSDN , caracteristicile proiectului nostru (dacă am optimizat pentru mai multe procesoare, dacă suntem RAM intensive, dacă ne dorim CPU dedicate sau ne descurcăm cu un CPU shared, etc.) şi de testele de performanţă pe care le vom face cu diverse configuraţii - în felul acesta vom putea decide în cunoştinţă de cauză.
După ce am ales configuraţia pentru WebRole, suntem pregătiţi de a crea proiectul de Azure şi WebRole-ul.
Microsoft ne-a făcut viaţa mai uşoară integrând tot ce înseamnă Azure direct în Visual Studio. Presupunând că folosim Visual Studio 2012 avem nevoie de SDK-ul Azure şi suntem gata de pornire.
Deschidem soluţia ce conţine proiectul/proiectele nostre şi adăugăm un proiect de tip Windows Azure Cloud Service
Pentru că vom adăuga proiectele deja existente în WebRole vom lăsa proiectul de cloud service gol
urmând să adăugăm proiectele în WebRole direct din Solution Explorer
După ce am adăugat primul proiect în WebRole pe următoarele le vom adăuga modificând direct fişierul de ServiceDefinitions.
Acest fişier de configurare va descrie structura de website-uri și directoare virtuale de pe fiecare maşină aşa că în cadrul său vom include:
Într-un final vom ajunge la o configuraţie de tipul acesta:
Ultimul pas este publicarea WebRole-ului pe platforma Azure , adică crearea efectivă de maşini virtuale şi transferarea codului pe fiecare din aceste maşini. Din nou Microsoft a făcut totul uşor pentru noi (poate prea uşor) şi din Visual Studio avem opțiunea de Publish pe proiectul de tip Cloud Service.
Wizard-ul de publicare ne va ajuta să alegem şi să ne creăm infrastructura Azure necesară (cloud service + storage account) şi să alegem dacă publicam în sistemul de staging (recomandat) sau direct pe production.
Dacă totul a mers bine şi WebRol-ul a fost creat putem accesa website-ul/website-urile noastre la adresa vizibilă în portalul de administrare (http://manage.windowsazure.com/) - o adresă tip guid.cloudapp.com dacă am publicat pe sistemul de staging, sau o adresă tip webportalulmeu.cloudapp.com dacă am publicat pe production.
Tooling-ul la dispoziţia noastă este excelent şi Microsoft a realizat o interfaţă de management extrem de uşor de înţeles şi folosit pentru Azure.
Cu toate acestea e aproape sigur că vă veţi lovi de o grămadă de obstacole în momentul migrării (particulare arhitecturii/contextului vostru). De asemenea mai sunt încă multe întrebări la care nu am răspuns (şi nici nu am încercat) în cadrul acestui articol (s-a trecut rapid peste logica de decizie "un sigur webrole" vs "mai multe webrole-uri") aşa că dacă doriţi să aflaţi mai multe detalii sau aveţi întrebări specifice, mă puteţi contacta la dragoş(at)txtfeedback.net
Migrarea în Azure nu a fost fără probleme, însă acum la trei luni din momentul migrării putem spune că suntem deplini satisfăcuţi de rezultate (şi de return on investment).
Majoritatea dificultăţilor au fost de know-how - cum anume traduci o arhitectură standard la un cloud - ce exact se schimba la baza de date, ce exact e un WebRole, de ce configuraţie ai nevoie? MSDN, traing-urile de pe Pluralsight, stackoverflow au ajutat, însă de departe cel mai folositor au fost discuţiile cu specialişti care au mai trecut prin acest tip de proiect.
Mulţumim cu această ocazie lui Radu Vunvulea (iQuest) şi lui Zoli Herczeg (Microsoft) care şi-au găsit timp în program să stea de vorbă cu noi şi să ne răspundă întrebărilor.
de Ovidiu Mățan
