Yev Rachkovan
My perežyly 2 serjozni zminy v Scrimmage. My počynaly jak analityčnyj produkt dlja B2C, potim pereključylysja na WEB3-gru dlja zarobitku, a potim staly B2B SaaS-produktom. Pid čas peršogo perehodu veś naš kod buv zaarhivovanyj, i nam znadobylosja 5 misjaciv, ščob pidgotuvaty produkt do zapusku. Pid čas drugogo pivota my povtorno vykorystaly 90% kodovoї bazy, i nam znadobyvsja 1 misjać, ščob pidgotuvatysja. Jak startaper, vy viryte v te, ščo robyte, ale zminy nemynuči. Vy hočete stvoryty produkt, jakyj zmože legko adaptuvatysja do vymog rynku? Oś jak my ce zrobyly.
Stvorjujemo zdorovi ujavlennja pro abstrakciї
Meni znadobylosja 4 roky programuvannja, ščob navčytysja buduvaty zdorovi abstrakciї. Ideja poljagaje v tomu, ščob buty jakomoga menš konkretnym, nazyvajučy svoї zminni ta klasy, ščob vy mogly zastosovuvaty їh za riznyh obstavyn.
Napryklad, my stvorjuvaly gru z personažem-drakonom, jakyj može pidvyščuvaty riveń i vykonuvaty kvesty. Zamisť togo, ščob nazyvaty zminni “drakonamy”, my nazyvajemo їh “NFT”. Cja nevelyka zmina v imenuvanni zmusyť vas myslyty biľš abstraktno. Zamisť togo, ščob dumaty “Ščo možuť robyty drakony”, vy budete dumaty “Ščo može robyty NFT”. Teper vy možete legko povtorno vykorystovuvaty cej klas u vsih svoїh majbutnih proektah, jaki buduť vykorystovuvaty NFT.
Inšym pošyrenym prykladom je sproba vidokremyty arhitekturnu abstrakciju vid logiky konkretnogo dodatku. Jakščo vy budujete arhitekturu jak kodove rišennja abo prosto CI/CD, ne nazyvajte reči svoїmy imenamy, nazyvajte їh za pryznačennjam. Jakščo u vas je 10 mikroservisiv, vy možete zahotity stvoryty Docker-fajl i CI/CD-fajl dlja kožnogo z nyh, zamisť ćogo vy možete stvoryty arhitekturnu abstrakciju pid nazvoju “deployable”, jaka matyme realizaciju Docker-fajlu i CI/CD za zamovčuvannjam i vymagatyme vid mikroservisu lyše dekiľka vhidnyh zminnyh, takyh jak im’ja, port i zobražennja. K8S ne povynen znaty pro logiku vašogo dodatku.
Jakščo vy budete dotrymuvatysja pravyľnyh abstrakcij, vy zmožete vidkryty novyj sposib napysannja kodu – buduvaty mehanizmy, jaki možuť vyrišuvaty problemy, zamisť togo, ščob vyrišuvaty їh bezroseredńo.
My budujemo mehanizmy, jaki možuť vyrišuvaty problemy, zamisť togo, ščob vyrišuvaty їh bezroseredńo.
Cja ideja bazujeťsja na bažanni pidtrymuvaty vsi majbutni biznes-vymogy bez vnesennja zmin do kodu. Jakščo vy pomityly, ščo je fajl, jakyj duže často zminjujeťsja, nastav čas pobuduvaty mehanizm pidtrymky podaľšyh zmin bez zminy kodu.
Prykladom može sluguvaty te, jak my organizuvaly našu programu vynagorod. Ideja dodatku poljagala v tomu, ščo korystuvači možuť robyty stavky, a my dajemo їm tokeny za kožnu zroblenu stavku. Zamisť togo, ščob nazyvaty “stavku” “stavkoju”, my nazvaly її “vynagorodoju”. Zamisť togo, ščob žorstko koduvaty kiľkisť tokeniv dlja vynagorody za stavku, my realizuvaly mehanizm, jakyj dozvoljaje nam nalaštovuvaty vynagorodu za kožnu “vynagorodu” z bazy danyh. Teper my možemo narahovuvaty tokeny za buď-ščo, ne zminjujučy žodnogo rjadka kodu.
Šče odyn jaskravyj pryklad: my hotily zbiľšyty vynagorodu korystuvačam, koly vony vygrajuť stavku. Zamisť togo, ščob pysaty kod na kštalt “Jakščo stavka prynosyť vynagorodu i jakščo cja stavka maje status VYGRAŠ, pomnožyty vynagorodu na 2”, my vprovadyly mehaniku “modyfikaciї”. Modyfikaciї dozvoljajuť nam zminjuvaty vynagorodu na osnovi poperedńo vyznačenyh fiľtriv. Vy vkazujete fiľtry v bazi danyh, i cej fiľtr bude avtomatyčno zastosovuvatysja do kožnoї nagorody. Napryklad, u nas je fiľtr “Koly typ vynagorody – stavka, a pole REZUĽTAT maje značennja VYGRAŠ, pomnožyty vynagorodu na 2”. Zavtra pryjde klijent i poprosyť zbiľšyty vynagorodu za prograš. My možemo zrobyty ce z bazy danyh, zminyvšy 0 rjadkiv kodu.
Cej kod prosto bezcinnyj i može buty vykorystanyj miľjonamy sposobiv dlja pidtrymky miľjardiv variantiv vykorystannja. Takyj kod zajmaje biľše času na napysannja, ale vy vytratyte nabagato menše času na jogo pidtrymku.
Jakščo vy budujete zdorovi abstrakciї i vykorystovujete їh dlja stvorennja uzagaľnenyh mehanizmiv, vy možete podumaty pro te, ščob vynesty dejaki mehanizmy v okremi mikroservisy, jaki ničogo ne znajuť pro reštu systemy.
My stvorjujemo mikroservisy z vidkrytym vyhidnym kodom
Ujaviť, ščo vaš mikroservis vykorystovuvatymuť tysjači inšyh rozrobnykiv v absoljutno ne pov’jazanyh z vašym proektah. Cja ideja zmušuje vas pereosmyslyty zaležnisť vašyh mikroservisiv odyn vid odnogo. Ce vberigaje naš kod vid žahu zaležnostej i robyť jogo prydatnym dlja povtornogo vykorystannja u vsih majbutnih proektah i povorotnyh momentah.
Prykladom može sluguvaty mehanizm planuvannja, jakyj my realizuvaly. My zapustyly naš dodatok jak okremyj dodatok iz cronjobs, jaki zapuskajuťsja z kodu. Problema v tomu, ščo my ne možemo masštabuvaty cej servis goryzontaľno, tomu nam dovelosja vidokremyty logiku planuvannja deinde. Zamisť togo, ščob nalaštovuvaty cronjob za dopomogoju kodu, my vprovadžuvaly i postijno dodavaly do nyh novi značennja, my realizuvaly K8S-Scheduler, jakyj je kerovanoju diagramoju, ščo rozgortajeťsja v našomu klasteri. Cja diagrama skanuje vsi naši mikroservisy na najavnisť vyznačeń cronjob i vykonuje їh za dopomogoju vyklykiv API. Teper my možemo opysaty cronjob pid čas stvorennja novogo endpoint, i todi Scheduler počne planuvaty jogo, ne vtručajučyś u kod.
Nastupnyj pryklad – autentyfikacija korystuvača za dopomogoju JWT. Zamisť togo, ščob zrobyty її častynoju odnogo z našyh mikroservisiv, my zrobyly її okremym mikroservisom, jakyj avtentyfikuje korystuvačiv i povertaje token JWT, jakyj možna zastosuvaty u vsih inšyh mikroservisah. Teper cej mikroservis možna povtorno vykorystovuvaty na buď-jakomu majbutńomu pivoti abo proekti, vykonavšy jedynu komandu dlja jogo rozgortannja.
Jakščo vy budete dotrymuvatysja ćogo pryncypu, čerez 2 roky u vas bude biblioteka z 10 mikroservisiv, jaki možna vykorystovuvaty dlja stvorennja buď-jakogo produktu, pov’jazanogo z vašoju dijaľnistju, za ličeni dni. Teper u vas je konstruktor produktiv, jakyj dozvoljaje stvorjuvaty їh, vykorystovujučy lyše konfiguraciї.
My stvorjujemo konstruktory produktiv zamisť produktiv
Vy možete nazvaty ce nadmirnoju konfiguracijeju, ale my nazyvajemo ce arhitekturoju. Teper, koly vy zrozumily, ščo vaš produkt ne vidpovidaje vymogam rynku, vy možete švydko perenalaštuvaty jogo, zminyvšy paru zminnyh u vašij bazi danyh i rozgornuvšy dejaki z vašyh mynulyh mikroservisiv u novomu klasteri. Odnak keruvaty vsima cymy mikroservisamy može buty skladno.
Terraform dobre dopomagaje nam u ćomu pytanni. Vona nadaje nam arhitekturnu abstrakciju, jaka dozvoljaje nam dyvytysja na infrastrukturu jak na kod, jakyj možna legko modyfikuvaty, zacykljuvaty ta konfiguruvaty. Jakščo vam potribna jakaś nova funkcionaľnisť, jakoї u vas šče nemaje, vy vže majete čitkyj interfejs, ščob stvorjuvaty її i dodavaty do teraformy, jaka ob’jednaje її z usima inšymy mikroservisamy. Vin avtomatyčno dodasť do ńogo avtoryzaciju, ščo zrobyť jogo dostupnym dlja ogljadu, rozgortannja ta planuvannja. Vin takož peredasť vsi neobhidni zminni seredovyšča i rozmistyť jogo u vidkrytomu dostupi.
Pidsumky
My vprovadyly systemu, jaka dozvoljaje nam rozrobljaty programne zabezpečennja za dopomogoju konfiguracij. Ce maje buty kincevoju metoju kožnogo IT-produktu, jakyj hoče maty možlyvisť utrymuvaty desjatky inženeriv pid svoїm dahom i perežyty majbutni kardynaľni zminy.
Ne kožne programne zabezpečennja potrebuje takogo pidhodu. Inodi vy hočete stvoryty švydkyj prototyp, jakyj protestuje rynok. Ale važlyvo vidriznjaty ” syryj” prototyp vid MVP, u jakogo poperedu dovge žyttja, spovnene zmin ta vymog.