La topología y las rutas de las aplicaciones son importantes para gestionar arquitecturas complejas y con la adición de los microservicios y Docker, todos necesitarán estas capacidades.
No hay duda de que las arquitecturas de microservicio están causando furor en el diseño de software. Los profesionales de las tecnologías de la información (TI) y los desarrolladores con quienes hablo están migrando a este patrón de manera muy consistente. Conocí a docenas de prospectos y clientes durante las diez semanas pasadas en AppDynamics y a todos les hice la misma pregunta: ¿está utilizando o está pensando cambiar a los microservicios? Y la respuesta de la mayoría fue ‘sí’. Normalmente, continúo con una pregunta sobre el uso de la tecnología de contenedores (como Docker), y la respuesta es ‘tal vez’. Sospecharía que a medida que maduren los contenedores y se amplíen a otras plataformas, probablemente esa respuesta cambiará.
No voy a explicar los conceptos básicos de los microservicios, pues se habla de ellos en otras partes. El patrón de utilizar APIs, creadas en un inicio para traspasar los límites de las aplicaciones dentro de una sola empresa u organización, ahora se está aprovechando dentro de una sola arquitectura de aplicaciones para brindar funcionalidad. La adopción de microservicios está siendo impulsada por dos fuerzas: la necesidad de agilidad y de velocidad; la recomposición de aplicaciones que permiten la experimentación, y la demanda para soportar nuevas plataformas de entrega como el Internet, el Internet móvil, las aplicaciones nativas y a socios. La definición de estos límites hace posible el desarrollo independiente de microservicios.
Los adoptadores anticipados han identificado varios criterios de diseño, como los de Netflix. En este excelente artículo, Ngnixentrevista aAdrian Cockroft, quien era parte de Netflix y ahora colabora con Battery Ventures(que resulta ser también uno de nuestros principales inversionistas). En este artículo, se habla de la arquitectura y de uno de los temas que me pareció particularmente interesante –desde la perspectiva de las operaciones de TI– fue el almacenamiento back-end separado para cada microservicio. El almacenamiento dispar requiere de una solución o estrategia compleja de gestión de datos maestros para mantener los datos en sincronía. El almacenamiento inconsistente también provoca problemas si surge un desastre y es necesaria la recuperación. El nivel de complejidad para gestionar todos estos backends separados parece ser una receta para la deuda técnica, que es la acumulación de decisiones viejas y posiblemente de corto plazo, que provocan la rigidez de los sistemas. Hablé con Adrian Cockroft sobre este tema específico y me dijo lo siguiente:
«La réplica en los centros de datos se maneja usando Cassandra o Riak para cada almacén de datos; es un plan ortogonal. Mantener las claves foráneas en sincronía en los almacenes de datos puede hacerse por excepciones cuando se detectan inconsistencias (como leer-reparar) o como una tarea por lotes nocturna, usando un escaneo acelerado completo de tablas. Cada almacén de datos es extremadamente sencillo y se mantendrá independientemente. En la práctica, esto es mucho más sencillo que una sola base de datos central con un esquema de ‘fregadero’».
Esto brindó la guía que otras publicaciones no hicieron. Adrian asegura específicamente que el desarrollo debería estar usando una tecnología de almacenamiento de datos estándar. En sus casos de uso, eso sería Cassandra o Riak, para mantener la consistencia desde una perspectiva de soporte. ¿Cuántas empresas desean tener dos plataformas específicas para el almacenamiento de datos? Los innovadores de la Web fueron los pioneros en estas arquitecturas para satisfacer las demandas de servicios y agilizar la velocidad de liberación. Encontré muchas de estas estadísticas, las cuales reúno a continuación:
· Amazon.com llama a entre 100-150 servicios (APIs) para crear una página.
· La arquitectura de microservicios de Netflix atiende 5 mil millones de llamadas API al día, de las cuales el 99.7% de las llamadas son internas. Netflix (2014)
· El tráfico API representa más de 60% del tráfico de nuestro nivel de aplicaciones. Salesforce.com (Octubre de 2013).
Los ingenieros de desarrollo y operaciones (DevOps) y los equipos responsables de operar los microservicios se están dando cuenta de algunas cosas, además del nivel de complejidad y escala creadas por estas nuevas arquitecturas:
─ Es difícil determinar qué servicios están siendo llamados para entregar la funcionalidad de las aplicaciones a un usuario específico.
─ Documentar y/o visualizar la topología fluida de las aplicaciones es algo que pocos han podido hacer.
─ Es casi imposible crear un mapa de la arquitectura o un plano del diseño de los servicios
Los enfoques de monitoreo de hoy consisten en las siguientes estrategias: http://zohararad.github.io/presentations/micro-services-monitoring/
En este plan, los códigos del estatus se registran y se examinan para un microservicio individual. No hay modo de determinar la salud de la aplicación que se está entregando al usuario, lo cual es un problema importante. El diseño entonces asocia esto con otra herramienta para visualización de las métricas básicas del microservicio. Este enfoque ayuda a determinar la salud de cada componente, pero una vez más, este enfoque deficiente es similar a la manera en que el monitoreo de los servidores funciona actualmente, lo cual es completamente inservible. Las vistas que existen en los silos no ofrecen la visibilidad que se requiere para entender la ruta completa de las transacciones. Si hay una falla en el servicio que se deriva en otras fallas del servicio, determinar la causa de raíz es virtualmente imposible debido a la naturaleza asincrónica de los microservicios. A menudo los servicios llaman a servicios adicionales, lo que significa que hay una relación uno a uno entre los servicios: http://eugenedvorkin.com/seven-micro-services-architecture-problems-and-solutions/
Otro enfoque es utilizar varias herramientas distintas para visualizar cada componente individualmente una vez más; este es el problema de raíz de #monitoringsucks: http://www.slideshare.net/nathariel/monitoring-microservices-platform-40373428
El último ejemplo es un patrón común que he observado, pero una vez más consiste en una vista al nivel de componentes que utiliza varias herramientas que reúnen datos de forma independiente. En este caso, la arquitectura consiste en CloudWatch para la infraestructura, Zabbix para el servidor, statsd y Collectd para las métricas (que tienen cabida en Graphite). El resultado son tres consolas, tres herramientas y tres vistas de cada componente. Estas herramientas y consolas no manejan el monitoreo de la infraestructura, ni tocan los datos de rendimiento de las aplicaciones.
Evidentemente, es necesario que se visualice la ruta de los servidores que incluyen la trazabilidad de un extremo a otro para cada interacción, desde el usuario pasando por todos las llamadas de servicios, junto con la infraestructura. AppDynamics ofrece esta capacidad. Aquí se presenta un ejemplo de una arquitectura de microservicios que corren en Docker que son monitoreados con AppDynamics. Este realmente es nuestro entorno de demostración, donde estamos corriendo generadores de carga en Docker junto con cada microservicio para nuestras instancias de aplicaciones de demostración. No publicamos todo, pero parte de él está en nuestro repositorio Docker. Esperamos revelar más detalles DockerCon si nuestras conferencias son seleccionadas.
¿Y aquellos que no quieren pagar por el software? Probablemente usted pagará con gente y tiempo, o con dinero. Si usted evalúa o selecciona AppDynamics, puede implementarse localmente o bajo el modelo de SaaS (y puede cambiar entre ambos modelos de implementación). Adrián Cockroft está trabajando en un nuevo proyecto de código abierto llamado Spigo, el cual visualiza las topologías (la instrumentación es de hecho la parte más difícil, que esto no hace). Este nuevo proyecto de código abierto está construido sobre d3 JavaScript y usted puede ver los primeros ejemplos y descargar el código fuente aquí. Hoy, la herramienta no tiene capacidades en tiempo real, pero llegarán con el tiempo. Las vistas de AppDynamics son también HTML5 y JavaScript, incluyendo nuestro rico mapa topológico. También animamos y mostramos datos detallados sobre el uso y el rendimiento de las rutas de comunicación.
La topología y las rutas de las aplicaciones son importantes para gestionar arquitecturas complejas y con la adición de los microservicios y Docker, todos necesitarán estas capacidades. AppDynamics es la visualización de topologías más avanzada del mercado para gestionar todas estas complejas arquitecturas nuevas y cada vez más populares, pero los proyectos de código abierto como Spigo mejorarán la visualización.