¿Qué es la arquitectura de microservicios? Microservicios explicados

La arquitectura de microservicios, también conocida como microservicios, son un método específico para diseñar sistemas de software que estructuran una única aplicación como un conjunto de servicios débilmente acoplados. Las aplicaciones tienden a comenzar como una arquitectura monolítica (más sobre esto más adelante) y, con el tiempo, crecer hasta convertirse en un conjunto de microservicios interconectados. La idea principal detrás de los microservicios están que algunos tipos de aplicaciones son más fáciles de construir y mantener cuando son divididas en muchas pequeñas partes que trabajan juntas. Aunque la arquitectura ha aumentado su complejidad, los microservicios siguen ofreciendo muchas ventajas sobre la estructura monolítica. El concepto de micro proviene de la infraestructura monolítica existente que la mayoría de las empresas han utilizado, especialmente si la empresa lleva una década o más en el mercado. En lugar de una arquitectura monolítica, cada componente de una arquitectura de microservicios tiene:

• Su propia CPU
• Su propio entorno de ejecución
• A menudo, un equipo dedicado trabaja en ello, asegurándose de que cada servicio están distinto entre sí

Esta arquitectura significa que cada servicio puede:

• Ejecutar su propio proceso único
• Comunica de forma autónoma sin depender de los otros microservicios ni de la aplicación en su conjunto

Esta capacidad de separarse y recombinarse protege todo el sistema contra la decadencia y facilita mejor los procesos ágiles, resultando atractivo para las organizaciones, especialmente para aquellas que aún utilizan infraestructuras monolíticas. Este artículo tratará:

• Cómo funcionan los microservicios
• Ejemplos
• Arquitecturas monolíticas frente a microservicios
• Pros y contras de los microservicios
• Recursos útiles

Cómo funcionan los microservicios

Los microservicios son un conjunto de servicios que actúan juntos para Haz que una aplicación completa funcione. Esta arquitectura utiliza APIs para pasar información, como consultas de usuario o un flujo de datos, de un servicio a otro. Cómo funciona el software subyacente, o sobre qué hardware está construido el servicio, depende únicamente del equipo que construyó el servicio. Esto hace que tanto la comunicación entre equipos como la actualización de servicios sean muy dinámicas—incluso reactivas—permitiendo que una empresa o equipo de software sea más resiliente en su desarrollo. Kubernetes ha contribuido a avanzar en la causa de los microservicios, aunque no es un pilar imprescindible. El auge de la computación en la nube y los ordenadores en red ha hecho dos cosas:

• Se eliminó la responsabilidad del usuario que necesitaba un ordenador potente para ejecutar todas las operaciones necesarias.
• Pone la responsabilidad en la empresa de utilizar servidores individuales para ejecutar su servicio cada vez que un usuario ejecuta la aplicación.

En el caso de los microservicios, la máquina del usuario puede ser responsable del procesamiento básico, pero están principalmente responsable de enviar y recibir llamadas de red a otros ordenadores. Siempre que te utiliza una aplicación, es razonable asumir que son hay otros cinco ordenadores, más o menos, que simplemente se encenden para potenciar tu experiencia. En el caso de algo como Facebook o Uber, puede ser más razonable esperar otros 10.000 ordenadores son procesando activamente información para mejorar la experiencia del usuario. Los microservicios a menudo se son considerados una evolución lógica de la Arquitectura Orientada a Servicios (SOA), pero son diferencias claras entre ambos.

Ejemplos de arquitectura de microservicios

Como señala Martin Fowler, muchas grandes empresas ahora utilizan microservicios dentro de su arquitectura. Netflix es uno de los primeros y más conocidos adoptantes. Otros ejemplos conocidos son:

