Header Ads Widget

Ticker

6/recent/ticker-posts

Arquitectura de microservicios: lo bueno, lo malo y lo que podría estar haciendo mejor

Ya no es una aplicación para gobernarlos a todos. Desde la perspectiva de la experiencia del usuario, la industria ha alcanzado lo que el informante web David Strom llama un modelo "más barato, de pago por bebida, [en el que] no es necesario implementar un entorno informático o un dispositivo de punto final en particular; ahora es su teléfono o sus tabletas ". Por el lado del consumidor, no solo ofrecemos plataformas gigantes como Salesforce, sino que estamos profundizando para agregar dimensión, lo que permite a los usuarios seleccionar y elegir sus flujos de trabajo. Cada vez más, los consumidores demandan estas "microaplicaciones" o "aplicaciones registradas".

En el backend, está sucediendo una tendencia similar con los desarrolladores y el patrón de diseño de arquitectura de software comúnmente llamado microservicios , donde las aplicaciones complejas se componen de pequeños procesos y servicios independientes, cada uno organizado en torno a capacidades individuales. Estos microservicios se comunican entre sí a través de interfaces de rendimiento de aplicaciones o API independientes del idioma . Como reflejo de la tendencia del consumidor, estos servicios son pequeños y se centran en completar tareas singulares.

Este documento técnico funciona para identificar qué son los microservicios, cuándo funciona la estrategia y cuándo simplemente no. También ofreceremos métodos para trabajar alrededor de  cinco barreras comunes a la arquitectura de microservicios .

Ya no es una aplicación para gobernar el mundo

“En el pasado, y en realidad todavía hoy, la mayoría de los sistemas comenzaron como un sistema monolítico, lo que básicamente significa que la aplicación completa existe en una única base de código y se implementa y, lo que es más importante, se escala como una sola unidad”, dijo Tammer Saleh, director de producto para Pivotal Cloud Foundry Services , durante su charla en la Cumbre de Plataformas Nórdicas API 2014 en Estocolmo. Usualmente utilizado en aplicaciones empresariales, un monolito es una acción ejecutable única en la aplicación del lado del servicio. Estas aplicaciones monolíticas construidas como unidades individuales han sido el estilo arquitectónico predominante desde hace algún tiempo.

Evitando las normas anteriores, Cloud Foundry ahora se une a Amazon, Netflix y The Guardian para conformar la primera ola de implementación corporativa de la arquitectura de microservicios .

Figura 1: Monolitos y microservicios.  Cortesía de James Lewis y Martin Fowler

Figura 1: Monolitos y microservicios. Cortesía de James Lewis y Martin Fowler

¿Por qué la gente se alejaría de estas aplicaciones monolíticas construidas como unidades individuales? Bueno, al igual que los gobiernos, las capas autónomas más desconectadas integradas en un propósito, más rígido, inflexible e inmutable puede ser el proceso, lo que aumenta la posibilidad de que todo el sistema colapse debido a un pequeño problema. Una aplicación monolítica también es más difícil de escalar, ya que se debe implementar un pequeño cambio en todos los procesos.

Lea también: Cómo administrar la seguridad de la API (ya sea monolito o microservicio)

¿Qué es un microservicio?

Los defensores de los desarrolladores de software James Lewis y Martin Fowler dieron la mejor definición que pudimos encontrar para este patrón arquitectónico cada vez más popular:

“El estilo arquitectónico de microservicios es un enfoque para desarrollar una sola aplicación como un conjunto de pequeños servicios, cada uno ejecutándose en su propio proceso y comunicándose con mecanismos ligeros, a menudo una API de recursos HTTP. Estos servicios se basan en las capacidades comerciales y se pueden implementar de forma independiente mediante una maquinaria de implementación totalmente automatizada. Existe un mínimo de administración centralizada de estos servicios, que pueden estar escritos en diferentes lenguajes de programación y utilizar diferentes tecnologías de almacenamiento de datos ".

