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