La ce să ne gândim când proiectăm o aplicatie în cloud

imageCâteva considerații legate de arhitectura aplicațiilor pe platforma Windows Azure:

1. Vom fi într-un mediu dinamic. Orice dependență de mașina locală trebuie ruptă. Dacă vă bazați pe adrese de IP, porturi, nume de computer, atunci puteți uita de ele. În cloud trebuie să vă așteptați că aplicația voastră va fi mutată pe alte mașini. Altfel nu veți putea scala împreună cu platforma sau nu veți putea relua activitatea în caz că sunteți mutați din cauza unor defecțiuni hardware. La limită, puteți să suprascrieți metodele de stop și start ale mediului pentru a trata schimbările.

2. Vom avea latențe impredictibile. Aplicația trebuie să fie capabilă să lucreze cu timpi de răspuns impredictibili din partea sistemului de stocare, dar și din partea altor aplicații. Dacă pe o mașină locală eram obișnuiți să avem fișiere, tabele sau alte obiecte acolo pe aceeași mașină, ei bine, în cloud aceste obiecte pot fi (și cu siguranță vor fi) pe alte mașini, sau chiar alte containere, sau chiar alte datacentere. Decorați codul cu logică de reîncercare.

3. Tranzacții și efectul asupra benzii și a costurilor. Când plătim pentru bandă, nu vom plăti pentru o anumită dimensiune de țeavă (așa cum suntem obișnuiți de la furnizorii de net), ci vom plăti cantitatea de date transferată în GB. Trebuie să ne obișnuim că stocarea o vom plăti nu numai per GB, dar și per tranzacție (acces). În plus, dacă datele sunt în alt datacenter, vom plăti bandă pentru ambele datacentere.

4. Autentificare și autorizare. Folosiți Azure AppFabric pentru a face ”outsourcing” la autorizare. Apoi veți putea face actualizări prin modificarea configurării, fără eforturi. Dacă folosiți deja ASP.NET membership provider, atunci sunteți acasă pe Windows Azure.

5. Starea aplicației. Am văzut deja la punctul 1. că aplicațiile se pot muta pe alte mașini, ceea ce înseamnă că orice date de care avem nevoie trebuie persistate într-una din elementele de stocare din Windows Azure (bloburi, cozi, tabele nosql sau baze de date relaționale SQL Azure).

6. Datele. Deși am mari îndoieli că cineva își poate proteja mai bine datele pe serverele proprii decât în cloud, hai să numim câteva tehnici de a liniști eventuali clienți paranoici, care preferă să aibă control fizic asupra datelor: modularizare (mutați în cloud doar datele cu care se simte clientul comfortabil, păstrați restul on-premises); sharding; criptare. Nu ezitați să le combinați.

Detalii în:

2 gânduri despre &8222;La ce să ne gândim când proiectăm o aplicatie în cloud&8221;

  1. 3 – De ce as face asta ? De ce as plati pentru tranzactie si pentru acces ? Pare a fi un model mult mai prost decat ceea ce e acum.
    Scalabilitatea e o problema doar pentru cei foarte mari, iar acestia isi permit propriul „nor”. Vezi facebook facand asta ?

  2. @Radu, îți spun asta fiindcă tranzacțiile cu storage-ul îți apar pe factură (1 cent pentru fiecare mie de tranzacții). În nor plătești ceea ce folosești, nu ce ceea ce poți folosi.
    Nu e vorba numai de scalabilitate, ci și de elasticitatea resurselor. Folosești cât îți trebuie, când îți trebuie.

Comentariile nu sunt permise.