Sembra chì u piccu di l'hype per i microservizi hè daretu à noi. Ùn avemu più leghje posti parechje volte à settimana "Cumu aghju movu u mo monolitu à 150 servizii". Avà aghju intesu più pinsamenti di sensu cumunu: "Ùn odiu micca u monolitu, mi importa solu di l'efficienza". Avemu ancu osservatu parechje migrazioni da i microservizi torna à u monolitu. Quandu si passa da una grande applicazione à parechji servizii più chjuchi, duverete risolve parechji prublemi novi. Elenchemu u più brevemente pussibule.

Ambientazione: da a chimica di basa à a meccanica quantistica

A creazione di una basa di dati di basa è di l'applicazione cù un prucessu di fondo era un prucessu abbastanza simplice. Publicu u readme nantu à Github - è spessu dopu una ora, un paru d'ore à u più, tuttu funziona, è aghju principiatu un novu prughjettu. Adding and running code, almenu per l'ambiente iniziale, hè fattu u primu ghjornu. Ma s'ellu ci avventuramu in i microservizi, u tempu di lanciamentu iniziale s'ingrandisce. Iè, avà avemu Docker cù l'orchestrazione è un cluster di macchine K8, ma per un programatore principiante tuttu questu hè assai più complicatu. Per parechji juniors, questu hè un pesu chì hè veramente una complicazione innecessaria.

U sistema ùn hè micca faciule da capisce

Fighjemu nantu à u nostru junior per un mumentu. Cù l'applicazioni monolitiche, s'ellu hè accadutu un errore, era faciule per seguità è passà immediatamente à debugging. Avà avemu un serviziu chì parla à un altru serviziu chì mette in fila qualcosa nantu à un bus di messagiu chì tratta un altru serviziu - è dopu si trova un errore. Avemu da mette tutti sti pezzi inseme per eventualmente scopre chì u serviziu A hè in esecuzione a versione 11, è u serviziu E hè digià aspittendu a versione 12. Questu hè assai sfarente da u mo logu standard cunsulidatu: avè aduprà un terminal / debugger interattivu per caminari. attraversu u prucessu passu à passu. Debugging è capiscitura sò diventati intrinsecamente più difficili.

S'ellu ùn pò micca esse debugged, forse avemu da pruvà

L'integrazione cuntinuu è u sviluppu cuntinuu sò oghji diventate cumune. A maiò parte di l'applicazioni novi chì vecu creanu automaticamente è eseguite teste cù ogni nova versione è esigenu teste per esse pigliate è riviste prima di registrazione. Quessi sò grandi prucessi chì ùn deve micca esse abbandunatu è sò stati un grande cambiamentu per parechje cumpagnie. Ma avà, per pruvà veramente u serviziu, aghju da tirà una versione di travagliu cumpleta di a mo applicazione. Ricurdativi di quellu novu ingegnere cù u cluster K8 di 150 servizii? Ebbè, avà avemu da insignà à u nostru sistema CI cumu per elevà tutti questi sistemi per verificà chì tuttu funziona veramente. Questu hè probabilmente troppu sforzu, cusì testeremu ogni parte in isolamentu: sò cunvinta chì e nostre specifiche sò abbastanza boni, l'API sò pulite, è un fallimentu di serviziu hè isolatu è ùn affetterà micca l'altri.

Tutti i cumprumessi anu una bona ragione. Diritta?

Ci hè parechje ragioni per passà à i microservizi. Aghju vistu questu fattu per una più grande flessibilità, per scaling teams, per rendiment, per furnisce una sustenibilità megliu. Ma in realtà, avemu investitu decennii in arnesi è pratiche per sviluppà monoliti chì cuntinueghjanu à evoluzione. U travagliu cù prufessiunali in diverse tecnulugia. Di solitu parlemu di scaling perchè si mette in i limiti di un unicu node di basa di dati Postgres. A maiò parte di e conversazioni sò circa scala di basa di dati.

Ma sò sempre interessatu à amparà nantu à a so architettura. In quale fase di a transizione à i microservizi sò? Hè interessante per vede più ingegneri chì dicenu chì sò felici cù a so applicazione monolitica. Parechje persone prufittàranu di i microservizi, è i benefici superanu i bumps in a strada di migrazione. Ma personalmente, per piacè dà a mo applicazione monolitica, un locu nantu à a spiaggia - è sò cumplettamente cuntentu.

Source: www.habr.com