Cómo decidir si adoptar un enfoque de microservicios

7

TL; DR: ¿Qué criterios debe utilizar para decidir si desea "hacer los servicios de micro"?

Dirijo un equipo de desarrolladores y uno de ellos insiste en que adoptemos un enfoque de micro servicios para la arquitectura. Al principio dudé, porque había estado codificando bajo una roca durante varios años y nunca supe que los microservicios eran una cosa.

Comencé a entusiasmarme con la idea, pero aún no creo que se justifique un enfoque de micro servicios en nuestro caso. Nunca atenderemos a millones de usuarios y solo somos 5, así que no es como si tuviéramos equipos completos dedicados a servicios tan específicos.

Tenemos un portal de administración de red basado en web que construimos y mantenemos. Hay muchas otras aplicaciones que manejan diferentes cosas como la facturación de llamadas VOIP, la recopilación de Netflow, la recopilación de uso basada en SNMP, etc. No llamaría a estos microservicios, ya que son un poco más toscos que las responsabilidades específicas de los microservicios. tener.

¿Deberían todos los equipos de desarrollo de todo el mundo 'hacer' micro servicios? Si no, ¿cómo decide si los microservicios son adecuados para su entorno?

    
pregunta emurano 17.12.2016 - 14:06

2 respuestas

11
  

Si no, ¿cómo decide si los microservicios son adecuados para su entorno?

Simplemente a través de dolor . Suena inusual, pero desde mi perspectiva es un indicador válido, de que algo va mal.

Si observas las razones, por qué microservices están de moda, hay una dimensión histórica que juega un papel importante.

Los proyectos generalmente exitosos van así:

  1. Comienza con un prototipo

  2. Prototipo de carne

  3. Poner en marcha el negocio

  4. Crecimiento enorme que resulta en

    a. Una gran cantidad de características están activadas

    b. Codebase crecimiento más allá del control

  5. PAIN comienza : la programación de implementaciones se convierte en una pesadilla, los subsistemas dependientes no se pueden implementar por separado

  6. RELIEF Microservices FTW

Dividir todo el código base en componentes fácilmente implementables.

La pregunta que está haciendo es un indicador bueno , que no está experimentando dolor a tal nivel, que sería necesario pasar a los microservicios.

Hacer microservicios no es sin un precio. Su sistema aumentará definitivamente en términos de complejidad.

  • Cuando tienes un monolito, tu mundo es simple: "Llama a un método, haz cosas, obtén resultados después de una cantidad de tiempo precalculable".

  • Cuando estás tratando con microservicios , te metes de lleno en el lodo de los sistemas distribuidos: "Llámame tal vez" Las cosas que son ciertas en un monolito, se vuelven inciertas en un mundo microservice .

La razón por la que muchas empresas grandes eligieron el enfoque de microservicio es simple : tratar los problemas de los sistemas distribuidos fue más simple que escalar su monolito.

Por supuesto: desde un punto de vista arquitectónico, un grupo de unidades separadas se ve más limpio (en el papel) que una bola de un monolito.

  

Dirijo un equipo de desarrolladores y uno de ellos insiste en que adoptemos un enfoque de micro servicios para la arquitectura.

Le preguntaría qué cambiaría (mejor o peor) en su escenario concreto.

  

Nunca vamos a atender a millones de usuarios y solo somos 5, por lo que no vamos a tener equipos completos dedicados a servicios tan específicos.

No veo un problema (directo) aquí. Dividir su base de código en partes desplegables separadas no tiene nada que ver con el tamaño del equipo. El código base como tal sería casi el mismo. Si su equipo maneja el código base ahora, debería ser posible hacerlo después de la migración. Lo que es necesario, además de dividir el código base, es: educar a su equipo en términos de cómo lidiar con los problemas de sistemas distribuidos . Esta es una inversión para hacer.

  

Nunca vamos a atender a millones de usuarios y solo somos 5, por lo que no vamos a tener equipos completos dedicados a servicios tan específicos.

     

No llamaría a estos microservicios ya que son un poco más toscos que las responsabilidades específicas que parecen tener los microservicios.

Los microservicios no tienen nada que ver con millones de usuarios, aunque sí con problemas de implementación de una base de código que enfrenta un millón de usuarios. Más: A pesar del término "micro", los "servicios" no solo deben tener una longitud de 100 líneas, sino que es una , pero no la única razón para llamarlo " micro ".

Me gusta mucho más el término "servicio enfocado". Eso es lo que es: en términos de "separación de inquietudes", dicho servicio se ocupa de un tema.

tl;dr

Si no tiene ningún problema al ejecutar su sistema actual, no debe hacer un cambio.

    
respondido por el Thomas Junk 17.12.2016 - 19:25
4
  

¿Deberían todos los equipos de desarrollo de todo el mundo 'hacer' micro servicios?

A pesar de los beneficios de la arquitectura de Microservices, la respuesta es por supuesto, no todos deberían .

  

Si no, ¿cómo decide si los microservicios son adecuados para   su entorno?

Es difícil de responder, porque cualquier arquitectura es la respuesta técnica a una pregunta política, estratégica . La estrategia comercial de la empresa es importante aquí, por lo tanto, la decisión no debe ser una mera cuestión que resolver entre los desarrolladores.

Sugiero leer la publicación de Martin Fowler sobre Microservicios . También leyendo los enlaces. Vale la pena leerlos.

Al leer sobre los puntos fuertes de los microservicios, puede obtener la respuesta a su pregunta principal: What criteria should you use to decide whether to 'do micro services'?

Por lo general, los microservicios como arquitectura encajan bien en sistemas complejos.

La complejidad se define por diferentes contextos delimitados. Al igual que las unidades de negocios que podrían operar y evolucionar independientemente unas de otras, pero logran un objetivo común trabajando en conjunto.

La complejidad del sistema no se debe a la complejidad unitaria de cada "contexto acotado". Se debe a la necesidad de tener que deshacerse de todos ellos en la misma solución.

Un contexto acotado puede ser tan simple como: administración de usuarios, registro, facturación, informes, seguimiento de eventos, seguridad (autenticación y autorización), ...

Dicho esto, no significa que los pequeños proyectos no deban adoptar esta arquitectura. Como es habitual, depende de si las ganancias superan los costos implícitos. Y en general, si responde a una necesidad real.

Tendría en cuenta, en serio, las concesiones descritas en el artículo vinculado anteriormente:

  
  • El equipaje adicional de administrar este tipo de sistemas, reduciendo la productividad
  •   
  • El conocimiento ( en profundidad ) del dominio ( microservicios )
  •   
  • La complejidad del desarrollo
  •   
  • La capacidad de la empresa para gestionar:      
    • Aprovisionamiento rápido
    •   
    • Monitoreo básico
    •   
    • Implementación rápida de aplicaciones
    •   
    • Cultura Devops
    •   
  •   

Finalmente, involucrarse con cualquier parte interesada en la compañía es un deber. Solo para asegurar que todos sepan las implicaciones.

    
respondido por el Laiv 17.12.2016 - 16:38

Lea otras preguntas en las etiquetas