scrierea codului aplicației precede Majoritatea soluțiilor cloud-soluții pe care majoritatea programatorilor de aplicații le scriu special pentru aceste zile.

pentru a gestiona această disonanță, a apărut metodologia aplicației cu 12 factori. The 12 factors este o abordare care ajută programatorii să scrie aplicații moderne într-un mod declarativ, folosind contracte clare implementate prin cloud.

în acest articol, voi introduce metodologia aplicației cu 12 factori și voi oferi un rezumat la nivel înalt al principiilor sale.

care este metodologia aplicației cu 12 factori?

în 2012, programatorii de la Heroku au debutat metodologia aplicației cu 12 factori. Acești programatori au dezvoltat și implementat sute de aplicații au scris această metodologie, bazându-se pe experiența lor de a vedea aplicațiile SaaS „în sălbăticie”.

acest grup consideră metodologia o triangulare a:

• practici ideale pentru a sprijini dezvoltarea aplicațiilor
• dinamica care apare ca o aplicație crește organic
• relația și colaborarea dintre dezvoltatorii de baze de cod

obiectivele lor sunt de două ori mai mari decât:

• pentru a ajuta la evitarea costurilor de eroziune de software
• pentru a crește gradul de conștientizare a problemelor sistemice care le-am observat în dezvoltarea de aplicații moderne

grupul indică două surse de inspiratie, modele de arhitectura de aplicare întreprindere și Refactoring, atât de dezvoltator profesionist Martin Fowler.

și acum, voi introduce fiecare dintre cei 12 factori.

principiul I. Codebase

„o bază de cod urmărită în controlul reviziei, multe implementări”

baza de cod ar trebui să aibă un sistem logic de control al versiunii ușor de înțeles.

fiecare implementare ar trebui să aibă propriul depozit de cod care poate fi implementat în mai multe medii. Evitați să găzduiți mai multe aplicații în același depozit. Acest lucru face ca controlul versiunii să fie aproape imposibil de înțeles, iar versiunile se vor încurca, rezultând o muncă fără valoare adăugată.

principiul II. dependențe

„declarați și izolați în mod explicit dependențele”

acest principiu susține că nu trebuie să vă bazați niciodată pe existența implicită a pachetelor la nivel de sistem. În schimb ”

• asigurați-vă că bibliotecile specifice aplicației sunt disponibile
• verificați dacă sunt disponibile bibliotecile de sistem necesare, cum ar fi curl sau ImageMagick. (Nu există nicio garanție că acestea există pe fiecare sistem în care aplicația ar putea rula în viitor.)

în general, o aplicație cu 12 factori trebuie să fie auto-conținând. Aplicația trebuie izolată suficient pentru a evita interacțiunile cu bibliotecile conflictuale care sunt instalate pe mașina gazdă.

să ne uităm la un exemplu. În Python, puteți obține declarația și izolarea folosind Pip și Virtualenv respectiv. Pentru a satisface acest principiu, trebuie să utilizați întotdeauna atât Declarația de dependență, cât și izolarea. Gestionați dependențele din cadrul aplicației, nu dintr-o sursă externă. Dependențele ar trebui să fie găzduite într-un depozit din cadrul aplicației

principiul III. Config

„stocați config în mediu”

o aplicație și configurația acesteia ar trebui să fie complet independente. Mai mult, stocarea configs în mod constant în cod ar trebui evitată în întregime.

configurațiile dvs. ar trebui să aibă un fișier separat și nu ar trebui să fie găzduite în depozitul de coduri. Un fișier de configurare separat facilitează actualizarea valorilor de configurare fără a atinge baza de cod reală, eliminând necesitatea re-implementării aplicațiilor dvs. atunci când modificați anumite valori de configurare.

când configurațiile sunt în mediu, nu în aplicație, ca variabile, îl puteți muta cu ușurință într-un alt mediu fără a atinge codul sursă. Aplicațiile cu doisprezece factori stochează Config – uri ca variabile, astfel încât este „puțin probabil să fie verificate accidental în depozit”. Un alt bonus: atunci config-urile dvs. sunt independente de limbă și de sistemul de operare.

principiul IV. servicii de suport

„tratează serviciile de suport ca resurse atașate”

într-o aplicație cu 12 factori, orice servicii care nu acceptă aplicația de bază trebuie accesate ca serviciu. Aceste servicii esențiale non-core ar putea include:

• baze de date
• stocare externă
• cozi de mesaje
• etc.

acestea pot fi tratate ca o resursă. Acestea ar trebui să fie accesate ca un serviciu prin HTTP sau cerere similară, apoi specificate în config. În acest fel, sursa serviciului poate fi modificată fără a afecta codul de bază al aplicației.

de exemplu, o aplicație care utilizează un sistem de așteptare a mesajelor este cea mai bună dacă se poate schimba cu ușurință de la RabbitMQ la ZeroMQ la ActiveMQ schimbând doar informațiile de configurare.

principiul V. Build, release, run

„strict separate construi și a alerga etape”

o aplicație de 12 factori este strict cu privire la separarea celor trei etape de construire, eliberare, și să fie difuzate.

