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

Инсталация: от базова химия към квантова механика

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

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

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

Ако не може да се отстрани проблема, вероятно ще ги тестваме.

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

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

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

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

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