Adopción de microservicios en Netflix: Lecciones de diseño arquitectónico

En algunas publicaciones de blog recientes, explicamos por qué creemos que es crucial adoptar una arquitectura de aplicação de cuatro niveles en la que las aplicações se desarrollan e implementan como conjuntos de microservicios . Cada vez es más evidente que si se siguen utilizando procesos de desarrollo y arquitecturas de aplicação que funcionaban bien hace diez años, simplemente no se puede avanzar lo suficientemente rápido para capturar y mantener el interés de los usuarios móviles, que pueden elegir entre un número cada vez mayor de aplicaciones.

El cambio a una arquitectura de microservicios crea oportunidades interesantes en el mercado para las empresas. Para los arquitectos y desarrolladores de sistemas, promete un nivel de control y velocidad sin precedentes a la vez que ofrecen nuevas experiencias web innovadoras a los clientes. Pero a un ritmo tan vertiginoso, puede parecer que no hay mucho margen de error. En el mundo real, no puedes dejar de desarrollar e implementar tus aplicaciones a medida que reestructuras los procesos para hacerlo. Usted sabe que su éxito futuro depende de la transición a una arquitectura de microservicios, pero ¿cómo lo hace realmente?

Afortunadamente para nosotros, varios de los primeros usuarios de microservicios ahora están compartiendo generosamente su experiencia en el espíritu del código abierto, no solo en forma de código publicado, sino también en presentaciones en conferencias y publicaciones de blogs. Netflix es un ejemplo claro. Como director de ingeniería web y luego arquitecto de la nube, Adrian Cockcroft supervisó la transición de la empresa de un modelo de desarrollo tradicional con 100 ingenieros que producían una aplicação monolítica de alquiler de DVD a una arquitectura de microservicios con muchos equipos pequeños responsables del desarrollo de extremo a extremo de cientos de microservicios que trabajan juntos para transmitir entretenimiento digital a millones de clientes de Netflix todos los días. Cockcroft, actualmente miembro de tecnología en Battery Ventures, es un destacado evangelista de los microservicios y las arquitecturas nativas de la nube y forma parte del consejo asesor técnico de NGINX.

En una serie de dos publicaciones de blog, presentaremos las principales conclusiones de dos charlas que Cockcroft dio el año pasado, en la primera conferencia anual NGINX en octubre y en una reunión de microservicios de Silicon Valley un par de meses antes. (También vale la pena ver las grabaciones de vídeo completas).

• Esta publicación define la arquitectura de microservicios y describe algunas de las mejores prácticas para diseñar una.
• Adopción de microservicios en Netflix: Lecciones para el diseño de equipos y procesos analiza por qué y cómo adoptar una nueva mentalidad para el desarrollo de software y reorganizar sus equipos en torno a ella.

¿Qué es una arquitectura de microservicios?

Cockcroft define una arquitectura de microservicios como una arquitectura orientada a servicios compuesta por elementos débilmente acoplados que tienen contextos delimitados .

Acoplado de forma flexible significa que puedes actualizar los servicios de forma independiente; actualizar un servicio no requiere cambiar ningún otro servicio. Si tienes un montón de servicios pequeños y especializados, pero aún así tienes que actualizarlos juntos, no son microservicios porque no están acoplados de forma flexible. Un tipo de acoplamiento que las personas tienden a pasar por alto a medida que realizan la transición a una arquitectura de microservicios es el acoplamiento de bases de datos, donde todos los servicios se comunican con la misma base de datos y actualizar un servicio significa cambiar el esquema. Necesitas dividir la base de datos y desnormalizarla.

El concepto de contextos delimitados proviene del libro Domain Driven Design de Eric Evans. Un microservicio con un contexto correctamente delimitado es autónomo a los efectos del desarrollo de software. Puede comprender y actualizar el código del microservicio sin saber nada sobre los aspectos internos de sus pares, porque el microservicio y sus pares interactúan estrictamente a través de API y, por lo tanto, no comparten estructuras de datos, esquemas de bases de datos u otras representaciones internas de objetos.

Si ha desarrollado aplicações para Internet, ya está familiarizado con estos conceptos, en la práctica, aunque no por su nombre. La mayoría de las aplicaciones móviles interactúan con varios servicios backend para permitir a sus usuarios compartir contenido en Facebook, obtener indicaciones de Google Maps y encontrar restaurantes en Foursquare, todo dentro del contexto de la aplicación. Si tu aplicación móvil estuviera estrechamente vinculada a estos servicios, antes de publicar una actualización, tendrías que hablar con todos sus equipos de desarrollo para asegurarte de que los cambios no afecten a nada.

Cuando se trabaja con una arquitectura de microservicios, se piensa en otros equipos de desarrollo internos como si fueran esos backends de Internet: como servicios externos con los que el microservicio interactúa a través de API. El “contrato” comúnmente entendido entre microservicios es que sus API son estables y compatibles con versiones posteriores. Así como es inaceptable que la API de Google Maps cambie sin previo aviso y de tal manera que afecte a sus usuarios, su API puede evolucionar pero debe seguir siendo compatible con las versiones anteriores.

Mejores prácticas para diseñar una arquitectura de microservicios

Cockcroft describe su papel como arquitecto de la nube en Netflix no en términos de controlar la arquitectura, sino como el descubrimiento y la formalización de la arquitectura que surgió a medida que los ingenieros de Netflix la construían. El equipo de desarrollo de Netflix estableció varias prácticas recomendadas para diseñar e implementar una arquitectura de microservicios.