Si bien los microservicios son más un concepto que una arquitectura predefinida con requisitos específicos, Lewis y Fowler dicen que hay ciertos atributos que normalmente vienen con los microservicios , que incluyen:

  • Componentización como servicio : reunir determinados componentes para realizar un servicio personalizado.
  • Organized Around Business Capabilities : capacidades de segregación para áreas comerciales específicas como la interfaz de usuario y las integraciones externas.
  • El proceso de desarrollo se basa en productos, no en proyectos : siguiendo el mensaje de Amazon “come tu propia comida para perros”, los desarrolladores se quedan con el software durante la vida útil del producto.
  • Smart Endpoints y Dumb Pipes : cada microservicio está lo más desacoplado posible con su propia lógica de dominio.
  • Gobernanza descentralizada : permite que la elección del desarrollador se base en los lenguajes preferidos para cada componente.
  • Gestión de datos descentralizada : tener cada etiqueta de microservicio y manejar los datos de forma diferente.
  • Automatización de la infraestructura : incluida la implementación automatizada en el proceso.
  • Diseño para fallas : lo que significa que deben realizarse más pruebas continuas de "qué pasaría si" para prepararse para la falla.

¿Dónde ganan los microservicios?

A medida que nos adentramos en un mundo y una experiencia de usuario más especializados, los microservicios, de alguna manera, también mejoran la experiencia del desarrollador , lo que le permite hacer crecer su negocio más rápidamente.

Cada vez más personas acuden en masa para probar la arquitectura de microservicios porque su modularidad de servicios pequeños, enfocados y cuasi independientes permite a las empresas implementar y escalar servicios con mayor facilidad. Esta segmentación también permite que los equipos más pequeños creen bases de código más pequeñas.

Los microservicios también se prestan a procesos de desarrollo de software ágiles , scrum y de entrega continua con ciclos de vida más cortos. Esta arquitectura se distingue de la arquitectura orientada a servicios (SOA) porque cada microservicio solo pertenece a una aplicación, no a varias.

¿A dónde van los microservicios y qué puede hacer usted?

Dado que son inherentemente individuales, los microservicios traen consigo su propio conjunto de problemas nuevos. Los microservicios a menudo experimentan problemas de compatibilidad , ya que los construyen diferentes equipos sobre diferentes tecnologías. Todo esto puede conducir a un entorno inestable en el que las personas están construyendo en diferentes direcciones. Para relacionar estas partes, es posible que se requieran soluciones alternativas extensas , que en realidad pueden tardar más en solucionarse que si se hubieran creado en un entorno monolítico.

Afortunadamente, hay formas de lidiar con estos problemas. Aquí citamos a los expertos sobre sus formas de superar los cinco obstáculos más comunes para el uso de microservicios:

Desafío de microservicios n. ° 1: crear microservicios primero

Los desarrolladores demasiado ansiosos, listos para lanzarse al mercado, pueden comenzar construyendo primero un microservicio y descubrir que se vuelve demasiado complejo y difícil de desarrollar, lo que finalmente hace que la aplicación no sea escalable.

“Ser aburrido es realmente bueno. Puedes escalar mucho siendo aburrido ”, dijo Saleh. "Cuando se cambia a una arquitectura de microservicios, viene con este impuesto constante en su ciclo de desarrollo que lo ralentizará a partir de ese momento", como ocurre con cualquier complejidad.

Con esto en mente, Saleh argumenta que las personas aún deberían comenzar con esa aplicación gigante y luego extraer información en microservicios más pequeños una vez que la aplicación sea estable.

Por supuesto, con los microservicios, las piezas individuales deben tener una comunicación mínima entre sí, que es donde sugiere crear un guardián para que solo un servicio pueda contactar con el esquema de la base de datos a la vez. Pero esto trae su propio conjunto de problemas cuando los servicios y las API con las que se comunican tienen su propio idioma, lo que puede llevar a una implementación de pasos bloqueados, tiempo de inactividad y la preocupación de un bloqueo completo al volver a implementar.

Saleh ofrece lo que él llama la solución bastante dolorosa de las pautas de control de versiones semánticas para permitir una implementación continua. El desarrollador de front-end francés Hugo Giraudel ofrece la mejor explicación de SemVer , un sistema de tres componentes de la siguiente manera:

  • X representa una versión principal, para cualquier cosa que probablemente rompa la API existente
  • Y representa una versión secundaria, para implementar una nueva función de forma compatible con versiones anteriores
  • Z representa un parche, para corregir errores

