El Maestro de los Microservicios

Algo que realmente me gusta de vivir en la ciudad es el hecho de que est谩 hecha para las masas. A pesar de sus muchos defectos (la lluvia no es una), Seattle est谩 dise帽ado para permitir que cientos de miles de personas pasen sus d铆as ocupados. Cuenta con un sistema de transporte que interconecta diferentes 谩reas, ordena diferentes pol铆ticas de uso del suelo para parques, residencias, comercios y escuelas, y proporciona zonas de estacionamiento restringido. Est谩 dise帽ado para caminar (asumiendo que te gustan las colinas), proporciona f谩cil acceso a los hospitales y est谩 custodiado por los departamentos de polic铆a y bomberos, pero Seattle no fue inicialmente una gran ciudad, su crecimiento es m谩s bien un trabajo en progreso. Como muchas otras ciudades, incluyendo la poderosa Nueva York, Seattle est谩 en constante desarrollo y planificaci贸n para que pueda escalar para apoyar a m谩s gente. Las similitudes entre el urbanismo y la ingenier铆a de software me fascinan, las cuales est谩n bien descritas por Sam Newman en su libro 芦Building Microservices禄. Al igual que las ciudades empezaron como pueblos peque帽os, la mayor铆a de los servicios empezaron como simples servidores sentados bajo el escritorio de alguien, y procesando unos pocos cientos de solicitudes al d铆a. Con el tiempo y si la idea es correcta, un servicio puede llegar a ser popular, lo cual es una gran cosa, excepto que el reto de aumentar la demanda se convierte r谩pidamente en un problema de tratar con las expectativas de los clientes. Esto es similar a c贸mo esperamos un mejor transporte y una aplicaci贸n m谩s eficiente de la ley cuando un pueblo se convierte en una ciudad. Como menciona Yao Yue, la ballena es una historia de creciendo . Twitter comenz贸 con un servicio monol铆tico llamado Monorra铆l , representado como una gigantesca caja de funcionalidad de enorme alcance. Aunque esta podr铆a ser la mejor manera de empezar, Monorriel pronto se volvi贸 demasiado complejo para razonar. La disponibilidad y los problemas de rendimiento lento surgieron a medida que el equipo de ingenier铆a de Twitter crec铆a hasta convertirse en un grupo m谩s grande de personas que a帽ad铆an funciones constantemente. Esto requer铆a m谩s recursos y una arquitectura m谩s basada en principios con un mejor manejo de las fallas. Twitter encubri贸 muy bien los errores de su sistema con la imagen de una ballena fallando. Si algo de eso le suena familiar, quiz谩s uno deber铆a considerar seguir el enfoque de Twitter de abrazar una arquitectura basada en microservicios.La evoluci贸n de una arquitectura monol铆tica en un conjunto de microservicios consiste en dividir una gran caja de I-can-do-lo-todo en cajas m谩s manejables que tienen un alcance de responsabilidad. Tambi茅n se trata de dividir los equipos en equipos m谩s peque帽os que puedan centrarse en un subconjunto de esos servicios (la ley de Conway). Los servicios resultantes son aut贸nomos -como los equipos que los gestionan-, por lo que pueden ser desplegados de forma independiente. El Maestro de Microservicios (i.e. you ) debe ser capaz de orquestar los principios de separaci贸n de preocupaciones, la cohesi贸n general del sistema, la degradaci贸n de fallos, la seguridad y la privacidad, y he descubierto que el establecimiento de algunos principios de arquitectura clave iniciales y la garant铆a de que se logren pueden ayudar a aliviar algunos de estos desaf铆os. Desde el punto de vista de la ingenier铆a y la preparaci贸n operativa:

  1. El entorno de prueba definitivo . Existen muchas estrategias para realizar pruebas en la producci贸n. Uno de mis favoritos son las pruebas con canarios, una pr谩ctica com煤n en la que el c贸digo menos estable s贸lo se permite a un peque帽o porcentaje del tr谩fico de producci贸n y se 芦hornea禄 durante un per铆odo de tiempo predeterminado, antes de su amplio despliegue.
  2. Despliegue continuo . Idealmente, el tiempo que se tarda desde la facturaci贸n hasta la producci贸n es de horas, no de meses. Llegar hasta all铆 requiere normalmente la construcci贸n de un gasoducto de despliegue totalmente automatizado que sea capaz de progresar de forma segura y fiable.
  3. Ver y aprender . Cualquier caracter铆stica que no incluya el monitoreo b谩sico de su desempe帽o, su utilizaci贸n de recursos o sus casos de fallas inesperadas no puede ser tomada en serio, liber谩ndola es como volar a ciegas, con la esperanza de que s贸lo funcione. En un sistema que se escala a millones de solicitudes por minuto, las cosas que se supone que fallan s贸lo el 0,01% del tiempo fallar谩n una vez por minuto y requerir谩n una reparaci贸n casi inmediata. La esperanza no es una estrategia en ingenier铆a de software, pero los servicios de monitoreo y el aprendizaje de sus datos s铆 lo son.
  4. Mejoras incrementales . Por lo general, evito esperar a que se implemente el sistema perfecto. Es mejor liberar algo peque帽o y mejorarlo con el tiempo.

