Сегодняшний день в каком то смысле подвел черту под результатами моих трудов за последние 4 года. И заставил о многом задуматься. Попробую поделиться своими выводами без указания деталей, дабы не нарушить NDA.
Первое что я осознал: done better than perfect. Быстро сделать работающее решение(пусть на костылях, пусть из говна и палок) - это гораздо лучше чем потратить в 10 раз больше времени на решение которое экономит один round-trip или пересылает на 10 мегабайт меньше данных. Почему - потому что это экономит тебе время. Обычно когда сравнивают различные решения то учитывают миллисекунды и мегабайты, но не учитывают время потраченное на реализацию этого решения. Оглядываясь назад могу сказать что я в какие-то моменты был идеалистом и пытался все сделать сразу идеально. И закапывал в это кучу времени. Теперь вот каюсь в этом.
Второе - keep it fucking simple. Воистину блять. Вот только это и хочется здесь добавить. Это выражение - как buzz word, его повторяют к месту и не к месту. Но осознание этого приходит только с опытом. Когда мы сравниваем различные решения - мы зачастую забываем об еще одном очень важном критерии - сложности. И выбираем решения которые гораздо более сложные. Просто потому что они красивее. Делай просто - и будет заебись. Все, именно так. К тому же наверняка и быстрее еще получится. Да, об этом решение скорее всего не расскажешь на конференции, да и друзьям в курилке не расскажешь. Зато работает, зато быстро. Чем больше в системе движущихся частей - тем больше вероятность что одно из них сломается.
Отдельно хочется сказать про микросервисную архитектуру. Будь проклят тот день когда этот buzz word пришел в Лазаду. Про нее толко на конференциях хорошо рассказывать, но в практическом плане - это просто ад. Все те мечтатели которые ее нахваливают - как правило просто получают удовольствие от ее реализации, они кайфуют от возрастающей сложности системы. Им важен процесс а не результат. Хотя они думают что приносят пользу - это не так. А если кто-то вам начнет расхваливать - FaaS(function as a service) - увольте его немедленно. После 2-х лет эксплуатации микросервисной архитектуры в продакшене могу твердо сказать - в 99% она вам не нужна. Я уверен что те проблемы который вы с помощью нее собираетесь решить - можно решить гораздо проще. И я еще более уверен что когда вы принимаете решение о переходе на микросервисную архитектуру - вы не осознаете всех тем проблем которые вы сами себе этим создаете. Особенно проблем вне продакшена - в организации разработки, в организации dev environment, QA и релизного процесса.
Мой опыт подсказывает мне что организационная структура отдела разработки очень сильно связана с архитектурой разрабатываемого приложения. Многие будут говорить - что за чушь, такого не может быть. Но на самом деле связь между организационной структурой и структурой приложения очень важна. Если нет четкого соответствия между компонентами архитектуры и командами - начинается бардак. Я не говорю что это должна быть связь 1:1, но эта связь определенно должна быть. Итак если вернуться к вопросу о том нужна ли микроархитектура и насколько она должна быть микро - я бы сказал так:
- если у вас меньше чем 10-15 программистов в отделе разработки - забудьте про микросервисы. Они вам просто не нужны. Монилит - ваш выбор.
- если команда выростает до 100 человек, то с монолитом работать будет уже не удобно. Можно попробовать разобрать монолит на несколько приложений, каждое из которых разрабатывается отдельной командой.
- только если ваша команда выросла до 200-300 человек - можно подумать о микросервисной архитектуре. Но опять же - степень ее микросервисности должен быть пропорционален численности отдела разработки.
Отсюда вывод - микросервисы отлично работают в компаниях масштаба Netflix, Ebay, Paypal и тд. Для более мелких компаний это как правило принесет только проблемы.
