¿Cómo se despliegan x veces al día gigantes de comercio electrónico como Amazon?

Gracias por el A2A.

No he trabajado en Amazon, por lo que no conozco su proceso de implementación en detalle. Sin embargo, donde trabajo, implementamos servicios muchas veces al día, ¡y eso está bien! Para nosotros, la razón principal por la que no implementamos constantemente es simplemente (a) lleva tiempo escribir un nuevo código y (b) lleva tiempo probar un nuevo código.

Aquí hay 10 consejos que utilizo para permitir que un equipo implemente sus servicios tantas veces al día como lo deseen.

  1. Implementaciones azules / verdes o de “alta disponibilidad”. Mientras la versión 1 de su aplicación esté activa, implemente la versión 2 “oscura” de modo que no sea detectable (por ejemplo, por DNS o su equilibrador de carga). Una vez que la versión 2 se haya inicializado y lo haya verificado (prueba de humo), cambie su servicio de descubrimiento para que apunte a la versión 2. La actualización es perfecta, y si algo sale mal, puede volver a la versión 1 inmediatamente.
  2. Inmediatamente después del n. ° 1, las implementaciones canarias son muy útiles para minimizar el retroceso y también para extender el impacto de la implementación de modo que no haya impacto en el rendimiento. Google es particularmente bueno en esto, y en su escala, es casi un requisito previo. Esto también permite pruebas A / B.
  3. Monitoreo receptivo (no falso). Debe ser rápido, pero debe ser correcto y debe manejarse con rapidez. Este tipo de monitoreo refuerza la confianza en la implementación.
  4. Mano a mano con el n. ° 3 es una cita que leí a Ernest Mueller cuando trabajé con él (parafraseado): “Si es doloroso, hágalo con más frecuencia”. Ernest tomó la plataforma heredada en Bazaarvoice desde ciclos de implementación muy largos y aterradores (creo que eran una vez al mes o más lento) hasta implementaciones semanales, y fue muy doloroso al principio, pero mejoró y mejoró hasta que Era una máquina bien engrasada. Esto genera confianza en la implementación. Programamos cuándo implementarlo y lo hicimos. Esto funciona mejor para aplicaciones monolíticas o aplicaciones con múltiples servicios que deben implementarse juntas que con microservicios, por lo que es muy importante entenderlo.
  5. Los ingenieros de operaciones y desarrollo de software trabajan juntos. Esto está en el corazón mismo del movimiento DevOps. Trabajo con mi equipo y entiendo la aplicación que estoy implementando, dentro y fuera. Esto me permite crear herramientas, automatización y servicios que se adaptan específicamente a los servicios que mi equipo está implementando. Las soluciones generales son geniales, pero no son perfectas.
  6. “BESO” se aplica aquí; mantener las cosas simples le permite minimizar las partes móviles. Cuantas menos partes móviles, menos probable es que las cosas se rompan cuando se implementa. Cuanto menos probable sea que se rompan las cosas, la implementación será más fluida y la implementación será más frecuente.
  7. No hagas el trabajo. Desarrolle herramientas para hacer el trabajo por usted. Entonces otras personas pueden delegar el trabajo en las herramientas, no tú. Específicamente, cree una herramienta que permita a sus desarrolladores de software realizar implementaciones con un solo clic. Bonificación: use una herramienta que ya conocen y entienden, como un CI. Yo uso a Jenkins. Mi equipo solo realiza un trabajo para hacer una compilación, la compilación pasa, luego ejecutan un trabajo para hacer una implementación. Luego van a tomar una cerveza y celebran su buen trabajo. Mientras tanto, estoy de vacaciones, y adivina qué, ¡ni siquiera me necesitaban!
  8. Tras el # 7, * automatízate sin trabajo. * En serio. Automatiza todo. Sal del camino de tu equipo. Les irá mejor si nunca tienen que esperarte.
  9. Eche un buen vistazo a la arquitectura de su infraestructura. ¿Realmente necesitas ese balanceador de carga de nivel medio? Maximice el tiempo de actividad minimizando los componentes. Descargue lo que pueda a los servicios que hacen bien su trabajo. No implemente su propia CDN. No implemente su propio DNS. (No, en realidad, la gente no piensa en esto tanto como cabría esperar, ¡el DNS ES MUY CRÍTICO!)
  10. Esta es probablemente la más obvia, pero tome algunas decisiones técnicas que sean claras, declarativas, deterministas, repetibles y bien documentadas. Sí, estoy implicando la gestión de la configuración (nixOS hace esto bien, pero Puppet también está bien) o Docker (los contenedores son una buena idea, generalmente, pero no siempre; ¿cuál es la sobrecarga para ejecutar Elasticsearch en un contenedor en una máquina virtual en un centro de datos del que no sabes nada? Pero, en última instancia, la idea es que desee que todo lo que automatiza ** siempre tenga el resultado exacto, idéntico, idéntico y conocido, cada vez, siempre, para siempre, incluso cambie la aplicación que se está ejecutando **
  11. ¡Prima! Ponga a disposición una versión virtualizada local de sus implementaciones reales, para que pueda “implementarlas” en su propia máquina local. Y borre todas sus configuraciones y todo periódicamente y comience desde cero (es decir, clone su repositorio git y siga las instrucciones de configuración) periódicamente, de hecho, automatícelo para que ocurra cada vez que realice una implementación local, de modo que La implementación local es exactamente lo que sucederá cuando realice la implementación real.

¡Buena suerte! No dude en solicitar aclaraciones o preguntas adicionales en los comentarios.