En una app de microservicios, ¿cuántos son demasiados microservicios?

¿Por qué microservicios?

Las arquitecturas de microservicios se han popularizado en los últimos años porque hacen que las aplicaciones complejas sean más ágiles y fáciles de gestionar. Los microservicios son similares a la arquitectura orientada a servicios (SOA), que fue popular en los años 2000. Pero los microservicios son diferentes de SOA en formas clave. Las aplicaciones de microservicios tienden a incluir más servicios, y cada servicio suele ser más ligero que bajo el modelo SOA.

La llegada de las plataformas de contenedores, especialmente Docker, ha ayudado a impulsar la popularidad de los microservicios. Los contenedores de aplicación facilitan el despliegue de microservicios ejecutando cada servicio dentro de un conjunto diferente de contenedores. Esto proporciona una manera fácil de aislar los procesos de cada servicio, así como escalar los servicios individualmente conforme lo demandan los cambios, en lugar de tener que escalar la aplicación completa.

Migración a microservicios

En la mayoría de los casos, si desea migrar a microservicios, tiene dos opciones:

• Refactorizar una aplicación monolítica existente para que funcione como un conjunto de microservicios. Refactorizar significa modificar la base de código sin volver a escribirla por completo.
• Reconstruir su aplicación desde cero, de acuerdo con una arquitectura de microservicios.

De cualquier manera, debe decidir cuántos microservicios incluir.

¿Cuántos microservicios necesita realmente? Esa es la gran pregunta. No hay una regla dura y rápida para determinar cuántos microservicios debería incluir una aplicación. La respuesta variará de aplicación a aplicación, y de organización a organización, por supuesto. Para determinar qué número es adecuado para usted, tenga en cuenta las siguientes consideraciones al planificar la migración de su aplicación.

Equilibre la agilidad con la complejidad

Su principal objetivo al decidir cuántos microservicios son suficientes es encontrar el equilibrio adecuado entre agilidad y complejidad.

Si implementa muy pocos microservicios, su aplicación no ganará mucha agilidad porque todavía estará compuesta de grandes partes, casi monolíticas.

Si tiene demasiados microservicios, terminará con más partes móviles en su entorno de las que necesita. Esto dificulta la gestión, el monitoreo y la seguridad.

Así, a medida que elabora una nueva arquitectura para su aplicación de microservicios, piense si el número de servicios que va a incluir proporcionará la agilidad que necesita mientras sigue siendo manejable para su equipo de administración.

Revise el código y los procesos existentes al refactorizar

Si está refactorizando su aplicación, trate de alinear cada microservicio con una parte distinta de su base de código, si es posible.

Esto es fácil de hacer si su código se escribió para ser modular o si su aplicación ya se ejecuta como un conjunto de diferentes procesos. En estos casos, puede tomar cada componente principal del monolito y ejecutarlo como un microservicio, sin tener que volver a escribir demasiado código.

Esto es más difícil de hacer si su aplicación es tan desesperadamente monolítica que no hay forma lógica de romper su código o procesos en microservicios. Si ese es el caso, probablemente es mejor reconstruir que refactorizar la aplicación, especialmente en la modernización de aplicaciones y los proyectos de transformación digital.

Mantenga la jerarquía organizacional en mente

Asegúrese de que cada microservicio esté asociado con un equipo de desarrollo y gestión DevOps dentro de su organización. Esto no significa que tenga que haber un equipo por cada microservicio. Un solo equipo puede manejar varios microservicios.

El objetivo aquí es simplemente asegurarse de que no incluye microservicios en su arquitectura que se convierten en "huérfanos", porque nadie está disponible para desarrollarlos o soportarlos; o, peor, microservicios que terminan siendo gestionados por múltiples equipos al mismo tiempo, lo que conduce a problemas de comunicación y organización.

Consumo de recursos

Puede ser útil pensar en términos de qué tipos de recursos necesitan diferentes partes de su aplicación, y cuántos necesitan.

Su entorno será más ágil si cada microservicio necesita acceder a solo un tipo de recurso, como el cálculo, el almacenamiento o las redes. Los microservicios que necesitan múltiples recursos son más difíciles de manejar y más propensos a fallar.

Además, su aplicación será capaz de escalar mejor y permanecer tan rentable como sea posible si las partes de ella que demandan el mayor volumen de recursos funcionan como sus propios microservicios. Esto se debe a que usted puede aumentar la asignación de recursos a estos microservicios cuando sea necesario, sin asignar más recursos a otros microservicios que no los necesitan.

Por ejemplo, si su aplicación permite a los usuarios subir fotos y luego cambiar su tamaño, esta funcionalidad debe asignarse a tres microservicios diferentes:

• Uno es un web front-end, que permite a los usuarios cargar una foto, que es una tarea ligera que requiere una cantidad moderada de recursos de computación.
• Otro es un microservicio de almacenamiento, que toma una imagen cargada o redimensionada y la almacena en una base de datos. Esta tarea requiere almacenamiento, pero muy poco cálculo.
• El tercero es un servicio que hace el redimensionamiento de imagen, que es muy intensivo en computación.

No olvide la seguridad

Las consideraciones de seguridad pueden ser una parte importante de cómo se decide qué se convierte en un microservicio distinto.

Un objetivo al planificar su arquitectura es hacer que los vectores de ataque para cada microservicio sean lo más pequeños posible. Por esa razón, asegúrese de no mezclar la funcionalidad de cara al público y los servicios internos dentro de un solo microservicio. Si lo hace, está exponiendo innecesariamente los servicios internos a un mayor riesgo de ataque, porque los servicios que no son públicos tienen menos probabilidades de ser atacados en la mayoría de los casos.

Tenga en cuenta, también, que uno de los beneficios de los microservicios es que ayudan a mitigar el impacto de las brechas. Si los atacantes comprometen un microservicio, no necesariamente serán capaces de comprometer el resto de su aplicación. Utilice esto para su ventaja, asegurándose que los servicios de mayor riesgo (es decir, los más probables de ser comprometidos, como los servicios web) dentro de su aplicación funcionan como microservicios distintos.

Del mismo modo, utilice diferentes microservicios para ejecutar las partes de su aplicación que son las más importantes de asegurar. Por ejemplo, si dispone de un servicio de almacenamiento que accede a datos de clientes protegidos por directivas reguladoras, ejecutar ese servicio como un microservicio distinto ayudará a mantenerlo más seguro en caso de que los atacantes comprometan otras partes de la aplicación.

Esto podría ser una razón para romper la funcionalidad de almacenamiento de su aplicación en varios microservicios. Algunos manejarán datos altamente sensibles, mientras que otros trabajarán con tipos de información menos sensibles.

Tomando la decisión de la aplicación de microservicios

Decidir exactamente cuántos microservicios debe tener su aplicación es una pregunta que solo usted puede responder. No hay una solución fácil.

Sin embargo, al evaluar cuestiones como la forma en que se organiza la base de código, el consumo de recursos de su aplicación, la forma en que se definen roles y equipos dentro de su organización, y las consideraciones de seguridad, se puede determinar cuántos microservicios son adecuados para usted.

Cuando lo haga, encuentre el equilibrio ideal entre la agilidad y la complejidad.