Cree un almacén de datos independiente para cada microservicio

No utilice el mismo almacén de datos de backend en todos los microservicios. Quiere que el equipo de cada microservicio elija la base de datos que mejor se adapte al servicio. Además, con un único almacén de datos es muy fácil que los microservicios escritos por diferentes equipos compartan estructuras de bases de datos, quizás con el objetivo de reducir la duplicación del trabajo. Se llega a una situación en la que si un equipo actualiza la estructura de una base de datos, otros servicios que también utilizan esa estructura también deben modificarse.

Separar los datos puede hacer que la administración de datos sea más complicada, porque los sistemas de almacenamiento separados pueden desincronizarse o volverse inconsistentes con mayor facilidad y las claves externas pueden cambiar inesperadamente. Es necesario agregar una herramienta que realice la gestión de datos maestros (MDM) operando en segundo plano para encontrar y corregir inconsistencias. Por ejemplo, podría examinar cada base de datos que almacena identificaciones de suscriptores, para verificar que las mismas identificaciones existan en todas ellas (que no haya identificaciones faltantes o adicionales en ninguna base de datos). Puedes escribir tu propia herramienta o comprar una. Muchos sistemas de gestión de bases de datos relacionales (RDBMS) comerciales realizan este tipo de comprobaciones, pero normalmente imponen demasiados requisitos de acoplamiento y, por lo tanto, no escalan.

Mantenga el código en un nivel de madurez similar

Mantenga todo el código de un microservicio en un nivel similar de madurez y estabilidad. En otras palabras, si necesita agregar o reescribir parte del código en un microservicio implementado que funciona correctamente, la mejor estrategia suele ser crear un nuevo microservicio para el código nuevo o modificado, manteniendo el microservicio existente intacto. [Editor: Esto a veces se conoce como el principio de infraestructura inmutable ]. De esta manera, puede implementar y probar iterativamente el nuevo código hasta que esté libre de errores y alcance la máxima eficiencia, sin riesgo de fallos ni degradación del rendimiento en el microservicio existente. Una vez que el nuevo microservicio sea tan estable como el original, puedes volver a fusionarlos si realmente realizan una sola función juntos o si existen otras eficiencias al combinarlos. Sin embargo, según la experiencia de Cockcroft, es mucho más común darse cuenta de que es necesario dividir un microservicio porque se ha vuelto demasiado grande.

Realice una compilación independiente para cada microservicio

Realice una compilación independiente para cada microservicio, de modo que pueda extraer archivos de componentes del repositorio en los niveles de revisión apropiados para él. A veces, esto conduce a una situación en la que varios microservicios extraen un conjunto similar de archivos, pero en diferentes niveles de revisión. Eso puede hacer que sea más difícil limpiar su base de código al desmantelar versiones de archivos antiguas (porque debe verificar con más cuidado que una revisión ya no se esté utilizando), pero es una compensación aceptable por lo fácil que es agregar nuevos archivos a medida que crea nuevos microservicios. La asimetría es intencional: quieres que introducir un nuevo microservicio, archivo o función sea fácil, no peligroso.

Implementar en contenedores

Implementar microservicios en contenedores es importante porque significa que solo necesitas una herramienta para implementar todo. Mientras el microservicio esté en un contenedor, la herramienta sabe cómo implementarlo. No importa cuál sea el contenedor. Dicho esto, Docker parece haberse convertido rápidamente en el estándar de facto para los contenedores.

Tratar a los servidores como si no tuvieran estado

Trate a los servidores, particularmente aquellos que ejecutan código orientado al cliente, como miembros intercambiables de un grupo. Todos realizan las mismas funciones, por lo que no es necesario preocuparse por ellos individualmente. Su única preocupación es que haya suficientes para producir la cantidad de trabajo que necesita, y puede usar el escalado automático para ajustar los números hacia arriba y hacia abajo. Si uno deja de funcionar, se reemplaza automáticamente por otro. Evite los sistemas “copo de nieve” en los que depende de servidores individuales para realizar funciones especializadas.

La analogía de Cockcroft es que debemos pensar en los servidores como ganado, no como mascotas. Si tienes una máquina en producción que realiza una función especializada, y la conoces por su nombre, y todos se entristecen cuando se estropea, es una mascota. En lugar de eso, deberías pensar en tus servidores como si fueran un rebaño de vacas. Lo que a usted le importa es cuántos galones de leche obtiene. Si un día notas que estás produciendo menos leche de lo habitual, averigua qué vacas no están produciendo bien y reemplázalas.

La arquitectura de entrega de Netflix se basa en NGINX

Netflix es un usuario de NGINX Open Source desde hace mucho tiempo y se convirtió en el primer cliente de NGINX, Inc. después de su incorporación en 2011. De hecho, Netflix eligió NGINX como el corazón de su infraestructura de distribución, Open Connect , una de las redes de distribución de contenido (CDN) más grandes del mundo. Con la capacidad de atender miles, y a veces millones, de solicitudes por segundo, NGINX y NGINX Plus son soluciones óptimas para la entrega HTTP de alto rendimiento y permiten a empresas como Netflix ofrecer experiencias digitales de alta calidad a millones de clientes todos los días.

Grabaciones de vídeo

Entrega rápida
nginx.conf 2014, octubre de 2014

Migración a microservicios, parte 1
Reunión de microservicios de Silicon Valley, agosto de 2014

Migración a microservicios, parte 2
Reunión de microservicios de Silicon Valley, agosto de 2014