¿Dónde encaja Elixir / erlang en el enfoque de microservicios? [cerrado]


109

Últimamente he estado haciendo algunos experimentos con docker compose para implementar múltiples microservicios en colaboración. Puedo ver los muchos beneficios que brindan los microservicios, y ahora que hay un buen conjunto de herramientas para administrarlos, creo que no es extremadamente difícil saltar al vagón de los microservicios.

Pero también he estado experimentando con Elixir y me gustan mucho los beneficios que proporciona por sí solo. Dado que fomenta el empaquetado de su código en múltiples aplicaciones desacopladas y admite actualizaciones de código activo, ¿cómo mezclaría Docker con elixir (o erlang, para el caso)?

Por ejemplo, si quiero usar Docker porque proporciona paridad dev-prod, ¿cómo encaja elixir en eso? Dado que los contenedores de la ventana acoplable son inmutables, pierdo la capacidad de realizar actualizaciones de código activo, ¿verdad? ¿Qué pasa con las implementaciones azul / verde o las versiones Canary?

Quiero decir, podría escribir microservicios con Elixir y usarlos como si estuvieran escritos en cualquier otro idioma, el poliglotismo es uno de los beneficios de los microservicios de todos modos, pero no estoy obteniendo todos los beneficios de usar la plataforma OTP. Supongo que las aplicaciones de erlang colaborativas puras son mucho más óptimas que el uso de colas intermedias para comunicarse entre microservicios escritos en diferentes (o no) lenguajes.


7
Veo que el voto negativo se debe a que la pregunta "no muestra ningún esfuerzo de investigación". Eso es triste porque no es realmente cierto, por supuesto que el problema podría estar en la pregunta en sí, pero no se me puede acusar de no investigar porque últimamente es lo único que he estado haciendo. Mucho.
Papipo

1
Esta pregunta es demasiado amplia: las preguntas sobre stackoverflow están destinadas a incluir problemas específicos.
Paweł Obrok

4
¿Debo moverlo a otro sitio de stackexchange? Porque la pregunta es legítima en mi opinión.
Papipo

2
Creo que es una pregunta interesante, pero ¿podría pertenecer al stackexchange de los programadores? Dicho esto, no votar para cerrar
George Mauer

1
Es increíble y está totalmente hecho para el trabajo.
Bryan

Respuestas:


138

Esta es una pregunta muy abierta, pero intentaré ilustrar por qué Elixir / Erlang puede ser la mejor plataforma que existe para desarrollar sistemas distribuidos (independientemente de si está trabajando con microservicios).

Primero, comencemos con algunos antecedentes. Erlang VM y su biblioteca estándar fueron diseñadas por adelantado para construir sistemas distribuidos y esto realmente se nota. Hasta donde yo sé, es el único tiempo de ejecución y VM que se usa ampliamente en la producción y está diseñado por adelantado para este caso de uso.

Aplicaciones

Por ejemplo, ya ha insinuado "aplicaciones". En Erlang / Elixir, el código está empaquetado dentro de aplicaciones que:

  1. se inician y detienen como unidad. Iniciar y detener su sistema es una cuestión de iniciar todas las aplicaciones en él
  2. proporcionar una estructura de directorio unificada y una API de configuración (¡que no es XML!). Si ya ha trabajado y configurado una aplicación OTP, sabe cómo trabajar con cualquier otra
  3. contiene el árbol de supervisión de su aplicación, con todos los procesos (por proceso me refiero a "procesos de VM" que son subprocesos de cálculo livianos) y su estado

El impacto de este diseño es enorme. Significa que los desarrolladores de Elixir, cuando escriben aplicaciones, tienen un enfoque más explícito para:

  1. cómo se inicia y detiene su código
  2. ¿Cuáles son los procesos que forman parte de una aplicación y, por tanto, cuál es el estado de la aplicación?
  3. cómo esos procesos reaccionarán y se verán afectados en caso de fallas o cuando algo sale mal

No solo eso, las herramientas en torno a esta abstracción son excelentes. Si tiene instalado Elixir, abrir "iex" y escriba: :observer.start(). Además de mostrar información y gráficos sobre su sistema en vivo, puede eliminar procesos aleatorios, ver su uso de memoria, estado y más. Aquí hay un ejemplo de cómo ejecutar esto en una aplicación Phoenix:

Observador ejecutándose con una aplicación Phoenix

La diferencia aquí es que las aplicaciones y los procesos le brindan una abstracción para razonar sobre su código en producción . Muchos lenguajes proporcionan paquetes, objetos y módulos principalmente para la organización del código sin reflejarse en el sistema de ejecución. Si tiene un atributo de clase o un objeto singleton: ¿cómo puede razonar sobre las entidades que pueden manipularlo? Si tiene una pérdida de memoria o un cuello de botella, ¿cómo puede encontrar la entidad responsable de ello?

Si le pregunta a cualquiera que ejecute un sistema distribuido, ese es el tipo de información que desea, y con Erlang / Elixir lo tiene como componente básico.

Comunicación

Todo esto es realmente solo el comienzo. Al construir un sistema distribuido, debe elegir un protocolo de comunicación y el serializador de datos. Mucha gente elige HTTP y JSON que, cuando lo piensa, es una combinación muy detallada y costosa para realizar lo que realmente son llamadas RPC.

Con Erlang / Elixir, ya tiene un protocolo de comunicación y un mecanismo de serialización listos para usar. Si desea que dos máquinas se comuniquen entre sí, solo necesita darles nombres, asegurarse de que tengan el mismo secreto y listo.

Jamie habló sobre esto en Erlang Factory 2015 y cómo pudieron aprovechar esto para construir una plataforma de juego: https://www.youtube.com/watch?v=_i6n-eWiVn4

Si desea utilizar HTTP y JSON, también está bien y las bibliotecas como Plug y los marcos como Phoenix le garantizarán que sea productivo aquí también.

Microservicios

Hasta ahora no he hablado de microservicios. Eso es porque, hasta este punto, realmente no importan. Ya está diseñando su sistema y nodos en torno a procesos muy pequeños que están aislados. ¡Llámalos nanoservicios si quieres!

No solo eso, también están empaquetados en aplicaciones, que los agrupan como entidades que se pueden iniciar y detener como una unidad. Si tiene aplicaciones A, B y C, y luego desea implementarlas como [A, B] + [C] o [A] + [B] + [C], tendrá muy pocos problemas para hacerlo debido a su diseño inherente. O, mejor aún, si desea evitar agregar la complejidad de las implementaciones de microservicios en su sistema por adelantado, puede implementarlas por completo en el mismo nodo.

Y, al final del día, si está ejecutando todo esto utilizando el Protocolo distribuido de Erlang, puede ejecutarlos en diferentes nodos y podrán llegar a otros siempre que se refiera a ellos por en {:node@network, :name}lugar de :name.

Podría ir más lejos, pero espero haberte convencido en este momento. :)


En realidad, me gustan mucho Elixir y OTP, la pregunta era más sobre cómo obtener algunos beneficios de los microservicios (como paridad dev-prod, lanzamientos canarios, etc.) mientras se usa Elixir.
Papipo

Tenía un párrafo sobre Docker pero se perdió. :) La esencia es que lo usa para la implementación de nodos, por lo que elige qué aplicaciones tienen sentido por nodo. Las implementaciones azul / verde definitivamente se pueden lograr, pero dependen del protocolo, el tipo de estado y otros factores.
José Valim

5
La charla que mencioné cubre una capa de enrutamiento que podría usarse para azul / verde o canario. Nuevamente, depende del protocolo elegido, pero puede pasar de una entrada global en Erlang distribuido, algo usando cónsul, o haproxy para algo basado en HTTP.
José Valim

El enfoque de descubrimiento de servicios tiene sentido. Supongo que siempre estaba pensando en términos de equilibrio de carga.
Papipo

1
¿Qué pasa con uno de los otros beneficios de los microservicios como elegir el mejor idioma para una tarea específica? Amo el elixir, sin embargo, no es el mejor lenguaje para cada tarea. Lo que quiero decir es que uno puede necesitar que un microservicio específico use un lenguaje diferente en lugar de elixir. Entonces, ¿debería seguir una arquitectura tradicional de microservicios?
Jeancarlo
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.