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