Header Ads Widget

Ticker

6/recent/ticker-posts

¿Debería comenzar con un monolito o microservicios?


 

Desafiando la sabiduría convencional

La sabiduría convencional sugiere que un nuevo proyecto debe comenzar con un servidor monolítico porque una aplicación unificada puede facilitar el flujo de trabajo para un pequeño equipo de puesta en marcha. Pero los microservicios pueden ser una alternativa valiosa en las circunstancias adecuadas. Entonces, ¿cómo decides cuál es el adecuado para tu equipo?

Para responder a esta pregunta, hemos llamado a tres  directores de tecnología que actualmente están lidiando con este tema. Por ejemplo, Darby Frey puso en marcha recientemente un proyecto totalmente nuevo después de asumir su nuevo papel como jefe de ingeniería de plataforma sénior de Gamut. A pesar de comenzar con un monolito en su empresa anterior, Belly, descubrió que, en las circunstancias adecuadas, comenzar con un monolito no siempre es la mejor manera de hacerlo.

En Belly, Darby y su equipo dividieron su monolito en una arquitectura de microservicios bastante grande. Se las arreglaron para llevarlo a un buen lugar, pero solo después de meses de pruebas y tribulaciones migrando a los microservicios. Con esta experiencia fresca en su mente, abordó su nuevo proyecto en Gamut con un poco más de cuidado con los microservicios. Y con eso, se encontró frente a una decisión con la que todos luchamos, ¿deberíamos comenzar con un monolito o microservicios y cómo decidimos ? Esa pregunta es la que abordaremos hoy.

Monolito frente a microservicios

Monolito

Al contrario de lo que podría pensar, un monolito no es una arquitectura anticuada que debamos dejar en el pasado. En determinadas circunstancias, un monolito es ideal. Hablamos con  Steven Czerwinski , director de ingeniería de Scaylr y ex empleado de Google, para comprender mejor esto.

“A pesar de que habíamos tenido estas experiencias positivas de usar microservicios en Google, nosotros [en Scaylr] optamos [por una ruta monolítica] porque tener un servidor monolítico significa menos trabajo para nosotros como dos ingenieros”, explicó.

Ventajas del monolito:

  • Menos inquietudes transversales: la principal ventaja de la arquitectura monolítica es que la mayoría de las aplicaciones suelen tener una gran cantidad de inquietudes transversales, como el registro, la limitación de velocidad y las funciones de seguridad, como pistas de auditoría y protección DoS. Cuando todo se ejecuta a través de la misma aplicación, es fácil conectar componentes a esas preocupaciones transversales.
  • Menos gastos operativos: tener una aplicación grande significa que solo hay una aplicación para la que necesita configurar el registro, la supervisión y las pruebas . Por lo general, también es menos complejo de implementar.
  • Rendimiento: también puede haber ventajas de rendimiento, ya que el acceso a la memoria compartida es más rápido que la comunicación entre procesos (IPC).

Contras del monolito:

  • Estrechamente acoplados: los servicios de aplicaciones monolíticas tienden a acoplarse y enredarse estrechamente a medida que la aplicación evoluciona, lo que dificulta aislar los servicios para fines como el escalado independiente o la capacidad de mantenimiento del código.
  • Más difícil de entender: las arquitecturas monolíticas también son mucho más difíciles de entender, porque puede haber dependencias y efectos secundarios que no son obvios cuando se mira un servicio o controlador en particular.

Microservicios

Si bien los microservicios tienden a ser más pequeños que el monolito promedio, no tienen por qué ser pequeños . Algunos lo son, pero el tamaño es relativo y no existe un estándar de unidad de medida entre las organizaciones. Estos servicios se basan en capacidades empresariales y se pueden implementar de forma independiente .

Ventajas de los microservicios

  • Mejor organización: las arquitecturas de microservicios suelen estar mejor organizadas, ya que cada microservicio tiene un trabajo muy específico y no se ocupa de los trabajos de otros componentes.
  • Desacoplado: los servicios desacoplados también son más fáciles de recomponer y reconfigurar para servir a los propósitos de diferentes aplicaciones (por ejemplo, servir tanto a los clientes web como a la API pública). También permiten la entrega rápida e independiente de piezas individuales dentro de un sistema integrado más grande.
  • Rendimiento: en las circunstancias adecuadas, los microservicios también pueden tener ventajas de rendimiento según cómo estén organizados. Esto se debe a que es posible aislar los servicios activos y escalarlos independientemente del resto de la aplicación.
  • Menos errores: los microservicios permiten el desarrollo paralelo al establecer un límite difícil de cruzar entre las diferentes partes de su sistema. Al hacer esto, hace que sea difícil, o al menos más difícil, hacer lo incorrecto: es decir, conectar partes que no deberían estar conectadas y acoplar demasiado las que necesitan estar conectadas.

Contras de microservicios

  • Inquietudes transversales en cada servicio: a medida que crea una nueva arquitectura de microservicio, es probable que descubra inquietudes transversales que no anticipaba en el momento del diseño. Deberá incurrir en la sobrecarga de módulos separados para cada preocupación transversal (es decir, pruebas) o encapsular las preocupaciones transversales en otra capa de servicio por la que se enruta todo el tráfico. Con el tiempo, incluso las arquitecturas monolíticas tienden a enrutar el tráfico a través de una capa de servicio externa por cuestiones transversales, pero con una arquitectura monolítica, es posible retrasar el costo de ese trabajo hasta que el proyecto esté mucho más maduro.
  • Mayor sobrecarga operativa: los microservicios se implementan con frecuencia en sus propias máquinas virtuales o contenedores , lo que provoca una proliferación del trabajo de disputas de VM. Estas tareas se automatizan con frecuencia con herramientas de gestión de flotas de contenedores .
