En primer lugar, definamos lo que entendemos por «Monolito» y «Microservicio». Una arquitectura monolítica se construye como un gran sistema y suele ser un código base. Un monolito a menudo se despliega de una sola vez, tanto el código frontal como el código final juntos, independientemente de lo que se haya cambiado. Una arquitectura de microservicios, sin embargo, es donde una aplicación se construye como un conjunto de pequeños servicios, cada uno con su propia base de código. Estos servicios se basan en capacidades específicas y, por lo general, pueden desplegarse de forma independiente.

La sabiduría convencional predica comenzando con un monolito. Esta tentación es especialmente fuerte cuando se empieza con un equipo delgado y con plazos de entrega ajustados. Pero, ¿la sabiduría convencional siempre tiene razón? Mi buen amigo Darby Frey recientemente comenzó un proyecto nuevo después de haber asumido su nuevo rol como Jefe de Ingeniería de Plataforma de Gamut. A pesar de haber empezado con el monolito en su anterior compañía Belly, descubrió que (en las circunstancias adecuadas) empezar con un monolito no siempre es el mejor camino a seguir.

En Belly, Darby y su equipo dividieron su monolito en una arquitectura de microservicios bastante grande. Lograron llevarlo a un buen lugar, pero sólo después de meses de pruebas y tribulaciones migrando a microservicios. Con esta experiencia fresca en su mente, se acercó a su nuevo proyecto en Gamut un poco más cauteloso con los microservicios:

«Yo era firmemente un miembro del equipo Monolith. Pensé] construyamos una sola aplicación y separemos las cosas más tarde si empezamos a sentir dolor», dijo. Aunque se trataba de un proyecto totalmente nuevo, el equipo de Darby era pequeño, y él tenía un calendario agresivo, así que en la superficie, un monolito parecía ser la opción obvia. «[Pero con este nuevo proyecto], estaba ansioso por no repetir los errores del pasado.»

Y con eso, se encontró frente a una decisión con la que todos luchamos, ¿debemos empezar con un monolito o microservicios y cómo decidimos?

Entendiendo las Opciones

Para decidir entre los dos, primero debemos aclarar qué queremos decir exactamente con «monolito» y «microservicio».

Zachary Crockett, CTO de Particle me dijo que «las arquitecturas de sistemas se encuentran en un espectro… Cuando se habla de microservicios, la gente tiende a concentrarse en un extremo de ese espectro: muchas aplicaciones diminutas que se transmiten demasiados mensajes entre sí. En el otro extremo del espectro hay un monolito gigante haciendo demasiadas cosas. Para cualquier sistema real, hay muchas arquitecturas orientadas a servicios entre esos dos extremos».

DEFINICIÓN DEL MONOLITO

Una aplicación monolítica se construye como una unidad única y unificada. A menudo, un monolito consta de tres partes: una base de datos, una interfaz de usuario del lado del cliente (compuesta de páginas HTML y/o JavaScript que se ejecutan en un navegador) y una aplicación del lado del servidor. La aplicación del lado del servidor manejará las peticiones HTTP, ejecutará la lógica específica del dominio, recuperará y actualizará los datos de la base de datos y rellenará las vistas HTML que se enviarán al navegador.

En un monolito, la lógica de aplicación del lado del servidor, la lógica del lado del cliente frontal, los trabajos de fondo, etc., están todos definidos en la misma base de código masivo. El resultado: si los desarrolladores quieren hacer cambios o actualizaciones, necesitan construir e implementar toda la pila de una sola vez.

Contrariamente a lo que se podría pensar, un monolito no es una arquitectura anticuada que tengamos que dejar en el pasado. En ciertas circunstancias, un monolito es ideal. Steven Czerwinski, director de ingeniería de Scaylr y antiguo empleado de Google, explicó que debido a que su equipo en Scaylr era pequeño, una aplicación unificada era más manejable en comparación con dividir todo en microservicios: «En los primeros días de Scaylr], a pesar de que habíamos tenido estas experiencias positivas de uso de microservicios en Google, fuimos[por un monolito] porque tener un servidor monolítico significa menos trabajo para nosotros como dos ingenieros».

Al considerar una arquitectura monolítica, su equipo debe considerar lo siguiente:

Pros del monolito
  • Menos preocupaciones transversales: La principal ventaja de la arquitectura monolítica es que la mayoría de las aplicaciones suelen tener un gran número de problemas transversales, como el registro, la limitación de velocidad y las características de seguridad, como los registros de auditoría y la protección DOS. Cuando todo pasa por la misma aplicación, es fácil conectar componentes a esas preocupaciones transversales.
  • Menos gastos generales operativos: Tener una aplicación[grande] significa que sólo se necesita una aplicación para configurar el registro, la supervisión y las pruebas. También es generalmente menos complejo de desplegar.
  • Desempeño: 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 de monolito

Acoplado firmemente: Los servicios de aplicaciones monolíticas tienden a estar estrechamente vinculados y enredados a medida que la aplicación evoluciona, lo que dificulta el aislamiento de servicios con fines tales como la escalabilidad independiente o la mantenibilidad 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, efectos secundarios y magia que no son obvias cuando se mira un servicio o controlador en particular.

DEFINICIÓN DE MICROSERVICIOS

No hay nada intrínsecamente «micro» en los microservicios per se. Aunque tienden a ser más pequeños que el monolito promedio, no tienen que 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.

El estilo de arquitectura de microservicios es un enfoque para desarrollar una única aplicación como un conjunto de pequeños servicios, cada uno de los cuales se ejecuta en su propio proceso y se comunica con mecanismos ligeros, a menudo una API de recursos HTTP. Estos servicios se construyen en torno a las capacidades empresariales y pueden desplegarse de forma independiente mediante maquinaria de despliegue totalmente automatizada. Hay un mínimo de gestión centralizada de estos servicios.

