​​🐞 Потери при недоработках планирования. Часть 2.

Факап из прошлого поста не стоил карьеры людей, но переписывать систему пришлось.

На этот раз собрали функциональные и нефункциональные требования и пришли к выводу, что нужно отказаться от монолита на PHP и строить на базе сервисов на асинхронном языке. Специалистов на рынке было больше со знанием Javascript и вопреки моей большой любви к Java я не рискнул с Java NIO стартовать проект: был большой риск не уложиться в сроки и не найти специалистов из-за крайне малого опыта Java разработчиков на нашем рынке с асинхронным IO.

В этот раз с Сашей, TL этого проекта, мы стирали фломастеры об доски не один месяц (actually, 2). К сожалению где-то потерялась фотка нашей проектной документации, которая была засвидетельствована на стопке листов A4, с рукописным текстом и вырезанных и вклеенных куском логики с других листочков. Жаль конечно, выглядело как Франкенштейн или как лоскутное одеяло… кому как угодно)

На выходе получили систему, которая вот уже 4-5 лет в эксплуатации и переживала смену слоев, но не смену общей архитектуры. Decoupling в действии. Мы потратили на первом этапе несколько месяцев на планирование и устранили теоретические проблемы еще на старте, а вот окупилось это с лихвой, ибо выкидывание целых двух слоев приложения (двух сервисов) заняло 1 неделю ударной работы (вот ссылка на эту часть истории из выступления на конфе, fyi).

Конечно, не все так радужно было и столкнулись с другими проблемами, которые были вызваны наличием большого количества сервисов/микросервисов:
🔸 оркестрация доставляла неудобства, да и еще доставляет дискомфорт по сей день)
🔸 tracing/debugging становится сложным
🔸 service mesh на объемах становится большой головной болью!

Когда писали эти сервисы, то изобретали свои велосипеды для борьбы с этими проблемами. По итогу, потеряли десятки тысяч USD пока обучались работать с service mesh и оркестровать, трейсить и дебажить. Но это все равно меркнет на фоне архитектурных. У вас же есть возможность поучиться на наших ошибках...