Considerar Porting App de .NET a Erlang - necesito consejo

Question

Estoy buscando en Erlang una versión futura de una aplicación distribuida de telefonía web alojada en tiempo real (es decir, Erlang parece ser la elección perfecta para este tipo de aplicación). Vengo de un fondo .NET y la versión actual de esta aplicación usa una combinación de C#, WCF y JQuery para entregar el servicio. Ahora necesito Erlang para permitirme agregar 9s extra a mi tiempo de actividad y permitirme obtener más por mis dólares de servidor.

Anteriormente, establecía un proceso de desarrollo combinando VS.NET, GIT, TeamCity y la implementación automática de archivos MSI en los diversos entornos que mantenemos. No es perfecto, pero ahora todos estamos bastante cómodos con eso. Me pregunto si un proceso como el que tenemos es incluso apropiado para una pila de tecnología tan radicalmente diferente (LYME).

Estoy seguro de que todos los desafíos de programación que resolvimos anteriormente con .NET se pueden resolver mejor con menos código con Erlang, por lo que estoy totalmente convencido de la elección del idioma. Lo que aún no entiendo al leer los libros de Pragmatic y O'Reilly en Erlang, es cómo debo adaptar los procesos de ingeniería de software y gestión de ciclo de vida de la aplicación (ALM) para adaptarme a la nueva plataforma. Veo que las actualizaciones de código in situ podrían hacer que mi vida (y la de mi equipo de pruebas y operaciones) sea mucho más fácil (en comparación con la espantosa desgracia de intentar implementar archivos MSI en una red de Windows) pero no estoy seguro de cómo deberían cambiar las cosas. cuando uso Erlang

Cómo haría usted:

• hacer la integración continua en Erlang (es comúnmente utilizado?)
• utilizarlo durante un ciclo de control de calidad (a menudo corremos ramas puntuales concurrentes utilizando GIT, que obtienen su propio mini qa ciclo, por lo que todos ellos se despliegan en un entorno de prueba)
• construir y distribuir el código para DEV, pRUEBA, UAT, puesta en escena y entornos PROD
• integrar fases de generación de código en su ciclo de acumulación (actualmente utilizamos MSBUILD + Plantillas T4)
• centralizar el registro para un montón de diferentes servidores (actualmente utilizamos Log4net, MSMQ, etc.)
• qué alertar con herramientas como SCOM
• determinar si alguien/algo ha configurado correctamente los servidores de producción
• permiten una producción hot-fixes sólo después de QA adecuada (sólo por personal autorizado)
• perfilar el rendimiento (computación y la comunicación) de sus aplicaciones
• interactúan con los servidores de directorio activo con sistema operativo windows

¡Creo que necesito saber qué funcionó para usted y por qué! ¿Qué herramientas y marcos usaste? ¿Qué intentaste que falló? ¿Qué harías diferente si pudieras comenzar de nuevo, sabiendo lo que sabes ahora?

Answer 1

Whoa, qué larga publicación. En primer lugar, debe tener en cuenta que el 99.9% y una mejor co-ayuda es un poco peligroso beber mientras está ciego. Sí, puedes obtener algunas cifras asombrosas de estabilidad, pero necesitas escribir tu programa de una manera que facilite esto. No viene gratis No sucede por arte de magia tampoco. Su aplicación debe diseñarse de manera tal que otros subsistemas se recuperen. OTP te ayudará mucho, pero aún lleva tiempo aprender.

Integración continua: fácil de hacer. Si puede llamar al rebar o make a través de su build-bot, probablemente ya esté aquí.Mire eunit, cover y Erlang QuickCheck (la mini variante es gratuita para los principiantes): todos pueden ejecutarse desde la barra de refuerzo.

QA Ciclo: No he tenido ningún problema aquí. Nuevamente, si usa rebar, puede crear lanzamientos incrustados que se minimizan. Vler de erlang puede copiar en cualquier lugar y ejecutar (son autónomos). Incluso puede implementar arreglos en caliente fácilmente en un sistema de este tipo alterando la ruta del código un poco para que tenga una superposición de correcciones más recientes. Tus opciones son numerosas Git ya te ayuda mucho aquí.

Ecologización: Fácil de hacer.

Centralización del registro: busque en SASL y el error_logger. Puedes hacer lo que quieras aquí.

Alerta: El sistema puede ser probado para todo lo que necesita (la introspección es fuerte en Erlang). Pero es posible que deba codificar un poco para conectarlo al sistema de su elección.

Configuración incorrecta: los archivos de configuración son términos de Erlang. Si se puede calcular, se puede hacer.

Seguridad: limite quién tiene acceso. Es un problema de personas, no técnico, en mi opinión.

Perfilado: cprof, cubierta, eprof, fprof, instrumento + un par de sistemas distribuidos para hacer lo mismo. El muestreo aleatorio también es fácil (la introspección es fuerte en Erlang).

Interacción de Windows: Dunno. (Sesgo: la última vez que utilicé Windows profesionalmente fue en 1998 más o menos).

Algunas observaciones personales:

Su mayor problema podría llegar a ser que se trate de meter Erlang en su proceso existente y que podría resistir. Es un entorno nuevo, por lo que se necesitarán nuevos enfoques en los lugares y usted debe esperar adaptarse y las limitaciones de la solución que encuentre en el camino. El consenso general es que puede funcionar (está funcionando para varios sitios grandes).

Parece que tiene un proceso bien establecido y estricto. ¿Cuánto se permite sacrificar ese proceso para dar paso a un nuevo tipo de pensamiento?

¿Están sus programadores dispuestos a echar a perder casi todos sus conocimientos de OO? Si no, terminará con un problema social en lugar de uno técnico. Sin embargo, si son como yo, aplaudirán, aplaudirán y obtendrán un nivel constante al trabajar con un lenguaje interesante para resolver un problema interesante de una nueva manera.

¿Cuántos programadores experimentados en Erlang tiene? Si tiene pocos, entonces mejor corte los dientes en algunos subsistemas más pequeños primero y luego trabaje hacia la meta más grande. Obtener el beneficio completo del sistema lleva meses si no años. Sin embargo, se puede obtener un beneficio parcial en semanas.