El sistema lo ayuda a aclarar el lanzamiento de la API o el microservicio como XYZ, lo que hace que la versión 2.1.0 sea un cambio mucho mayor que 1.1.9, que se asignaría para la corrección de errores. Esto le permite catalogar versiones, identificar parches y ayudar a guiar las versiones principales y secundarias de su equipo.

Saleh admite que el mantenimiento de registros puede ser tedioso, pero “esto es parte del dolor inherente de construir una arquitectura de microservicios. Lo que obtienes de esto es que puedes ampliar tu equipo de ingeniería [y] puedes escalar tu aplicación mucho más fácilmente ".

Desafío de microservicios n. ° 2: barreras de información para la productividad

Como escribió el gerente de software Richard Clayton sobre la experiencia de su equipo, los microservicios pueden poner barreras artificiales a la productividad. “Decidimos dividir el backend en ocho servicios separados y tomamos la mala decisión de asignar servicios a las personas. Esto reforzó la noción de propiedad de servicios específicos por parte de los desarrolladores. Debido a que los servicios eran propiedad de personas, los desarrolladores comenzaron a quejarse de que el Servicio A estaba bloqueado por tareas del Servicio B ”, dice. “Esta falta de preocupación se convirtió en un muy mal hábito; dejamos de intentar comprender lo que estaban haciendo nuestros compañeros a pesar de que éramos responsables de revisar sus solicitudes de extracción ... Los desarrolladores perdieron de vista los objetivos del sistema en favor de los objetivos de sus servicios individuales ".

Clayton también dice que, si bien los microservicios están destinados a construirse y escalarse de forma independiente, existe un fuerte deseo de compartir código. "Puede replicar la funcionalidad en todos los servicios y aumentar la carga de mantenimiento, o necesita construir bibliotecas compartidas con cuidado y tratar los conflictos de dependencia que puedan surgir".

De manera similar, Selah menciona que aunque los microservicios permiten una tecnología única personalizada para cada elemento, los peligros operativos de las partes incongruentes pueden aumentar el potencial de fallas del sistema, lo que genera tensión en un equipo que no está listo para ser destruido por una nueva arquitectura.

¿Cómo puede su equipo superar esto? Bueno, Clayton argumenta que los microservicios no deberían ser la arquitectura de facto. Si su equipo ya tiene problemas de comunicación, es una forma segura de fallar. También sigue el consejo de Saleh al recomendar que cualquier microservicio debe mantenerse simple, evitando conscientemente el hábito natural de ser granular desde el principio. Y recomienda que cree su microservicio sobre una plataforma como servicio (PaaS) que permitirá una mejor comunicación entre microservicios, al menos en el back-end.

Desafío de microservicios n. ° 3: ¿Cómo se encuentran sus servicios entre sí?

Está construyendo, implementando, escalando y evolucionando cada una de estas capacidades comerciales por separado, pero deben poder comunicarse entre sí para crear flujos de trabajo lógicos y un producto terminado completo que, desde la perspectiva del usuario final, es indistinguible de la aplicación monolítica.

Saleh dice que la mayoría de las veces los desarrolladores intentan codificar las ubicaciones en el código fuente, pero un cambio en la ubicación de sus servicios requiere cambios en su base de código, lo que conduce a una serie de otros problemas.

¿Cuál es una mejor manera de superar estos desafíos para que un microservicio encuentre otro? Tiene dos opciones: protocolo de descubrimiento de servicios o un enrutador centralizado . Ambos requieren registro y cancelación del registro, así como alta disponibilidad y escalabilidad. A partir de ahí, depende de usted decidir cuál se adapta a su ciclo de vida de desarrollo.

