Чини се да је врхунац хипе-а за микросервисе иза нас. Више не читамо постове неколико пута недељно „Како сам преместио свој монолит на 150 услуга.“ Сада чујем више здраворазумских мисли: „Не мрзим монолит, само ми је стало до ефикасности.“ Чак смо приметили неколико миграција са микросервиса назад на монолит. Када прелазите са једне велике апликације на више мањих услуга, мораћете да решите неколико нових проблема. Хајде да их наведемо што је краће могуће.

Поставка: од основне хемије до квантне механике

Постављање основне базе података и апликације са позадинским процесом био је прилично једноставан процес. Објављујем реадме на Гитхуб-у - и често у року од сат, највише неколико сати, све ради и почињем нови пројекат. Додавање и покретање кода, барем за почетно окружење, обавља се првог дана. Али ако се упустимо у микроуслуге, почетно време лансирања нагло расте. Да, сада имамо Доцкер са оркестрацијом и кластером К8 машина, али за програмера почетника све је ово много компликованије. За многе јуниоре ово је терет који је заиста непотребна компликација.

Систем није лако разумети

Хајде да се на тренутак фокусирамо на нашег јуниора. Код монолитних апликација, ако је дошло до грешке, било је лако пронаћи је и одмах прећи на отклањање грешака. Сада имамо услугу која разговара са другом услугом која нешто ставља у ред на магистрали порука која обрађује другу услугу—и онда долази до грешке. Морамо да спојимо све ове делове да бисмо на крају открили да Сервис А користи верзију 11, а Сервис Е већ чека верзију 12. Ово се веома разликује од мог стандардног консолидованог дневника: морам да користим интерактивни терминал/дебагер за ходање кроз процес корак по корак. Отклањање грешака и разумевање су сами по себи постали тежи.

Ако не може да се отклони грешке, можда ћемо их тестирати

Континуирана интеграција и континуирани развој сада постају уобичајени. Већина нових апликација које видим аутоматски креирају и покрећу тестове са сваким новим издањем и захтевају да се тестови полажу и прегледају пре регистрације. То су сјајни процеси од којих не треба одустати и који су представљали велики помак за многе компаније. Али сада, да бих заиста тестирао услугу, морам да подигнем пуну радну верзију своје апликације. Сећате се оног новог инжењера са К8 кластером од 150 услуга? Па, сада ћемо научити наш ЦИ систем како да покрене све ове системе да бисмо проверили да ли све заиста функционише. Ово је вероватно превише напора, па ћемо само тестирати сваки део изоловано: уверен сам да су наше спецификације довољно добре, АПИ-ји чисти, а грешка услуге је изолована и да неће утицати на друге.

Сви компромиси имају добар разлог. Јел тако?

Постоји много разлога за прелазак на микроуслуге. Видео сам да је ово урађено ради веће флексибилности, за скалирање тимова, ради перформанси, да би се обезбедила боља одрживост. Али у стварности, уложили смо деценије у алате и праксе за развој монолита који настављају да се развијају. Радим са професионалцима у различитим технологијама. Обично говоримо о скалирању јер они наилазе на границе једног Постгрес чвора базе података. Већина разговора је о скалирање базе података.

Али увек сам заинтересован за учење о њиховој архитектури. У којој се фази преласка на микроуслуге налазе? Занимљиво је видети више инжењера који кажу да су задовољни својом монолитном применом. Многи људи ће имати користи од микроуслуга, а користи ће надмашити проблеме на путу миграције. Али лично, молим вас да ми дате моју монолитну апликацију, место на плажи - и ја сам потпуно срећан.

Извор: ввв.хабр.цом