• eBay
• Amazon
• Twitter
• PayPal
• SoundCloud
• Dorado
• El Guardián

  En cada una de estas empresas son presente una red de microservicios. Por ejemplo, SoundCloud podría tener un microservicio para nuevos usuarios diseñado para incorporar a un usuario a su aplicación. El microservicio activará la cuenta del usuario en el backend y podría ser responsable de enviar un correo de bienvenida al usuario y una guía cuando este inicie sesión en la aplicación. Otro microservicio para Soundcloud podría ser gestionar la subida y almacenamiento de la canción de un usuario en la plataforma. Otro podría ser su funcionalidad de búsqueda y artistas recomendados. Como una empresa está dividida en departamentos con personas con diferentes responsabilidades, como un agente de ventas, un financiero y un cajero bancario que son todos puntos de contacto con el mismo banco, los microservicios de una empresa dividen la responsabilidad de toda la empresa en acciones individuales. La diferencia entre este diseño de microservicios y un monolito están que Soundcloud no tiene una única aplicación para manejar cada una de estas partes, que se lanzan en primavera de cada año y se distribuyen en CD-ROM, por ejemplo. En su lugar, cada parte (microservicio):

• Funciona de forma autónoma para contribuir al conjunto
• Puede actualizarse de forma moderna de desarrollo e integración continua (CI/CD)

(Explora las mejores prácticas de microservicios que ayudarán a te Obtén funcionar con éxito.)

Arquitectura monolítica vs arquitectura de microservicios

El patrón arquitectónico monolítico ha sido el estilo arquitectónico utilizado en el pasado, antes de Kubernetes y la época de los servicios en la nube. En una arquitectura monolítica, el software están una única aplicación distribuida en un CD-ROM, lanzada una vez al año con las últimas actualizaciones. Ejemplos son Photoshop CS6 o Microsoft 2008.

Ese estilo era la forma estándar de construir software. Pero a medida que la tecnología ha evolucionado, también el estilo arquitectónico debe avanzar. En una era de Kubernetes y flujos de trabajo CI/CD, la arquitectura monolítica se encuentra con muchas limitaciones: las empresas necesitan impulsar los microservicios. Características de una arquitectura monolítica:

• Los cambios son lentos
• Los cambios son costosos
• Difícil adaptarse a una línea de productos específica o cambiante

Las estructuras monolíticas Haz que los cambios en la aplicación sean extremadamente lentos. Modificar solo una pequeña sección de código puede requerir una versión completamente reconstruida y desplegada del software. (Conoce las complejidades de la modernización de aplicaciones y la refactorización de código.) Si los desarrolladores desean escalar ciertas funciones de una aplicación, deben escalar toda la aplicación, complicando aún más los cambios y actualizaciones. Los microservicios ayudan a resolver estos desafíos.

Ventajas de los microservicios

Las aplicaciones construidas como un conjunto de componentes modulares independientes son más fáciles de probar, mantener y entender. Permite a las organizaciones:

• Aumentar la agilidad
• Mejorar los flujos de trabajo
• Reducir el tiempo que se tarda en mejorar la producción

Aunque cada componente independiente aumenta la complejidad, también puede contar con capacidades adicionales de monitorización para combatirla. Aquí son los beneficios más comunes de los microservicios y por qué tantas empresas ya los utilizan.

Independencia de los desarrolladores

A cada microservicio a menudo se le asigna un solo equipo de desarrollo para mantenerlo. Por tanto, están mayor libertad e independencia para los desarrolladores. Los equipos pequeños que son trabajando en paralelo pueden iterar más rápido que los equipos grandes. Cuando un solo servicio gana popularidad, el equipo más pequeño también puede escalar los servicios por sí mismo sin tener que esperar a un equipo más grande y complejo.

Aislamiento y resiliencia

Si alguno de los componentes falla, debido a problemas como tecnología obsoleta o incapacidad para desarrollar más el código, los desarrolladores son capaces de poner en marcha otro componente mientras el resto de la aplicación sigue funcionando de forma independiente. Esta capacidad da a los desarrolladores la libertad de desarrollar y desplegar servicios según sea necesario, sin tener que esperar decisiones sobre toda la aplicación.

Escalabilidad

Como los microservicios son compuestos por componentes mucho más pequeños, pueden consumir menos recursos y, por tanto, escalar más fácilmente para satisfacer la creciente demanda de ese componente específico. Como resultado de su aislamiento, los microservicios pueden funcionar correctamente incluso durante grandes cambios de tamaño y volumen, lo que los hace ideales para empresas que trabajan con una amplia gama de plataformas y dispositivos.

