Josh Evans habla sobre el mundo caótico y colorido de los microservicios de Netflix, comenzando con lo más básico: la anatomía de los microservicios, los desafíos asociados con los sistemas distribuidos y sus beneficios. Sobre esta base, explora las prácticas culturales, arquitectónicas y operativas que conducen al dominio de los microservicios.
A diferencia de la deriva operativa, la introducción de nuevos lenguajes para la internacionalización de servicios y nuevas tecnologías como los contenedores son decisiones conscientes para agregar nueva complejidad al entorno. Mi equipo de operaciones estandarizó la mejor hoja de ruta tecnológica para Netflix, que se basó en las mejores prácticas predefinidas basadas en Java y EC2, pero a medida que el negocio creció, los desarrolladores comenzaron a agregar nuevos componentes como Python, Ruby, Node-JS y Docker.
Estoy muy orgulloso de haber sido los primeros en defender que nuestro producto funcione excelente sin esperar las quejas de los clientes. Todo comenzó bastante simple: teníamos programas operativos en Python y algunas aplicaciones administrativas en Ruby, pero las cosas se pusieron mucho más interesantes cuando nuestros desarrolladores web anunciaron que iban a deshacerse de la JVM y trasladarían la web. Aplicación a la plataforma de software Node.js. Después de la introducción de Docker, las cosas se volvieron mucho más complejas. Seguimos la lógica y las tecnologías que se nos ocurrieron se hicieron realidad cuando las implementamos para los clientes porque tenían mucho sentido. Te diré por qué esto es así.
API Gateway en realidad tiene la capacidad de integrar excelentes scripts que pueden actuar como puntos finales para los desarrolladores de UI. Convertiron cada uno de estos scripts de tal manera que después de realizar cambios pudieran implementarlos en producción y luego en los dispositivos de los usuarios, y todos estos cambios se sincronizaron con los puntos finales que se ejecutaban en la puerta de enlace API.
Sin embargo, esto repitió el problema de crear un nuevo monolito donde el servicio API estaba sobrecargado con código de tal manera que ocurrían varios escenarios de falla. Por ejemplo, se eliminaron algunos puntos finales o los scripts generaron aleatoriamente tantas versiones de algo que ocuparon toda la memoria disponible del servicio API.
Era lógico tomar estos puntos finales y sacarlos del servicio API. Para hacer esto, creamos componentes de Node.js que se ejecutaban como pequeñas aplicaciones en contenedores Docker. Esto nos permitió aislar cualquier problema y falla causado por estas aplicaciones de nodo.
El costo de estos cambios es bastante elevado y consta de los siguientes factores:
- Herramientas de productividad. La gestión de nuevas tecnologías requirió nuevas herramientas porque el equipo de UI, al utilizar muy buenos scripts para crear un modelo eficiente, no tuvo que dedicar mucho tiempo a administrar la infraestructura, solo tuvo que escribir scripts y verificar su funcionalidad.
Información y clasificación de oportunidades: un ejemplo clave son las nuevas herramientas necesarias para descubrir información sobre los factores que influyen en el rendimiento. Era necesario saber cuánto estaba ocupado el procesador, cómo se estaba utilizando la memoria, y recopilar esta información requería diferentes herramientas. - Fragmentación de imágenes base: la AMI base simple se ha vuelto más fragmentada y especializada.
- Gestión de nodos. No existe una arquitectura o tecnología disponible que le permita administrar nodos en la nube, por lo que creamos Titus, una plataforma de administración de contenedores que proporciona implementación de contenedores escalable y confiable e integración en la nube con Amazon AWS.
- Duplicación de una biblioteca o plataforma. Proporcionar nuevas tecnologías con la misma funcionalidad principal de la plataforma requería duplicarla en herramientas de desarrollo Node.js basadas en la nube.
- Curva de aprendizaje y experiencia industrial. La introducción de nuevas tecnologías crea inevitablemente nuevos desafíos que es necesario superar y aprender de ellos.
Por lo tanto, no podíamos limitarnos a un “camino pavimentado” y teníamos que construir constantemente nuevas formas de hacer avanzar nuestras tecnologías. Para mantener bajos los costos, limitamos el soporte centralizado y nos concentramos en la JVM, los nuevos nodos y Docker. Priorizamos el impacto efectivo, informamos a los equipos sobre el costo de sus decisiones y los alentamos a buscar formas de reutilizar las soluciones de alto impacto que ya habían desarrollado. Utilizamos este enfoque al traducir el servicio a idiomas extranjeros para entregar el producto a clientes internacionales. Los ejemplos incluyen bibliotecas cliente relativamente simples que se pueden generar automáticamente, de modo que es bastante fácil crear una versión de Python, una versión de Ruby, una versión de Java, etc.
Buscábamos constantemente oportunidades para utilizar tecnologías probadas que habían demostrado su eficacia en un lugar y en otras situaciones similares.
Hablemos del último elemento: cambios o variaciones. Mira como el consumo de nuestro producto varía de forma desigual según el día de la semana y según la hora a lo largo del día. Se podría decir que las 9 a.m. es el momento más difícil para Netflix, cuando la carga en el sistema alcanza su máximo.
¿Cómo podemos lograr una alta velocidad de implementación de innovaciones de software, es decir, realizar constantemente nuevos cambios en el sistema, sin causar interrupciones en la prestación del servicio y sin crear inconvenientes a nuestros clientes? Netflix logró esto mediante el uso de Spinnaker, una nueva plataforma global de gestión y entrega continua (CD) basada en la nube.
Fundamentalmente, Spinnaker fue diseñado para integrar nuestras mejores prácticas de modo que, a medida que implementamos componentes en producción, podamos integrar la salida directamente en nuestra tecnología de entrega de medios.
Hemos podido incorporar dos tecnologías en nuestro proceso de entrega que valoramos mucho: análisis canary automatizado e implementación por etapas. El análisis Canary significa que dirigimos una pequeña cantidad de tráfico a la nueva versión del código y pasamos el resto del tráfico de producción a través de la versión anterior. Luego comprobamos cómo el nuevo código afronta la tarea, mejor o peor que el existente.
Un lanzamiento escalonado significa que si un lanzamiento en una región tiene problemas, pasamos a un lanzamiento en otra región. En este caso, la lista de verificación antes mencionada debe incluirse en el proceso de producción. Le ahorraré algo de tiempo y le recomiendo que consulte mi charla anterior, Ingeniería de operaciones globales de Netflix en la nube, si está interesado en profundizar en este tema. La grabación de video del discurso se puede ver siguiendo el enlace en la parte inferior de la diapositiva.
Al final de la charla hablaré brevemente sobre la organización y arquitectura de Netflix. Al principio teníamos un esquema llamado Entrega Electrónica, que fue la primera versión de transmisión de medios NRDP 1.x. El término "backstream" se puede utilizar aquí porque inicialmente el usuario sólo podía descargar contenido para reproducirlo posteriormente en el dispositivo. La primera plataforma de entrega digital de Netflix, allá por 2009, se parecía a esto.
El dispositivo del usuario contenía la aplicación Netflix, que constaba de una interfaz UI, módulos de seguridad, activación y reproducción de servicios, basada en la plataforma NRDP - Netflix Ready Device Platform.
En aquel momento la interfaz de usuario era muy sencilla. Contenía lo que se llamaba Queque Reader, y el usuario iba al sitio para agregar algo a Queque y luego ver el contenido agregado en su dispositivo. Lo positivo fue que el equipo de front-end y el equipo de back-end pertenecían a la misma organización de entrega electrónica y tenían una estrecha relación de trabajo. La carga útil se creó en base a XML. Paralelamente se creó la API de Netflix para el negocio de DVD, que incentivó a aplicaciones de terceros a dirigir el tráfico a nuestro servicio.
Sin embargo, la API de Netflix estaba bien preparada para ayudarnos con una interfaz de usuario innovadora, que contenía metadatos de todo el contenido, información sobre qué películas estaban disponibles, lo que creó la capacidad de generar listas de observación. Contaba con una API REST genérica basada en el esquema JSON, Código de Respuesta HTTP, el mismo que se usa en la arquitectura moderna, y un modelo de seguridad OAuth, que era lo que se requería en ese momento para una aplicación front-end. Esto permitió pasar de un modelo público de entrega de contenidos en streaming a uno privado.
El problema con la transición fue la fragmentación, ya que ahora nuestro sistema operaba dos servicios basados en principios de operación completamente diferentes: uno en Rest, JSON y OAuth, el otro en RPC, XML y un mecanismo de seguridad de usuario basado en el sistema de token NTBA. Esta fue la primera arquitectura híbrida.
Básicamente, había un firewall entre nuestros dos equipos porque inicialmente la API no escalaba muy bien con NCCP y esto generó fricciones entre los equipos. Las diferencias estaban en los servicios, protocolos, circuitos, módulos de seguridad y los desarrolladores a menudo tenían que cambiar entre contextos completamente diferentes.
En este sentido, tuve una conversación con uno de los ingenieros superiores de la empresa, a quien le hice la pregunta: "¿Cuál debería ser la arquitectura adecuada a largo plazo?" y él me hizo la contrapregunta: "Probablemente usted esté más preocupado sobre las consecuencias organizativas: ¿qué sucede si integramos estas cosas y rompen lo que hemos aprendido a hacer bien? Este enfoque es muy relevante para la Ley de Conway: "Las organizaciones que diseñan sistemas están limitadas por un diseño que replica la estructura de comunicación de esa organización". Esta es una definición muy abstracta, por lo que prefiero una más específica: "Cualquier pieza de software refleja la estructura organizacional que la creó". Esta es mi cita favorita de Eric Raymond: "Si tienes cuatro equipos de desarrolladores trabajando en un compilador, terminarás con un compilador de cuatro pasos". Bueno, Netflix tiene un compilador de cuatro pasos y así es como trabajamos.
Podemos decir que en este caso la cola mueve al perro. Nuestra primera prioridad no es la solución, sino la organización; es la organización la que impulsa la arquitectura que tenemos. Poco a poco, de una mezcolanza de servicios, pasamos a una arquitectura que llamamos Blade Runner, porque aquí estamos hablando de servicios de borde y la capacidad de NCCP para separarse e integrarse directamente en el proxy Zuul, la puerta de enlace API y la funcionalidad correspondiente. Las “piezas” se han convertido en nuevos microservicios con funciones más avanzadas de seguridad, reproducción, clasificación de datos, etc.
Por tanto, se puede decir que las estructuras departamentales y la dinámica empresarial juegan un papel importante en la configuración del diseño del sistema y son un factor que promueve o impide el cambio. La arquitectura de microservicios es compleja y orgánica, y su salud se basa en la disciplina y el caos introducido.
Algo de publicidad
Gracias por estar con nosotros. ¿Te gustan nuestros artículos? ¿Quieres ver más contenido interesante? Apóyanos haciendo un pedido o recomendándonos a amigos, , un análogo único de servidores de nivel de entrada, que fue inventado por nosotros para usted: (disponible con RAID1 y RAID10, hasta 24 núcleos y hasta 40GB DDR4).
Dell R730xd 2 veces más barato en el centro de datos Equinix Tier IV en Amsterdam? Solo aqui ¡en los Paises Bajos! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - ¡desde $99! Leer acerca de
Fuente: habr.com