Cele mai scumpe probleme de infrastructură apar la câteva luni după punerea în producție, când sistemul se comportă altfel decât se aștepta cineva. Baza de date nu suportă volumul real de scriere, clusterul nu poate fi actualizat fără oprire, iar mediul de test nu seamănă suficient cu producția pentru a prinde problemele din timp. Aproape toate aceste situații se pot preveni printr-o etapă de proiectare serioasă, făcută înainte de a se cumpăra echipamente sau de a se scrie primul script de provizionare.
Metoda de lucru
Începem de la cerințe măsurabile, nu de la tehnologii. Care este volumul de tranzacții la vârf și cum a evoluat în ultimele douăsprezece luni. Cât timp de indisponibilitate este tolerabil și cât costă efectiv o oră de oprire. Ce cerințe legale există privind localizarea datelor. Cine va opera sistemul și ce competențe are deja echipa. Fără aceste răspunsuri, orice diagramă este o presupunere.
Dimensionarea o facem pe baza măsurătorilor din sistemul actual, nu pe estimări. Colectăm date despre utilizarea de procesor, memorie, IOPS și lățime de bandă pe o perioadă relevantă, identificăm vârfurile reale și proiectăm cu o marjă de creștere justificată. Supradimensionarea este cea mai frecventă formă de risipă pe care o întâlnim, iar subdimensionarea produce incidente în cel mai prost moment posibil.
Pentru deciziile importante prezentăm de obicei două sau trei variante, cu model de costuri pe trei ani și cu avantajele și dezavantajele fiecăreia scrise explicit. Un arhitect care propune o singură soluție și o prezintă ca fiind evidentă ascunde, de regulă, compromisurile pe care le-a făcut. Fiecare decizie majoră ajunge într-un registru ADR, astfel încât peste doi ani cineva să poată înțelege de ce s-a ales varianta respectivă.
Ce livrăm
Documentația de arhitectură cuprinde diagrame logice, diagrame fizice sau de resurse cloud, fluxurile de date între componente și punctele de integrare cu sistemele existente. Adăugăm modelul de rețea și de securitate, strategia de stocare și de backup, planul de recuperare și modul în care sistemul va fi actualizat fără întreruperi.
Peste acestea vine planul de implementare, împărțit în etape cu criterii de acceptanță clare pentru fiecare. O etapă nu se consideră încheiată pentru că a fost instalat un serviciu, ci pentru că a trecut testele stabilite: comportamentul la încărcare, comutarea pe nodul de rezervă, restaurarea dintr-o copie de siguranță, timpul de revenire.
Acolo unde este relevant, proiectăm ținând cont de cerințele NIS2 privind segmentarea rețelei, controlul accesului și jurnalizarea, precum și de obligațiile GDPR referitoare la localizarea și protejarea datelor cu caracter personal. Este considerabil mai ieftin să incluzi aceste măsuri în proiect decât să le adaugi ulterior peste un sistem aflat în producție.
Pentru cine este potrivit
Serviciul are sens pentru companii aflate în fața unei schimbări structurale: o migrare din centrul de date propriu către cloud sau invers, înlocuirea unei platforme de virtualizare, construirea unui al doilea sit pentru continuitatea activității, sau lansarea unui produs pentru care infrastructura existentă nu a fost gândită.
Este util și pentru echipele de dezvoltare care au construit o aplicație bună, dar au ajuns la limita a ceea ce se poate obține fără o infrastructură proiectată corespunzător. Adesea nu este nevoie de o rescriere, ci de un model de stocare potrivit, de o separare corectă a mediilor și de o strategie de scalare stabilită în avans.
Rezultate
Ieșiți din etapa de proiectare cu un document pe care un furnizor îl poate cota corect, pe care echipa internă îl poate implementa și pe care un auditor îl poate citi. Estimările de buget devin apropiate de realitate, pentru că se bazează pe dimensionare măsurată. Iar deciziile pe care le luați acum rămân explicate în scris pentru cine va prelua sistemul mai târziu.