Desarrollo autónomo

A diferencia de los monolitos, los componentes individuales son mucho más fáciles de encajar en Pipelines de entrega continua y escenarios de despliegue complejos. Solo el servicio preciso necesita ser modificado y redesplegado cuando están necesario un cambio. Si un servicio falla, los demás seguirán funcionando de forma independiente. Su naturaleza autónoma beneficia a los equipos porque:

• Permite la escalada y el desarrollo
• No requiere mucha coordinación con otros equipos

Los microservicios son una ventaja particular cuando las empresas se distribuyen más y los trabajadores trabajan más en remoto.

Relación con el negocio

Las arquitecturas de microservicios son divididas a lo largo de los límites del dominio empresarial, organizadas en torno a capacidades como logística, facturación, etc. Esto aumenta la independencia y la comprensión en toda la organización: diferentes equipos son capaces de utilizar un producto específico y luego poseerlo y mantenerlo durante toda su vida útil.

Evolutiva

Cualquier arquitectura de microservicios están altamente evolutiva. Los microservicios son una excelente opción para situaciones en las que los desarrolladores no pueden predecir completamente a qué dispositivos accederá la aplicación en el futuro. También permiten cambios rápidos y controlados en el software sin ralentizar la aplicación en su conjunto, por lo que te pueden ser más iterativos en el desarrollo de funciones y nuevos productos.

Desventajas de los microservicios

Por supuesto, la arquitectura de microservicios conlleva una curva de aprendizaje. Los usuarios primerizos pueden tener dificultades para determinar:

• El tamaño de cada microservicio
• Límites óptimos y puntos de conexión entre microservicios
• El marco adecuado para integrar servicios

De forma más amplia, los microservicios presentan estos inconvenientes:

• Mayor complejidad
• Más caro
• Mayores riesgos de seguridad

Mayor complejidad

Ante todo, los microservicios son un sistema mucho más complicado. Tiene una curva de aprendizaje que puede ser pronunciada de ascender, pero una vez aprendida, como en la mayoría de las cosas, puede usarse con facilidad. Las nuevas soluciones no siempre son mejores, y están culpa de muchos consultores e ingenieros jóvenes que intentan resolver diferentes problemas con las mismas soluciones. La arquitectura de microservicios no siempre están la mejor solución para una aplicación. Para algunos puede ser demasiado compleja de lo que están necesario.

Más caro

Los microservicios también pueden ser más costosos. Normalmente funcionan en sus propios entornos con sus propias CPUs. Funcionan mediante llamadas API que tienen un coste. Y, por último, cuanto más complicado es el entorno, se necesita un equipo de ingenieros capaces de construirlo, así que los costes de mano de obra son mayores.

Mayores riesgos de seguridad

Por último, dado que los microservicios existirán a través de diferentes entornos en distintas máquinas en ejecución con distintas llamadas a la API, ofrecen más puntos de contacto para que un atacante Obtén y dañe el sistema.

Los microservicios soportan DevOps

Al final, los microservicios son parte del cambio integral hacia DevOps hacia el que muchas organizaciones son trabajando. Los entornos DevOps fomentan colaboraciones sólidas entre los equipos de desarrollo y operaciones para Haz que TI sea más ágil, así que el negocio también está ágil. Los microservicios son simplemente una tecnología para usar. En cambio, forman parte de un concepto más amplio que las organizaciones deben adoptar cultura, conocimientos y estructuras para los equipos de desarrollo en apoyo a los objetivos empresariales.

Lecturas relacionadas

• BMC DevOps Blog
• Microservicios vs Miniservicios: Elegir el marco adecuado
• Microservicios vs Serverless: ¿Cuál es la diferencia?
• Kubernetes Guide, una serie de artículos y tutoriales
• Kubernetes vs Docker Swarm: Comparando herramientas de orquestación de contenedores
• Roles y responsabilidades de Ingeniero DevOps

Estas publicaciones son mías y no representan necesariamente la posición, estrategias u opinión de BMC.