Desde el punto de vista de la arquitectura interna:

  1. La fuerza de la autonom铆a. Puede sonar no trivial, pero compartir c贸digo que est谩 estrechamente unido a la l贸gica de negocio es un antipatr贸n y deber铆a evitarse a favor de la autonom铆a y la descentralizaci贸n del sistema.
  2. Aceptar cambios de contrato . No es realista esperar que un contrato entre dos servicios no cambie. El soporte de versiones, la compatibilidad con versiones anteriores y la capacidad de actualizaci贸n son esenciales para la estabilidad a largo plazo de cualquier caracter铆stica.
  3. Ir async . Los servicios que gastan recursos esperando respuestas pueden ser un desperdicio. En el mundo de los as铆ncronos, la comunicaci贸n se rige por modelos basados en eventos con servicios de pubs y subwoofers que no esperan. Sin embargo, no hay almuerzo gratis, el diagn贸stico de los sistemas basados en eventos ha demostrado ser un 谩rea desafiante.
  4. No almacene lo que se puede volver a aprender. Los servicios sin estado son f谩ciles de razonar. En muchos casos, se pueden retroceder con un riesgo m铆nimo si su versi贸n m谩s reciente resulta ser inestable. Por otro lado, la reducci贸n de los servicios de estado puede causar m煤ltiples efectos secundarios que son dif铆ciles de entender y aumentan las posibilidades de corrupci贸n de datos. Adem谩s, los datos persistentes suelen requerir modelos de consistencia, alta disponibilidad y recuperaci贸n r谩pida.
  5. Ser resistente . Me gusta mucho la idea de Chaos Monkey de Netflix – un servicio que constantemente provoca fallos controlados en los servicios de Netflix para asegurar que todos los servicios tengan garant铆as de aislamiento de fallos de sonido. El libro de Michael Nygard Release It! recomienda los disyuntores como mecanismos de protecci贸n contra la propagaci贸n de fallas que vale la pena explorar. En resumen, los disyuntores tienen por objeto cortar la comunicaci贸n posterior a un servicio que no est谩 disponible para evitar que se llenen las colas de solicitudes. La comunicaci贸n puede ser restaurada autom谩ticamente una vez que los servicios externos est茅n de nuevo en l铆nea.

En general, creo que la escala es dif铆cil y a menudo subestimada; es un 谩rea que espero que tenga una innovaci贸n dram谩tica en los pr贸ximos a帽os. 驴Te ha gustado este art铆culo? Suscribirse para obtener nuevos mensajes por correo electr贸nico. Cr茅dito de la imagen: Steve Dennis

Etiquetas

MicroserviciosCodificaci贸nArquitectura del softwareDesarrollo del softwareIngenier铆a del softwareMicroservicios MaestroHackernoon Top StorySam Newman