Monolit sistemlərin qurulmasının 3 səbəbi

Bəli, məqsəd üçün nəzərdə tuturam.

Bu günlərdə monolit bir memarlıq tövsiyə etmək bir atəş üçün qan tökülməsini təyin etmək kimi bir az səslənir, amma məni eşit. Uzun müddətli, genişlənə bilən, xidmət qabiliyyətli, çevik və digər müsbət cəhətləri (ağıl da daxil olmaqla) təmin etmək üçün tətbiqinizi bir microservices arxitekturasında inkişaf etdirmək və yerləşdirmək istəyəcəksiniz. Ancaq yeni bir proqram qurursanız, şirkətiniz və inkişaf qrupunuz bir sistemin sadə xidmətlərə parçalanması ilə əlaqəli istehzalı mürəkkəbliyə hələ hazır olmaya bilər. Bazar üçün sürət və vaxt zərifliyi ləkələyə bilər ... və yaxşıdır!

Monolit bir sistem qurmağın ilk səbəbi bilinməyənlərə kömək etməkdir. Mikroservislərə başlamağınızla əlaqədar hər hansı bir kitab və ya məqalə götürün və sistemin komponent xidmətlərinə parçalanması prosesini təsvir edəcəkdir. Ancaq yeni başlamısınızsa, hələ parçalanacaq bir sisteminiz yoxdur. Sistemdə ümumiyyətlə nə tələb etdiyinizi müəyyənləşdirmək olduqca çətin ola bilər, bu tələbləri yaxşı müəyyənləşdirilmiş interfeyslərlə boş birləşdirilmiş xidmətlər toplusuna ayırmaq və sındırmaq daha azdır. Tipik bir başlanğıcda bilinməyənlərin səviyyəsi ilə bu analizin hətta sağa yaxın olma ehtimalı çox azdır.

Çevik üslub metodologiyalarının artmasının əsas istiqaməti tələblərin artan yerlərdə aşkar edilməsinə imkan verməkdir, çünki hər şeyi əvvəlcədən bilmək demək mümkün deyil. Eynilə, maddi bir buraxılış və ya iki əliniz olduqda bir sistemin komponent xidmətlərini ayırd etmək daha asandır. Beləliklə, əvvəlcə, yalnız başlayın! Doğru etdiyinizdən narahat olmayaraq ilkin sistemi qurun ... bu mərhələdə "doğru" yoxdur. Sənət, çoxlu sayda texniki borc toplamadan əvvəl, funksionallığa davam etməklə sisin təmizlənməsi kimi müəyyən xidmətləri ayırmaq arasında tarazlıq tapmaqdadır. Düşüncə və niyyət ilə yaxınlaşan memarlığa bu tədricən yanaşma, heç nəyi bilmədən əvvəl onu əldə etməyə çalışmaqdan daha sürətli və daha uğurlu olacaqdır.

Monolit bir memarlığı nəzərdən keçirməyin ikinci bir səbəbi, komanda hazır deyilsə. Sistem kifayət qədər yaxşı müəyyənləşdirilmiş olsa belə, bir sistemin komponent xidmətlərinə bölünməsi həmişə düz deyil. Əldən çıxmış bir nəhəng java işinin (hər sistemin birində) olmasını riskə atmağa dəyərmi? Bir xidməti nəzərdən keçirərkən, kiçik nə qədər kiçikdir? Normal tövsiyə, xidmətin yalnız məntiqi bir şey etməyincə davam etməsi lazım olsa da, yüksək sürətdə, böyük məlumat dünyasında, məsələn, çox kiçik olsa da ciddi performans təsirləri göstərə bilər.

Əsas məqam odur ki, hər zaman fikirləşməli olan işlər var və komandanın bu qərarları müvəffəqiyyətlə balanslaşdırması üçün düzgün bacarıq tələb olunur. Komandanız mikroservislər üçün yenidirsə, təlim üçün vəsait ayırmaq, komandanın kəşf etməsi üçün vaxtında və bəlkə də qarışıqda yeni bacarıqların işə götürülməsi mənada düzgündür. Bir neçə şirkət yenidən inkişaf etdirmək üçün inkişafı dayandıra biləcəyi üçün, güman ki, bu vaxt ənənəvi təcrübələrindən istifadə edərək bina qurmağa davam etməlidirlər. Bu sonradan bir az iş görməyiniz lazım olsa da, komandanın tamamilə hazırlıqsız irəli getməsindən daha yaxşı nəticə əldə edəcəksiniz. İnanın mənə, təhsili olmayan, erkən versiyalı mikroservis cəhdlərində də çox iş var.

Nəhayət, bir monolit sistem sizin bazara ən sürətli yolunuz ola bilər və bir çox hallarda bu sürət mükəmməl memarlıqdan daha vacibdir. Bir çox şirkət, xüsusən məhdud maliyyə ilə işləyən startaplar üçün satışa çıxmaq yaşamaq üçün vacibdir. Mikroservislər nəticədə həyatı daha da asanlaşdırsa da, bu rahatlıq daha çox ödəməyə ehtiyac duyduğunuz bir qabaqcıl xərc ilə gəlir. Yaxşı bir mikroservis memarlığı zərif sadədir, lakin asan, sürətli və ya təsadüfi deyil. Bu gün orada bir çox böyük, yetkin, genişmiqyaslı mikroservis nümunələri var - Twitter, Amazon, Spotify, LinkedIn - lakin bunların hamısının monolit tətbiq kimi başlamış və sonradan inkişaf etmiş bir səbəbi var. Heç vaxt texniki mükəmməlliyə can atmaq, iş uğur qazanmağa imkan verməyin. Praqmatik arxitektura o deməkdir ki, texnologiya seçimləri digər tərəfdən deyil, biznes ehtiyaclarını dəstəkləməlidir.

Sözsüz getməli olsa da, bu ssenarilərin hər birinin əksinə olması monolit memarlıq qurmamaq üçün böyük bir səbəbdir. Tətbiqiniz artıq kifayət qədər yaxşı müəyyənləşdirilibsə, komandanız mikroservislərdə təcrübəlidir və şirkətinizin inkişaf dövrlərinə sərf etmək üçün vaxtı və pulu var, onda mütləq bir mikro servis xidmətləri memarlığına investisiya qoymalısınız. Bu yolun uzunmüddətli faydaları məlumdur və bu nöqtədə yaxşı sənədləşdirilmişdir. Ancaq hələ orada deyilsinizsə, yaxşıdır. Mövcud vəziyyətinizi etiraf edin, yolunuzu planlaşdırın və niyyətlə təkrarlayın - yenə də vəziyyətinizi düzəldəcəksiniz və vaxt keçdikcə işinizin tələb etdiyi hər bir şeyi davam etdirməyə hazır olan texnoloji danışıqlara layiq bir arxitektura ilə başa çatacaqsınız.

Daha zəhmli məzmun üçün buraya baxın