Beneficiile organizationale ale microserviciilor

W e’ve fost tot acolo , in crestere cu produse software codebases mari si complexe, adaugand mai multi ingineri pare sa incetineasca dezvoltarea , mai degraba decat accelerarea acesteia . S-ar parea ca proiectul a atins un punct de rentabilitate in scadere. Deci, cum putem atenua acest lucru si preveni dezastrul iminent?

„Echipele mari, de obicei, ajung sa piarda timpul tuturor”

– J. Richard Hackman, Universitatea Harvard

Pe masura ce un produs software creste, eforturile ingineresti de sprijin trebuie, de obicei, sa se intensifice odata cu acesta.

Array

In acest moment nu este neobisnuit ca noii membri ai echipei sa se lupte pentru a intelege baza de cod si sa inteleaga alegerile tehnice implicite, ceea ce duce la pierderea productivitatii.

Doua reguli pentru pizza

Atunci cand echipa creste dincolo de un anumit punct, nu este neobisnuit ca membrii productivi anteriori sa fie impiedicati, partial de efortul suplimentar pus pe ei de a indruma noi membri intr-o echipa in continua crestere. Dar, de asemenea, din incarcarea suplimentara pusa pe membrii echipei din comunicarea in intreaga echipa acum mult mai mare.

Pentru a atenua pierderea de productivitate, trebuie sa ne mentinem echipele slabe si rapide la o dimensiune optima.

Array

O regula buna aici este „The Two Pizza Team” – abordarea stabilita de Amazon. Esenta conceptului este ca nicio echipa nu ar trebui sa fie mai mare decat una care ar putea fi hranita cu doua placinte pentru pizza.

„Cred ca acest tip de descentralizare este important pentru inovatie, deoarece mainile tale sunt mai aproape de butoanele a ceea ce incerci sa construiesti”

– Jeff Bezos, CEO Amazon

Desigur, mentinerea echipelor la aceasta dimensiune, atunci cand nevoile de produs si afacerea sunt in crestere, nu este nici durabila. Prin urmare, voi discuta despre o abordare arhitecturala care nu numai ca permite echipelor sa ramana slabe si concentrate, ci si descentralizata.

Array

Prin migrarea la arhitectura microservice, luam un produs software mare si il impartim in mai multe servicii mai mici, fiecare cu o complexitate foarte redusa. Acest lucru poate fi realizat prin mentinerea serviciilor individuale cuplate in mod slab si vorbind printr-un contract stabil si bine definit, mai des decat asa-numitul REST-API.

Ce este un microserviciu?

A lua cuvantul micro prea literar este o conceptie gresita frecventa care va duce la dureri de cap majore pe drum.

In schimb, aceste servicii ar trebui sa corespunda principiilor Design Driven Design (DDD). Ganditi-va la nume ca la servicii specifice domeniului, in care fiecare serviciu este responsabil pentru un anumit domeniu comercial al produsului.

Acum s-ar putea sa va ganditi ca ati obtinut deja un produs de succes si ca preferati sa nu incepeti de la zero. Nu va faceti griji, de fapt aceasta este etapa perfecta pentru a incepe. In acest stadiu, pur si simplu nu mai adaugam noi caracteristici nucleului monolitic existent. In schimb, le vom dezvolta ca servicii noi, construind astfel o fatada in jurul vechiului nucleu. Aceste servicii vor sufoca incet vechiul monolit si vom ajunge la o arhitectura de microserviciu de succes.

Independenta tehnica, distribuirea proprietatii

Unul dintre cele mai mari beneficii ale unei arhitecturi de microservicii este posibilitatea independentei tehnice datorita cuplajului slab si a contractelor puternice angajate de serviciile individuale. Acest lucru permite fiecarei echipe sa detina cu adevarat alegerile tehnologice facute in cadrul serviciului lor, ceea ce Sam Newman discuta in cartea sa Building Microservices.

Proprietatea echipei asupra serviciilor ca produse proprii stabileste un mediu care incurajeaza atat responsabilitatea, creativitatea, cat si un sentiment mai profund al scopului. Acest mediu este crucial pentru ca inginerii ambitiosi sa prospere si sa ramana plini de resurse.

Misca-te repede

O auzim adesea; deplasati-va rapid, adaptati-va si iterati . In mediul tehnologic de astazi, trebuie intotdeauna sa ne tinem in picioare, gata sa pivotam atunci cand piata o cere.

Prin utilizarea arhitecturii microservice nu mai suntem constransi de alegerile tehnologice anterioare, prin urmare nici incetinite de acestea. Am creat apoi un cadru care permite echipelor sa se deplaseze intr-un ritm considerabil mai rapid, adaptandu-se constant la noile dezvoltari. Ele pot itera rapid si arunca vechiul; ceva care deseori este esential in industria cu o evolutie rapida si extrem de tehnica.

Acum putem incarca cu usurinta noile echipe prin crearea de noi servicii, fara a mai fi nevoie sa intelegem o baza de cod anterioara mare si relatia interna complexa pe care aceasta o implica. Odata eliberata de aceasta povara, echipa este binecuvantata cu o mai mare libertate de a lua decizii rapide, ducand la adaugari utile de produse; ergo, producand un avantaj major atunci cand creste organizatia.

Desigur, odata ce am implementat o arhitectura de microservicii, am vrea sa folosim noi oportunitati. Probabil ca stiti cel putin o mica parte a produsului dvs. care se remarca prin meritul propriu. Complexitatea lansarii acestor piese ca produse separate mai mici in aceasta etapa este mult redusa, deoarece baza de cod de baza poate partaja aceleasi module de servicii software ca produsul de baza. Reflectati un moment si luati in considerare toate noile posibilitati pe care le permite acest lucru.

Avand aceste produse frate ne permite sa extragem valorile individuale de baza din produs si sa le comercializam pentru o baza mai larga de clienti care nu ar folosi produsul mai mare. Pe masura ce unii dintre acesti clienti cresc, ar putea dori sa foloseasca mai multe dintre noile noastre produse sau chiar sa se converteasca la platforma completa. Costurile de intretinere ale acestor noi produse sunt o fractiune din produsul parinte, deoarece acesti frati au o cantitate larga de cod, prin urmare, evolutiile produsului parinte pot fi aplicate direct in aval.

Esenta acestui articol este ca, prin aplicarea unei arhitecturi de microservicii pe o platforma software, se pot obtine beneficii mari in scalabilitatea organizationala. Acesta este rezultatul posibilitatii de descentralizare a luarii deciziilor si a responsabilitatii prin modularizare. Aceasta reducand totodata complexitatea prin comunicarea prin contracte puternice (API) si asigurarea cuplarii libere (fara comunicare interproces). Echipele consecutive pot fi mai mici si pot functiona ca entitati organizationale separate.

In acest articol, partea tehnica a lucrurilor a fost mentinuta in mod deliberat la minimum, cu cat partile mai complicate sunt omise. Cu toate acestea, am atasat mai multe materiale tehnice mai jos pentru cei dintre voi care doresc sa exploreze detaliile subiectului.

ARTICOLE SIMILAREDE LA ACELAȘI AUTOR