El descubrimiento de servicios permite una detección automática de los servicios ofrecidos y dirige un servicio hacia el otro, mientras el enrutador trabaja entre los sistemas. Si bien el descubrimiento de servicios le dice dónde están las cosas, el enrutador centralizado en realidad está enviando todo el tráfico. El enrutador está construido de manera muy transparente y expuesto externamente, pero es mucho más desafiante de construir que el servicio de descubrimiento, donde no es necesario enrutar todos los datos.

Desafío de microservicios n. ° 4: ¿Cómo se pueden comunicar los servicios entre sí?

Dado que cada pieza funciona de forma independiente, existe el riesgo de latencia cuando se junta cada pieza. Si bien el objetivo de los microservicios es que pueden trabajar de forma independiente, deben trabajar juntos, lo que puede ser un desafío repetido. Particularmente cuando muchos servicios están haciendo llamadas a muchos otros, puede tener una "pila de perros" de información: cuando un servicio deja de funcionar mientras que los otros servicios de conexión no tienen ningún mecanismo de tiempo de espera, eventualmente toda la aplicación colapsará.

Saleh dice que puede crear un disyuntor que actúe como un servicio de descubrimiento, donde un microservicio se da cuenta de que otro está "enfermo" y notifica al disyuntor principal. A partir de ese momento, un microservicio podrá verificar el descubrimiento del servicio para determinar si el microservicio al que está conectado está roto para evitar que se realicen llamadas hacia o desde dicho microservicio. Saleh recomienda establecer un "tiempo de espera" de unos diez minutos.

Desafío de microservicios n. ° 5: los datos descentralizados no siempre son positivos

Tener una gestión de datos descentralizada ve dos caras de la misma moneda: permite que los equipos trabajen de forma independiente y que la aplicación se amplíe más rápidamente, pero la forma en que cada equipo cuantifica las cosas puede resultar confusa. Como lo expresaron Lewis y Fowler , “Significa que el modelo conceptual del mundo diferirá entre sistemas. Este es un problema común cuando se integra en una gran empresa: la "vista de ventas" de un cliente será diferente de la "vista de soporte". Es posible que algunas cosas que se denominan 'clientes' en la 'vista de ventas' no aparezcan en la 'vista de asistencia' ". Cuando los datos se administran por separado, la semántica realmente podría hacer o deshacer una actualización ".

Según Lewis y Fowler, una buena manera de superar este obstáculo, que reside entre microservicios y con API externas, es a través del diseño basado en dominios . DDD divide y reagrupa dominios complejos en múltiples contextos delimitados, que luego traza la relación entre ellos.

También puede optar por gestionar las incoherencias mediante el uso de transacciones que prueben la integridad de las interacciones antes de publicar una actualización. Sin embargo, las transacciones distribuidas son muy difíciles de implementar.

Lewis y Fowler dicen que ninguna de estas correcciones es perfecta, pero "la compensación vale la pena siempre que el costo de corregir los errores sea menor que el costo de la pérdida de negocios con una mayor coherencia".

En conclusión: ¿Son los microservicios adecuados para su aplicación y su equipo?

Resumamos los beneficios y los inconvenientes de usar una arquitectura de microservicios en lugar del tipo monolítico más común. Luego, te dejaremos decidir cuál es la adecuada para tu aplicación y tu equipo:

¿Cómo un microservicio eclipsa a un monolito?

  1. Hace que su aplicación sea más escalable con equipos más pequeños.
  2. Permite la modularidad y está más abierto al cambio en general.
  3. Utiliza una base de código más pequeña.

¿Cuáles son las limitaciones de la arquitectura de microservicios?

  1. Puede causar problemas de comunicación entre diferentes partes de la aplicación y dentro de su equipo.
  2. Posteriormente, requiere un mayor esfuerzo para catalogar, probar y corregir incompatibilidades.
  3. Aún debe construir el monolito antes de construir los microservicios sobre él.


Para obtener más información, vea a  Tammer Saleh de Pivotal Software dar una charla sobre arquitectura de microservicios.


Ahora cuéntanos tu experiencia. ¿Ya experimentaste con microservicios? ¿Cómo reaccionó su equipo a la reestructuración? ¿Tu aplicación fue más o menos estable? ¡Cuéntanos tu historia a continuación!

Publicar un comentario

0 Comentarios