Изглежда, пикът на хипа по микроуслугите е зад нас. Вече не четем по няколко пъти на седмица постове "Как пренесох монолита си в 150 услуги". Сега по-често чувам разумни мисли: "Не мразя монолита, просто се грижа за ефективността". Дори наблюдавахме няколко миграции от микроуслуги обратно към монолита. При прехода от едно голямо приложение към няколко по-малки услуги ще трябва да решите няколко нови проблеми. Нека изброим тях максимално кратко.

Настройка: от основна химия до квантова механика

Настройването на основна база данни и приложение с фонова задача беше сравнително ясен процес. Публикувам readme в Github — и често след един час, максимум за няколко часа, всичко работи и започвам нов проект. Добавянето и стартирането на кода, поне за началната среда, става в първия ден. Но ако сме се осмелили на микроуслуги, времето за първоначално стартиране скача до небето. Да, сега имаме Docker с оркестрация и кластер от машини K8, но за начинаещ програмист всичко това е много по-сложно. За много джуниори това е бреме, което наистина представлява ненужна сложност.

Системата не е лесна за разбиране

На минутка да спрем на нашия джуниор. С монолитни приложения при възникване на грешка беше лесно да се проследи и веднага да се премине към отстраняване на грешки. Сега имаме услуга, която общува с друга услуга, която поставя нещо в опашка на шина за съобщения, която обработва друга услуга — и там възниква грешка. Трябва да съберем всички тези части, за да разберем в крайна сметка, че услуга А работи с версия 11, а услуга Е вече очаква версия 12. Това е коренно различно от стандартния ми консолидиран журнал: трябва да използваме интерактивен терминал/отладчик, за да преминем през процеса стъпка по стъпка. Отстраняването на грешки и разбирането по същество стана по-сложно.

Ако не може да се отстрани грешка, може би ще ги тестваме

Непрекъснатата интеграция и непрекъснатото развитие стават все по-разпространени. Повечето нови приложения, които виждам, автоматично създават и стартират тестове с всяко ново издание и изискват тестовете да преминат и да бъдат прегледани преди регистрацията. Това са страхотни процеси, от които не можем да се откажем, те представляват значителна промяна за много компании. Но сега, за да проверя истински услугата, трябва да вдигна пълната работна версия на приложението си. Помните ли новия инженер с клъстера K8 от 150 услуги? Ами, сега ще научим нашата CI система как да вдигне всичките тези системи, за да проверим, че всичко наистина работи. Вероятно е твърде много усилия, така че просто ще тестваме всяка част изолирано: сигурен съм, че нашите спецификации са достатъчно добри, API е чист, а отказът на услугата е изолиран и няма да влияе на другите.

Всички компромиси имат основателна причина. Нали?

Има много причини за преминаването към микросервизи. Видях, че го правят за по-голяма гъвкавост, за мащабиране на екипи, за производителност, за да осигурят по-добра устойчивост на работата. Но в действителност сме вложили десетилетия в инструменти и практики за разработване на монолити, които продължават да се развиват. Работя с професионалисти в различни технологии. Обикновено говорим за мащабиране, защото те се сблъскват с ограниченията на един узел на базата данни Postgres. По-голямата част от разговорите се посвещават на мащабирането на БД.

Но винаги съм заинтересован да науча за тяхната архитектура. На какъв етап от преминаването към микросервизи се намират. Интересно е да наблюдавам, че все повече инженери казват, че са доволни от монолитното си приложение. На много от тях микросервизите ще донесат ползи, а предимствата ще превъзхождат препятствията по пътя на миграцията. Но лично на мен моля, дайте ми моето монолитно приложение, място на плажа – и аз съм напълно щастлив.

Източник: habr.com