четверг, 21 сентября 2017 г.

Мысли в слух

         Сегодняшний день в каком то смысле подвел черту под результатами моих трудов за последние 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 и тд.  Для более мелких компаний это как правило принесет только проблемы. 

Aerospike


        В последнее время мне пришлось довольно близко познакомится с внутренностями Aerospike. Большим открытием для меня стал тот факт что  специализированный SSD storage аероспайка не имеет собственного кэша. Так как этот сторадж работает напрямую с блочным устройством, то они также обходят кэш файловой системы.  Это означает что каждый GET запрос к персистентному namespace означает поход на SSD. Это конечно быстрее чем HDD, но все равно во много раз медленнее чем работа с памятью.  Исходя из этого я могу сделать вывод что Aerospike проектировался в первую очередь под write нагрузку либо под смешанную 50% write/50% read нагрузку. В таких случаях кэш как правило бесполезен, поэтому в AS его и нет.
             Но если вам нужен persistent сторадж с преимущественно read нагрузкой очень хорошо себя показал файловый сторадж аероспайка. В этом случае чтение идет с кэша файловой системы, что весьма позитивно сказывается на общей производительности Aerospike.
              Для тех кто хочет понять как работает Aerospike, я рекомендую к прочтению whitepaper Aerospike: Architecture of a Real-Time Operational DBMS