începeți procesul de construire stocând aplicația în controlul sursei, apoi construiți dependențele acesteia. Separarea informațiilor de configurare înseamnă că o puteți combina cu construirea pentru etapa de lansare—și apoi este gata pentru etapa de rulare. De asemenea, este important ca fiecare versiune să aibă un ID unic.

principiul VI. procese

„executați aplicația ca unul sau mai multe procese apatride”

stocați orice date necesare pentru a persista într-un serviciu de suport stateful, cum ar fi bazele de date. Ideea este că procesul este apatrid și nu împărtășește absolut nimic.

în timp ce mulți dezvoltatori sunt obișnuiți cu „sesiuni lipicioase”, stocarea informațiilor în sesiune așteptând următoarea solicitare va fi de la același serviciu contrazice această metodologie.

principiul VII. principiul de legare a portului

„exportați servicii prin legarea portului”

aplicațiile cu 12 factori trebuie să fie întotdeauna independente de aplicațiile suplimentare. Fiecare funcție ar trebui să fie propriul proces—în deplină izolare.

într-un mediu tradițional, presupunem că diferite procese gestionează funcționalități diferite. Ca atare, este ușor să presupunem în continuare că aceste funcționalități sunt disponibile printr-un protocol web, cum ar fi HTTP, ceea ce face probabil ca aplicațiile să ruleze în spatele serverelor web, cum ar fi Apache sau Tomcat. Dar acest lucru este contrar metodologiei cu 12 factori.

în schimb, adăugați o bibliotecă server web sau similar cu aplicația de bază. Aceasta înseamnă că aplicația poate aștepta cereri pe un port definit, indiferent dacă este HTTP sau un protocol diferit.

principiul VIII. concurenta

„scară prin modelul de proces”

un adevărat app 12-factor este proiectat pentru scalare. Construiți-vă aplicațiile astfel încât scalarea în cloud să fie perfectă. Când dezvoltați aplicația pentru a fi concurentă, puteți crea noi instanțe în cloud fără efort.

pentru a adăuga mai multă capacitate (porniți procese suplimentare pe mașini suplimentare), Aplicația dvs. ar trebui să poată adăuga mai multe instanțe în loc de mai multă memorie sau CPU pe mașina locală.

principiul IX. Disposability

„maximizați robustețea cu pornire rapidă și oprire grațioasă”

conceptul de procese de unică folosință înseamnă că o aplicație poate muri în orice moment, dar nu va afecta utilizatorul—aplicația poate fi înlocuită cu alte aplicații sau poate porni din nou. Construirea disponibilității în aplicația dvs. asigură că aplicația se închide cu grație: ar trebui să curețe toate resursele utilizate și să se închidă fără probleme.

atunci când este proiectat în acest fel, aplicația vine înapoi din nou repede. De asemenea, atunci când procesele se termină, ar trebui să-și termine cererea curentă, să refuze orice cerere de intrare și să iasă.

principiul X. paritatea Dev/prod

„mențineți dezvoltarea, stadializarea și producția cât mai asemănătoare”

aplicațiile implementate pentru dezvoltare și producție ar trebui să aibă paritate. În esență, ar trebui să existe doar cea mai mică diferență între ambele implementări.

o mare diferență poate duce la probleme de compatibilitate neintenționate între dev și Codul de producție. Atunci când construiți o aplicație cu 12 factori, serviciile de suport între dev și prod trebuie să fie aceleași; o diferență aici ar putea cauza probleme semnificative pe linie.

principiul XI. Logs

„tratează jurnalele ca fluxuri de evenimente”

spre deosebire de aplicațiile monolitice și tradiționale care stochează informații de jurnal într—un fișier, acest principiu susține că ar trebui să transmiteți jurnalele într-o locație aleasă-nu pur și simplu să le aruncați într-un fișier jurnal.

de obicei, jurnalele nu se află în același loc în mediile bazate pe cloud după fiecare ardere. Pe măsură ce încep noi procese sau aplicația dvs. se blochează, jurnalele vor fi distribuite pe mai multe mașini cloud; nu vor sta pe o singură mașină sau gazdă.

rezolvați această problemă numind un loc comun pentru jurnalele de flux. În unele cazuri, puteți redirecționa pur și simplu Stdout la un fișier. Cu toate acestea, mai probabil, veți dori să implementați un router de jurnal precum Fluentd și să salvați jurnalele în Hadoop sau într-un anumit serviciu, cum ar fi Splunk.

principiul XII. procesele de administrare

„rulați sarcinile de Administrare/Gestionare ca procese unice”

principiul final al aplicației cu 12 factori propune separarea sarcinilor administrative de restul aplicației. Aceste activități pot include migrarea unei baze de date sau inspectarea înregistrărilor.

deși procesele de administrare sunt separate, trebuie să continuați să le rulați în același mediu și împotriva codului de bază și a configurației aplicației în sine. Expedierea codului sarcinilor de administrare alături de aplicație împiedică deriva.

lectură înrudită

• BMC DevOps Blog
• Agile vs Cascada SDLCs: care este diferența?
• conducte de implementare (CI / CD) în ingineria Software
• ce este programarea extremă (XP)?
• cum & de ce să devii o fabrică de Software
• conferințe de top pentru programare & dezvoltare Software