Estudio de caso de microservicios: creación de un marco de microservicios en CIBC

Cómo decidir si un monolito o microservicios es lo mejor para su negocio

Entrevistamos a tres directores de tecnología que se enfrentaron a esta decisión para obtener información sobre esta cuestión; Darby Frey (Gamut), David Strauss (Pantheon) y Steven Czerwinski (Scalyr). Sus experiencias nos enseñan a preguntarnos lo siguiente:

¿Estás en un territorio familiar?

Darby y su equipo en Gamut pudieron profundizar directamente en los microservicios porque tenían experiencia con plataformas de comercio electrónico y su empresa tenía un gran conocimiento sobre las necesidades y demandas de sus clientes. Si viajaba por un camino desconocido, por otro lado, un monolito podría haber sido la opción más segura.

¿Está preparado su equipo?

¿Su equipo tiene experiencia con microservicios? ¿Qué pasa si cuadruplica el tamaño de su equipo durante el próximo año? ¿Son los microservicios ideales para esa situación? Evaluar estas dimensiones de su equipo es crucial para el éxito de su proyecto.

Si su equipo está preparado, comenzar con microservicios es prudente, ya que le permite acostumbrarse al ritmo de desarrollo en un entorno de microservicios, desde el principio.

¿Cómo está tu infraestructura?

En realidad, necesitará una infraestructura basada en la nube para que los microservicios funcionen para su proyecto.

“[Anteriormente], querría comenzar con un monolito porque deseaba implementar un servidor de base de datos. La idea de tener que configurar un servidor de base de datos para cada microservicio y luego escalar era una tarea gigantesca. Solo una organización enorme y conocedora de la tecnología podría hacer eso ”, explicó David Strauss, CTO de Pantheon. "Mientras que hoy con servicios como Google Cloud y Amazon AWS, tiene muchas opciones para implementar cosas pequeñas sin necesidad de poseer la capa de persistencia para cada una".

Evaluar el riesgo empresarial

Puede pensar que los microservicios son el camino "correcto" a seguir como una startup experta en tecnología con grandes ambiciones. Pero los microservicios plantean un riesgo empresarial .

“Muchos equipos sobreconstruyen su proyecto inicialmente; todos quieren pensar que su startup será el próximo unicornio y que, por lo tanto, deberían construir todo con microservicios o alguna otra infraestructura hiper-escalable. Pero eso suele estar mal, casi todo el tiempo ”, dijo Strauss.

Un ejemplo de esto de sus primeros días en Pantheon fue un sistema que se limitaba a una sola máquina virtual . Pensaron que pasaría uno o dos meses hasta que se verían obligados a escalarlo. Terminó siendo más de un año, y terminaron escalando de una manera completamente diferente de lo que habían anticipado.

Espere nuestro eBook: Estrategias para la arquitectura de microservicios

Toma de decisiones en contexto

Utilizando la sabiduría extraída de las entrevistas, tome las respuestas a las preguntas anteriores y aplíquelas a la situación de su equipo.

Cuándo empezar con un monolito

Aquí hay algunos escenarios que indican que debe comenzar su próximo proyecto utilizando arquitectura monolítica.

  • Su equipo está en la etapa de fundación: su equipo es pequeño, entre 2 y 5 miembros y, por lo tanto, no puede abordar una arquitectura de microservicios más amplia y con muchos gastos generales.
  • Está construyendo un producto no probado o una prueba de concepto: ¿Está construyendo un producto no probado en el mercado? Si se trata de una idea nueva, es probable que gire y evolucione con el tiempo, por lo que un monolito es ideal para permitir una iteración rápida del producto . Lo mismo se aplica a una prueba de concepto donde su objetivo es aprender tanto como sea posible lo más rápido posible, incluso si termina tirándolo.
  • No tiene experiencia en microservicios: si su equipo no tiene experiencia previa con microservicios, a menos que pueda justificar el riesgo de aprender "sobre la marcha" en una etapa tan temprana, es probable que sea otra señal de que debe ceñirse a un monolito para comenzar.

Cuándo comenzar con microservicios

A continuación, se muestran algunos escenarios que indican que debe comenzar su próximo proyecto utilizando microservicios:

  • Necesita una entrega de servicios rápida e independiente: los microservicios permiten la entrega rápida e independiente de piezas individuales dentro de un sistema integrado más grande. Tenga en cuenta que, según el tamaño de su equipo, puede llevar tiempo ver las ganancias en la prestación de servicios en comparación con comenzar con monolito.
  • Una parte de su plataforma debe ser extremadamente eficiente: si su empresa está realizando un procesamiento intensivo de petabytes de volumen de registro, es probable que desee construir ese servicio en un lenguaje muy eficiente (es decir, C ++) mientras se puede construir su panel de usuario. en Ruby on Rails.
  • Planea hacer crecer su equipo: comenzar con microservicios hace que su equipo se acostumbre a desarrollar pequeños servicios separados desde el principio, y tener equipos separados por límites de servicio hace que sea mucho más fácil escalar su equipo cuando lo necesita sin introducir una complejidad exponencial.

El Takeaway

No intente utilizar microservicios solo porque otros equipos de ingeniería están teniendo éxito con ellos. Su propio contexto, evaluado según las consideraciones anteriores, es la clave para decidir si debe comenzar con monolitos o microservicios.

Gracias a nuestro panel de entrevistados por compartir sus ideas. A nuestros lectores: ¿Cómo ha sido su experiencia de desarrollo? ¿Ve otros beneficios o inconvenientes en la adopción de arquitecturas monolíticas o de microservicios ? Comenta abajo.

Publicar un comentario

0 Comentarios