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

В какой-то момент руководитель группы спросил его:

Итак, как вы думаете, когда мы полностью перейдем на Oracle?

В этот момент у меня немного повысилось давление. Мы работаем на Sybase IQ. Переносим все на Oracle… Как мы собираемся перестроить остальную часть приложения, чтобы справиться со всеми проблемами производительности и т. д.

К счастью, ответ Питера был очень коротким и точным:

Никогда

Как я уже сказал, это произошло несколько лет назад, и в современном мире неоднородность распределенных систем находится на другом уровне. Тогда мы имели дело в основном с трехуровневыми приложениями, и выбор между технологиями был на трех уровнях:

  1. База данных — часто зависит от того, какие лицензии были приобретены, но с технической точки зрения разница между Oracle 8 и MS SQL Sever 2008 незначительна. IQ или КДБ.
  2. Средний уровень — выбор тогда был действительно между технологиями Java или Microsoft. Руководствуясь имеющимся набором навыков в компании и на рынке. У вас были бы ребята, утверждающие, что Java является открытым исходным кодом, и поэтому ему нельзя доверять так сильно, как .Net, или что множество библиотек для Java сделало его гораздо более привлекательным соперником.
  3. Внешний интерфейс — веб-клиент или собственный клиент? Да, тогда это все еще был выбор, который многие рассматривали: должны ли мы создавать приложение с помощью Swing? Или, может быть, даже изначально на C++, поскольку вся наша пользовательская база использует Windows XP (если мы говорим о внутреннем продукте, то есть). В наши дни выбор сузился до веб-интерфейса, но технологии, доступные в этой области, резко возросли с точки зрения количества и сложности.

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

Простые истории можно быстро реализовать с помощью Python или JavaScript (NodeJS). Они также отлично подходят для прототипирования, когда вам нужно быстро предоставить несовершенное решение, чтобы получить отзывы от пользователей/клиентов. Когда вы имеете дело с более сложной проблемой, например, проталкиваете несколько терабайт данных через конвейер обработки, Scala, вероятно, является самым привлекательным из доступных инструментов.

Но не единственный. Другой подход, если он находится в рамках ваших ограничений, — это правильная среда. Для сложной задачи обработки данных вы можете использовать Google DataFlow SDK с его конвейерами и преобразованиями. Это избавляет от необходимости поддерживать сложный стек технологий (например, Spark) и позволяет вам сосредоточиться на решении реальной проблемы.

Я продолжаю видеть посты или статьи о том, как одна технология развивается, а другая деградирует. Например: NodeJS: теперь, когда вы можете запустить его на сервере, вы должны использовать JavaScript везде! Да и когда единственный инструмент у тебя молоток, то все проблемы появляются как гвозди.

Недавно я принял решение переписать большую часть программного обеспечения, созданного с помощью NodeJS и работающего на периферийных устройствах с C/C++. Раньше это работало нормально, потому что устройства, которые мы использовали до сих пор, имели процессоры Intel I5 или I7. Когда мы развернули это на Atom, оказалось, что JavaScript как интерпретируемый язык — не самая оптимальная идея.

Я думаю, что это технологическое разнообразие является благословением. Это позволяет нам создавать более интеллектуальные и оптимальные решения для клиентов. На мой взгляд, крайне важно не замыкаться в себе от разнообразия технологий.