Рассмотрение приложения Porting от .NET до Erlang - нужен совет

Question

Я смотрю Erlang для будущей версии распределенного приложения для телефонии в режиме реального времени в режиме реального времени (то есть Erlang выглядит абсолютно идеальным выбором для такого типа приложение). Я исхожу из фона .NET, и текущая версия этого приложения использует комбинацию C#, WCF и JQuery для доставки службы. Теперь мне нужен Erlang, чтобы позволить мне добавить дополнительные 9 секунд к моему времени и позволить мне получить больше ударов за мои серверные баксы.

Раньше я настраивал процесс разработки, комбинируя VS.NET, GIT, TeamCity и автоматическое развертывание файлов MSI в различных средах, которые мы поддерживаем. Это не идеально, но нам все это довольно удобно. Мне интересно, подходит ли такой процесс, как у нас, для такого радикально отличного стека технологий (LYME)?

Я уверен, что все проблемы программирования, которые мы ранее разрешили с помощью .NET, могут быть лучше решены в меньшем количестве кода с помощью Erlang, поэтому я полностью продаюсь по выбору языка. То, что я еще не понял, прочитав книги Прагматика и О'Рейли в Erlang, заключается в том, как я должен адаптировать процессы управления программным обеспечением и процессом жизненного цикла приложений (ALM) в соответствии с новой платформой. Я вижу, что обновления кода на месте могли бы значительно облегчить мою жизнь (и моей команды тестирования и команды ops) (по сравнению с ужасными страданиями от попыток развернуть файлы MSI через сеть Windows), но я не уверен, как все должно измениться когда я использую Эрланг.

Как бы вы:

• сделать непрерывную интеграцию в Erlang (это он обычно используется?)
• использовать его в течение цикла QA (мы часто работаем одновременно тема филиалы с помощью GIT, которые получают свою собственную мини -QA цикл, так что все они получают развернуто в тестовой среде)
• строить и распространять свой код на DEV, ИСПЫТАНИЯ, ЕСХН, сценография и PROD среды
• интегрировать фазы генерации кода в сборки в цикле (в настоящее время мы используем MSBuild + T4)
• централизовать вход для связки различных серверов (в настоящее время мы используем log4net, MSMQ и т.д.)
• делать предупреждение с помощью инструментов, как SCOM
• определить, было ли кто-то/что-то неправильно настроены вашими производственных сервера
• позволяет производить горячий исправляет только после надлежащего контроля качества (только уполномоченный персонал)
• профиля производительности (вычисления и коммуникации) ваших приложений
• взаимодействует с активными серверами каталогов на базе Windows

Думаю, мне нужно знать, что сработало для вас и почему! Какие инструменты и рамки вы использовали? Что вы пробовали, что не удалось? Что бы вы сделали по-другому, если бы вы могли начать все сначала, зная, что вы знаете сейчас?

Answer 1

Whoa, какой длинный пост. Во-первых, вы должны знать, что 99,9% и более качественная помощь немного опасна для питья в то время как слепой. Да, вы можете получить некоторые потрясающие показатели стабильности, но вам нужно написать свою программу таким образом, чтобы это было облегчено. Это не бесплатно. Магия тоже не происходит. Ваше приложение должно быть спроектировано таким образом, чтобы восстанавливались другие подсистемы. OTP поможет вам многое - но это все еще требует времени, чтобы учиться.

Непрерывная интеграция: легко выполняется. Если вы можете позвонить rebar или make через ваш сборщик, вы, вероятно, уже здесь.Посмотрите на eunit, обложку и Erlang QuickCheck (мини-вариант бесплатно для стартеров) - все можно запустить с арматуры.

QA Cycle: у меня здесь не было никаких проблем. Опять же, если вы используете rebar, вы можете создавать встроенные релизы, которые минимизированы erlang vm, которые вы можете копировать в любом месте и запускать (они автономны). Вы даже можете быстро развернуть исправления для такой системы, слегка изменив путь кода, чтобы у вас было оверлей новых исправлений. Ваши варианты многочисленны. Гит уже много помогает тебе здесь.

Осаждение: Легко сделано.

Централизация регистрации: ознакомьтесь с SASL и error_logger. Вы можете делать все, что хотите.

Alerting: система может быть исследована для всего, что вам нужно (интроспекция сильна в Erlang). Но вам, возможно, придется немного закодировать, чтобы подключить его к выбранной вами системе.

Misconfiguration: Конфигурационные файлы являются условиями Erlang. Если это можно вычислить, это можно сделать.

Безопасность: Ограничение у кого есть доступ. На мой взгляд, это проблема людей, а не техническая.

Профилирование: cprof, cover, eprof, fprof, instrument + несколько распределенных систем для этого. Случайная выборка также проста (интроспекция сильна в Эрланге).

Windows взаимодействие: Dunno. (Смещение: в прошлый раз я использовал окна профессионально в 1998 году или около того).

Некоторые личные наблюдения:

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

Похоже, что у вас хорошо установленный и строгий процесс. Сколько этого процесса можно пожертвовать, чтобы уступить место новому виду мышления?

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

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