Al considerar los microservicios, su equipo debe tener en cuenta:

Pros 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 más grande e integrado.
  • Desempeño: En las circunstancias adecuadas, los microservicios también pueden tener ventajas de rendimiento dependiendo de cómo estén organizados, ya que es posible aislar los servicios en caliente 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, se dificulta -o al menos se dificulta- hacer algo incorrecto: es decir, conectar partes que no deberían estar conectadas y acoplar con demasiada fuerza las que necesitan estar conectadas.
Contras de los microservicios
  • Preocupaciones transversales en cada servicio: A medida que construye una nueva arquitectura de microservicios, es probable que descubra muchas preocupaciones transversales que no anticipó en el momento del diseño. Tendrá que incurrir en la sobrecarga de módulos separados para cada problema transversal (es decir, pruebas), o encapsular los problemas transversales en otra capa de servicio a través de la cual se enruta todo el tráfico. Eventualmente, incluso las arquitecturas monolíticas tienden a enrutar el tráfico a través de una capa externa de servicios para preocupaciones 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 Operacional: Los microservicios se despliegan con frecuencia en sus propias máquinas o contenedores virtuales, lo que provoca una proliferación del trabajo de disputa de VM. Con frecuencia, estas tareas se automatizan con herramientas de gestión de flotas de contenedores.

Tomar la decisión correcta para su organización

Los pros y los contras pueden proporcionar un marco general para discutir los posibles beneficios e inconvenientes de una arquitectura sobre otra cuando se sienta con su equipo. Para aplicar eficazmente estos principios generales, entrevisté a docenas de CTOs para crear una rúbrica de consideraciones para usted cuando está decidiendo qué es lo mejor para su organización.

¿ESTÁS EN TERRITORIO FAMILIAR?

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

¿ESTÁ PREPARADO TU EQUIPO?

¿Tiene su equipo experiencia con microservicios? ¿Qué pasa si cuadruplicas el tamaño de tu equipo en 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 sabio, ya que le permite acostumbrarse al ritmo de desarrollo en un entorno de microservicios, desde el principio.

¿CÓMO ESTÁ SU INFRAESTRUCTURA?

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

«Anteriormente, querría empezar con un monolito porque quería implementar un servidor de base de datos. La idea de tener que crear un servidor de base de datos para cada microservicio y luego ampliarlo fue una tarea gigantesca. Sólo una organización enorme y conocedora de la tecnología podría hacer eso», me explicó David Strauss, Director Técnico de Pantheon. «Mientras que hoy en día con servicios como Google Cloud y Amazon AWS, tienes muchas opciones para desplegar cosas minúsculas sin necesidad de poseer la capa de persistencia para cada una».

EVALUAR EL RIESGO DEL NEGOCIO

Usted puede pensar que los microservicios son el camino «correcto» a seguir como una startup conocedora de la tecnología con grandes ambiciones. Pero los microservicios representan un riesgo para la empresa. David Strauss explicó:

«Muchos equipos superponen su proyecto inicialmente; todo el mundo quiere pensar que su startup será el próximo unicornio y que, por lo tanto, deberían construirlo todo con microservicios o alguna otra infraestructura hiperescalable. Pero eso suele estar mal, casi todo el tiempo».

Continuó diciendo que, en estos casos, las áreas que usted pensó que necesitaba escalar probablemente no son las partes que necesitarán escalar primero, y eso resulta en un esfuerzo fuera de lugar incluso para los sistemas que necesitarán escalar.

CUESTIONES DE CONTEXTO

Los CTOs con los que hablé tenían una amplia experiencia tanto con monolitos como con microservicios. Algunos comenzaron con confianza con microservicios, mientras que otros se aferraron a un monolito al principio y eventualmente hicieron una transición a los microservicios a medida que sus inicios crecían. Considere su propio contexto y los siguientes escenarios para ayudar a determinar qué arquitectura se ajusta a su situación.

Cuándo empezar con un monolito

Aquí hay algunos escenarios que indican que debería comenzar su próximo proyecto usando 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 es incapaz de abordar una arquitectura de microservicios más amplia y costosa.
  • Usted 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 rápida iteración del producto. Lo mismo se aplica a una prueba de concepto en la que su objetivo es aprender lo más rápido posible, incluso si termina tirándola a la basura.
  • Usted no tiene experiencia en microservicios: Si su equipo no tiene experiencia previa con microservicios, a menos que pueda justificar asumir el riesgo de aprender «sobre la marcha» en una etapa tan temprana, es probable que sea otra señal de que debe atenerse a un monolito para comenzar.

Cuándo Empezar Con Microservicios

Aquí hay algunos escenarios que indican que usted debe comenzar su próximo proyecto usando microservicios:

  • Usted necesita un servicio rápido e independiente: Los microservicios permiten la entrega rápida e independiente de piezas individuales dentro de un sistema más grande e integrado. Tenga en cuenta que, dependiendo del tamaño de su equipo, puede tomar 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 crear ese servicio en un lenguaje muy eficiente (por ejemplo, C++), mientras que su panel de control de usuario puede estar integrado en Ruby on Rails.
  • Planea hacer crecer su equipo: Comenzar con microservicios acostumbra a su equipo a desarrollarse en pequeños servicios separados desde el principio, y tener equipos separados por límites de servicio hace que sea mucho más fácil ampliar su equipo cuando sea necesario sin introducir una complejidad exponencial.

El monolito no está muerto y los microservicios no son los más adecuados para cada contexto. Evite la tentación de sumergirse en microservicios simplemente por su explosión de crecimiento. En su lugar, utilice la sabiduría de los CTOs que vinieron antes para considerar cuidadosamente qué arquitectura tiene más sentido para usted.