Типичная ситуация. Программист читает книжку о новом, или не таком уж и новом, языке программирования, базе данных или иной технологии и сгорает от нетерпения поскорее ее попробовать. Возможно, он узнает о технологии или подходе не из книги, а из подкаста или доклада на конференции, не суть важно. Другая похожая ситуация — «в нашем проекте все очень плохо, потому что мы используем DynamoDB (пишем на Java), давайте все перенесем на PostgreSQL (перепишем на Erlang)». В этой заметке я собрал веские причины не поддаваться соблазну протащить новые игрушки в продакшн.

1. Почти всегда внедрение новой технологии или переход с одной на другую — задача очень непростая и ресурсоемкая. Ваши эстимейты о том, что это якобы займет месяц или два, неверны, потому что вы не учитываете необходимость поддерживать и развивать то, что уже есть сейчас, миграцию данных, необходимость поправить десятки, если не сотни, багов, которые выявятся после перехода, и так далее. Вы должны быть абсолютно уверены, что у вас фичфриз (не только на словах!) и прямо сейчас нет более приоритетных задач. А такое бывает крайне редко.
2. Технология редко оказывается настоящим источником проблемы. Почти всегда дело в людях, не разобравшихся, как эту технологию правильно применять. Если отовсюду лезут баги, попробуйте уже наконец начать писать тесты. Если все тормозит, сядьте и обдумайте как следует оптимизацию , заведите кэши, и так далее. Если хоститься в Amazon слишком дорого, оптимизируйте расходы. За один рабочий день можно легко сократить стоимость размещения сервиса в AWS на 25-50%, практически ничего при этом не потеряв, проверено!
3. Любая технология имеет слабые и сильные стороны. Скорее всего, сейчас вы сосредоточены только на сильных. MongoDB может очень круто скейлиться, но насколько это реально удобно жить без схемы БД, транзакций и вьюх? Сегодня мы видим появление большого количества «убийц C/C++», таких же быстрых, но еще и безопасных. Допустим, есть массив из 1000 объектов. Для безопасности при инициализации массива нужно вызвать 1000 конструкторов, а при обращении к элементам массива проверять, не вышли ли мы за его пределы. Либо скорость, либо безопасность. Что выбрали в Rust , он безопасный или быстрый? Всегда приходится делать какой-то компромисс.
4. У любой технологии помимо явных минусов всегда есть еще свои «тонкости и нюансы». При переходе на новую базу данных, язык, фреймворк или методологию вы соберете все-все-все грабли и баги. Невероятно, но в компиляторе вашего нового любимого языка программирования баги тоже есть ! Помимо багов бывают и другие проблемы, например, сломанная обратная совместимость в новых релизах. Если речь о базе данных, тогда вы можете потерять данные при нетсплитах. Если об облачном хостинге, вы можете столкнуться с проблемой шумных соседей. То есть, помимо теории, речь о которой шла в предыдущем пункте, есть еще и практика. Будьте ко всему этому морально готовы.
5. Инструментарий. Можно долго хаять C/C++, что писать на нем не безопасно, но за годы существования у языка появились IDE, отладчики , статические анализаторы кода и другие стабильные, проверенные временем инструменты разработки, решающие очень многие практические проблемы. У Rust и Haskell до сих пор нет нормальных IDE. Если брать фреймворки, то Play Framework , к примеру, поддерживается существующими IDE тоже из рук вон плохо. Возможно, вам и в Vim неплохо пишется, но разделяют ли ваш энтузиазм в этом вопросе ваши коллеги и люди, приходящие на собеседования?
6. Библиотеки. Если речь о базе данных, для каких языков у нее есть клиенты и насколько они хороши? Если речь о языке, есть ли у него AWS SDK? Как на этом языке нарисовать диаграмму? Как построить отчет в Excel или PDF? Очень во многих современных проектах есть потребность строить какие-то отчеты и эти вопросы возникают очень быстро. Биндинги не решают проблему , так как зачастую они плохо взаимодействуют с рантаймом языка (особенно если это язык с легковесными процессами, как Erlang или Go), покрывают малую часть возможностей библиотеки, завязаны на старую версию оригинальной библиотеки, просто сломаны (так было с биндингами к GD для Haskell, когда я последний раз их смотрел), очень плохо документированы (попробуйте поработать с OpenGL на Haskell ) и так далее. Недаром ведь в C++ предусмотрена возможность вызывать сишный код напрямую, а в языке Scala — код, написанный на Java.
7. Зоопарк технологий создает проблемы, как бы вам не хотелось верить в обратное. Казалось бы, риски минимальные, если вы все построили на микросервисах . Но написанные на разных языках микросервисы взаимодействуют друг с другом, а значит для каждого микросервиса нужно поддерживать несколько версий клиента на разных языках. Если вы думаете, что написали очень маленький скрипт или сервис, и его не нужно «поддерживать», так как в случае чего проще выкинуть и написать с нуля, то тоже ошибаетесь. В случае с сервисом потребуется миграция данных и бесшовное переключение. Маленькие скрипты постепенно дописываются, в результате чего разрастаются и их становится не так уж просто переписать. К тому же, даже в маленьких скриптах исправляются десятки багов, и выкидывать проверенный временем, стабильный код — это большой риск.
8. Размер сообщества имеет значение. Вокруг новых технологий это сообщество, как правило, довольно невелико. Если вы столкнетесь со сложной проблемой, то где будете просить помощи? Написаны ли уже книги и документация, с которыми смогут ознакомиться ваши коллеги? Не забывайте, что все возникающие проблемы вам придется решать в условиях авралов и дэдлайнов.
9. Велика вероятность, что вы решаете новым модным инструментом не ту задачу. У многих компаний не такой уж highload для использования NoSQL решений. Обычный PostgreSQL с репликами и, возможно, небольшим ручным шардированием, решит задачу куда лучше, чем этот ваш Riak. Также во многих компаниях не такой уж big data, чтобы использовать Hadoop. Если речь идет о нескольких терабайтах данных в месяц, их будет намного быстрее обработать безо всяких там Hadoop . Кроме того, если сейчас вы пишите вебчик на Scala, то нет смысла переписывать все на Rust или Go, так как эти языки, скорее всего, просто не дадут вам существенных преимуществ. Что-то будет лучше, а что-то намного хуже.
10. Где вы будете искать программистов с опытом этого вашего модного Swift или Clojure? Если сейчас вы протащите Cassandra в продакшн и уйдете из проекта, кто потом сможет это поддерживать? И кому, собственно, вы такой классный будете нужны со знанием этих странных и никому не нужных технологий? Не лучше ли инвестировать свое время в что-то более распространенное на практике?

В общем и целом, перед протаскиванием новой технологии всегда нужно проявлять осторожность, иначе можно на ровном месте создать самому себе кучу проблем. Сомневайтесь во всем, что вам говорят евангелисты. Не стесняйтесь (вежливо и без троллфейса!) задавать им неудобные вопросы вроде тех, что были приведенны выше. В случая с языками хорошим признаком является возможность вызывать код на Си или Java напрямую, без биндингов. Еще более хороший признак, если язык транслируется в C/C++ или Java. Это означает, что создатели языка подумали о минимизации рисков, а не то, что они не осилили православный LLVM. Скорее всего 🙂

Подождите лет пять, пока с технологией не поиграются другие и не соберут все-все-все грабли. Если после этого появятся саксесс сторис, возможно, технология действительно чем-то интересна. После этого поиграйтесь еще немного в своих пет проджектах, затем на некритичных проектах на работе (например, в админке или интеграционных тестах). Если все хорошо, то можно постепенно, маленькими шажками, попробовать применить технологию уже там, где ходят пользователи.

Дополнение: В продолжение темы — Критика языка Rust и почему C/C++ никогда не умрет и Почему эти ваши модные NoSQL решения не так уж хороши .