Filosofía de la ingeniería: Werner Vogels

Conclusiones clave

• Su principio definitorio es que todo falla todo el tiempo, así que diseñas para la falla en lugar de contra ella. Como CTO de Amazon desde 2005, Werner Vogels convirtió una observación contundente – a escala suficiente, la falla de componentes es constante y está garantizada estadísticamente – en una doctrina de diseño: asume que cada disco, servidor, enlace de red y dependencia fallará, y construye sistemas que se mantengan disponibles a través de la falla en lugar de fingir que se puede prevenir.¹⁶
• Coescribió el artículo de Dynamo, que fue pionero en las ideas detrás del NoSQL moderno. “Dynamo: Amazon’s Highly Available Key-value Store” (SOSP 2007) reunió hashing consistente, relojes vectoriales, quórums laxos, membresía basada en gossip y consistencia eventual en un único almacén siempre escribible, e influyó directamente en Cassandra, Riak, Voldemort y el propio DynamoDB de Amazon.²³
• Es el principal evangelista de la consistencia eventual. Su ensayo “Eventually Consistent” planteó con claridad el compromiso entre disponibilidad y consistencia: cuando la red se particiona – y a escala lo hará – tienes que elegir, y Dynamo eligió mantenerse disponible y converger pronto en lugar de bloquearse hasta que cada réplica esté de acuerdo.⁴⁷
• Le dio a la cultura de ingeniería la frase “tú lo construyes, tú lo operas” (you build it, you run it). En una conversación de 2006 describió el modelo de Amazon en el que los desarrolladores son dueños de sus servicios en producción – delimitándolos, construyéndolos y operándolos – y argumentó que poner a quienes construyen al frente del busca y frente al cliente es lo que impulsa la calidad.⁵

El principio

“Todo falla, todo el tiempo.” – Werner Vogels, CTO de Amazon, sobre el diseño de sistemas distribuidos confiables⁶

La mayor parte de la ingeniería optimiza para el caso en que todo funciona. Construyes el camino feliz, manejas los pocos errores que puedes imaginar y publicas. Ese instinto sobrevive justo hasta que operas a escala – y entonces te traiciona. Cuando estás corriendo cientos de miles de máquinas, lo “raro” deja de ser raro. Una falla de disco que ocurre una vez cada tres años por unidad ocurre en algún punto de tu flota cada pocos minutos. Un enlace de red que pierde un paquete en un millón pierde millones de paquetes al día. La frase más famosa de Vogels comprime esto en cuatro palabras: todo falla todo el tiempo.⁶ La falla no es una excepción que rodear con ingeniería; a escala es la condición de estado estacionario para la que debes hacer ingeniería.

El principio que se desprende es la inversión del habitual. Si no puedes prevenir la falla – y a escala demostrablemente no puedes – entonces prevenirla es el objetivo equivocado. El objetivo correcto es mantenerte disponible mientras las cosas fallan. Así que asumes que cada componente morirá, y diseñas de modo que cualquier muerte individual sea sobrevivible: replicas datos entre máquinas para que la pérdida de una sea invisible, desacoplas servicios detrás de API para que una dependencia que falla degrade una función en lugar de derribar el sistema, y minimizas el radio de impacto de cualquier fallo para que no pueda tumbar el conjunto. El sistema no está construido para evitar el caso de falla; está construido para que el caso de falla sea aburrido.¹⁶

Hay una segunda mitad del principio, y es la que hace real a la primera: no puedes tener consistencia perfecta y disponibilidad perfecta al mismo tiempo una vez que la red puede particionarse, así que tienes que elegir – y Vogels eligió la disponibilidad. Cuando una división de red corta el enlace entre tus réplicas, un sistema puede o bien negarse a responder hasta que todos estén de acuerdo (consistente, pero no disponible) o seguir respondiendo con lo que tiene y reconciliar después (disponible, pero brevemente inconsistente). Para el carrito de compras de Amazon, negarse a responder era inaceptable – un carrito que rechaza un “agregar al carrito” durante una partición es un carrito que pierde una venta.⁴ Así que Dynamo siempre acepta la escritura y deja que las réplicas converjan después. El costo es una pequeña ventana en la que distintas réplicas pueden devolver respuestas diferentes; la recompensa es un sistema que nunca le dice “no” a un cliente. Ese compromiso – mantenerse disponible y converger pronto en lugar de bloquearse hasta que todos estén de acuerdo – es la consistencia eventual, y Vogels dedicó una carrera a sostener que es el compromiso correcto a escala.⁴⁷

Contexto

Werner Vogels nació el 3 de octubre de 1958 en Ermelo, Países Bajos.¹ Su camino hacia la computación no fue la línea recta convencional a través de una universidad de élite. Estudió ciencias de la computación en The Hague University of Applied Sciences, terminando en 1989, y solo más tarde obtuvo un doctorado en ciencias de la computación de la Vrije Universiteit Amsterdam – su tesis de 2003, “Scalable Cluster Technologies for Mission Critical Enterprise Computing”, fue supervisada por Henri Bal y Andrew Tanenbaum, este último una de las figuras fundacionales del campo en sistemas distribuidos y sistemas operativos.¹ El detalle que vale la pena conservar es que el doctorado siguió a años de trabajo real con sistemas en lugar de precederlo; la teoría alcanzó a la práctica.

El capítulo más formativo llegó en la Cornell University, donde de 1994 a 2004 fue científico investigador trabajando en sistemas empresariales escalables y confiables.¹ En Cornell estuvo dentro del grupo de sistemas distribuidos de Ken Birman – el linaje detrás de Isis y la comunicación grupal confiable, el cuerpo de trabajo que se preguntaba cómo un conjunto de máquinas puede ponerse de acuerdo, mantenerse consistente y seguir funcionando a medida que sus miembros fallan y se recuperan. Cofundó una empresa, Reliable Network Solutions, con Birman y Robbert van Renesse, y se desempeñó como su VP y CTO.¹ Este es el suelo intelectual en el que Vogels creció: no “cómo evitamos que las máquinas fallen”, sino “cómo un grupo de máquinas se mantiene correcto y disponible mientras sus miembros fallan”. Cuando más tarde dijo que todo falla todo el tiempo, no estaba improvisando – estaba enunciando la premisa fundacional de la tradición de sistemas distribuidos confiables dentro de la cual había pasado una década.

Se unió a Amazon en septiembre de 2004 como director de investigación de sistemas, fue nombrado CTO en enero de 2005 y sumó el título de VP en marzo de 2005 – el cargo que ha ocupado desde entonces, dirigiendo la orientación tecnológica de toda la empresa.¹ Su llegada coincidió con los años en que Amazon estaba inventando la nube moderna: el sistema de almacenamiento Dynamo se construyó y documentó en este período, Amazon Web Services lanzó sus servicios fundacionales, y Vogels se convirtió en la voz pública de los principios arquitectónicos subyacentes a todo ello – diseñar para la falla, desacoplar mediante servicios, abrazar la consistencia eventual y poner a las personas que construyen un servicio a cargo de operarlo.²⁴⁵

La obra

“Todo falla todo el tiempo”: diseñar para la falla y la consistencia eventual

Empieza aquí, porque es el principio convertido en ingeniería. La doctrina tiene dos movimientos. El primero es diseñar para la falla: tratar cada componente como algo que va a fallar, y hacer que el sistema sobreviva a su pérdida. Eso significa redundancia (replicar para que cualquier copia pueda desaparecer), desacoplamiento (los servicios hablan a través de API para que una dependencia enferma degrade con elegancia en lugar de provocar una cascada) y contención del radio de impacto (particionar el sistema para que un fallo quede atrapado en una celda pequeña en lugar de extenderse).¹⁶ La prueba de un diseño no es “¿funciona cuando todo está sano?” sino “¿qué pasa cuando esta pieza muere en el peor momento posible?” – y la respuesta tiene que ser “el sistema sigue sirviendo”.

El segundo movimiento es el que hace posible la alta disponibilidad a escala: la consistencia eventual. La observación CAP de Eric Brewer dice que cuando la red se particiona, un sistema distribuido no puede ser a la vez perfectamente consistente y plenamente disponible – debe renunciar a uno.⁷ El “Eventually Consistent” de Vogels hace explícita la elección y define la alternativa con precisión: bajo consistencia eventual, “el sistema de almacenamiento garantiza que si no se realizan nuevas actualizaciones sobre el objeto, eventualmente todos los accesos devolverán el último valor actualizado”.⁴ La palabra eventualmente es todo el compromiso. Un sistema que prioriza la disponibilidad “puede aceptar siempre la escritura, pero bajo ciertas condiciones una lectura no reflejará el resultado de una escritura completada recientemente”.⁴ Durante una ventana breve y acotada, dos réplicas pueden discrepar – pero ninguna se niega jamás a responder. La convergencia ocurre en segundo plano, y el usuario nunca queda bloqueado.

Por qué importa como ingeniería: el modelo mental que la mayoría de los desarrolladores tiene de una base de datos es el de una sola máquina, donde una escritura es instantáneamente visible para cada lectura posterior porque solo hay una copia. Ese modelo no sobrevive a la escala, porque una sola copia es un punto único de falla y una sola máquina es un techo para el rendimiento. En el momento en que replicas – cosa que debes hacer para estar disponible – heredas la pregunta de qué ve un lector mientras las copias se ponen al día. La contribución de Vogels fue insistir en que esto no es un defecto que ocultar sino una dimensión de diseño que elegir deliberadamente, y dar a los ingenieros el vocabulario – read-your-writes, lecturas monótonas, consistencia de sesión – para escoger exactamente cuánta consistencia necesita realmente una carga de trabajo dada, en lugar de pagar por la garantía más fuerte en todas partes.⁴

El artículo de Dynamo y el movimiento NoSQL

El principio tiene un artefacto canónico: “Dynamo: Amazon’s Highly Available Key-value Store”, que Vogels coescribió y que se publicó en SOSP 2007, el principal foro de sistemas operativos del campo.² Dynamo fue la respuesta de Amazon a un requisito específico y brutal – el carrito de compras tenía que aceptar escrituras siempre, incluso durante particiones de centros de datos y fallas de disco, porque un carrito no disponible pierde ingresos directamente.²³ Las bases de datos relacionales tradicionales, afinadas para la consistencia fuerte, no podían prometer eso bajo partición. Así que Amazon construyó un almacén que cambió consistencia por disponibilidad y dejó escrito exactamente cómo.

Dynamo es un catálogo de técnicas de sistemas distribuidos ensambladas en un único sistema siempre escribible y descentralizado, y la influencia del artículo proviene de lo limpiamente que las expuso.²³ El hashing consistente particiona los datos entre nodos para que el anillo pueda crecer o encogerse sin rebarajar todo – “escalabilidad incremental, posiblemente lineal”.³ Los relojes vectoriales rastrean la historia causal de cada valor para que las escrituras concurrentes puedan detectarse en lugar de perderse en silencio. Los quórums laxos y la entrega con pista mantienen el sistema escribible incluso cuando algunas réplicas están inalcanzables, estacionando escrituras en un suplente temporal hasta que el nodo legítimo regrese. La anti-entropía con árboles de Merkle permite a las réplicas encontrar y reparar sus diferencias de manera eficiente. La membresía basada en gossip permite a los nodos conocerse entre sí y detectar fallas sin coordinador central – el diseño es deliberadamente simétrico y descentralizado, de modo que “cada nodo en Dynamo debería tener el mismo conjunto de responsabilidades que sus pares”, lo que significa que no hay un nodo especial cuya muerte sea catastrófica.³ Cada una de estas decisiones sirve al mismo amo: mantenerse disponible cuando las cosas fallan.

Amazon nunca liberó el código de Dynamo, pero el artículo hizo el trabajo – se convirtió en uno de los artículos de sistemas más influyentes de su década, la semilla intelectual del movimiento NoSQL.³ Apache Cassandra, Riak y Project Voldemort rastrean todos sus diseños sin líder y eventualmente consistentes directamente hasta él.³ Y el nombre perduró comercialmente en Amazon DynamoDB, que está construido sobre los principios de Dynamo aunque tomó decisiones de ingeniería distintas bajo el capó (replicación con un único líder en lugar del modelo puro sin líder de Dynamo).³ La lección de la influencia de Dynamo merece destacarse en sí misma: el foso competitivo de Amazon no era el código, era la claridad. Al explicar con precisión a qué garantías renunciaron y por qué, le enseñaron a una generación de ingenieros cómo razonar sobre el compromiso.

AWS, la orientación a servicios y “tú lo construyes, tú lo operas”

Dynamo es un sistema de almacenamiento; la contribución más profunda de Vogels es arquitectónica y cultural. La plataforma de Amazon está construida como una malla de servicios independientes que solo hablan a través de API – sin bases de datos compartidas alcanzadas por detrás del telón, sin acoplamiento oculto.⁵ La disciplina importa para la falla: cuando los servicios están desacoplados detrás de interfaces firmes, uno que falla degrada la función específica que alimenta en lugar de corromper los datos o atascar los hilos de todo lo que lo tocó. La orientación a servicios es contención del radio de impacto expresada como arquitectura. También es lo que hizo posible AWS – una vez que tus sistemas internos son servicios limpios y direccionables por API, exponerlos al mundo exterior como productos es un paso siguiente natural.

La mitad cultural es la frase por la que se cita a Vogels tan a menudo como “todo falla todo el tiempo”: “tú lo construyes, tú lo operas” (you build it, you run it). En una conversación de 2006 con Jim Gray, describió el modelo de Amazon en el que cada servicio es propiedad de extremo a extremo del equipo que lo crea: “Cada servicio tiene un equipo asociado a él, y ese equipo es completamente responsable del servicio – desde delimitar la funcionalidad hasta diseñar su arquitectura, construirlo y operarlo”.⁵ Y la justificación trataba explícitamente sobre la calidad a través de la propiedad: “Tú lo construyes, tú lo operas. Esto pone a los desarrolladores en contacto con la operación cotidiana de su software. También los pone en contacto cotidiano con el cliente”.⁵ No hay un muro por encima del cual arrojar el código; el ingeniero que escribió el servicio carga con el busca por él. El efecto es un ciclo de retroalimentación apretado – la persona más capaz de arreglar una fragilidad es la persona que siente su dolor a las 3 de la madrugada, y la persona que diseñó la función oye la queja del cliente directamente. La propiedad no es aquí un eslogan de recursos humanos; es un mecanismo de confiabilidad. Un equipo que opera lo que construye diseña para la falla porque la falla los despierta a ellos.

Evangelizar la nube: radio de impacto, celdas y sistemas bien arquitecturados

El cuarto cuerpo de trabajo de Vogels es menos un artefacto único que un rol sostenido: durante dos décadas ha sido el arquitecto-evangelista que codificó cómo construir sobre la nube, no solo cómo construir la nube.¹⁶ Los temas recurrentes son el principio aplicado a un alcance cada vez mayor. Minimizar el radio de impacto: particionar los sistemas en celdas independientes para que un fallo, un despliegue defectuoso o una solicitud envenenada quede contenido en una porción de clientes en lugar de en todos ellos. Desacoplar de forma agresiva: preferir servicios asíncronos y débilmente acoplados con contratos explícitos por encima de cadenas síncronas apretadas donde una dependencia lenta atasca toda la ruta de llamada. Automatizar la recuperación, no documentarla: un manual de operación que necesita a un humano no se ejecuta cuando el humano está dormido. Abrazar la falla como una entrada de prueba, inyectando fallos deliberadamente para demostrar que el sistema los sobrevive en lugar de esperar que lo haga. Cada uno de estos es “todo falla todo el tiempo” convertido en una práctica operativa – el mensaje consistente, repetido a lo largo de charlas, escritos y una segunda conversación en ACM años después, de que la resiliencia es una propiedad que diseñas desde la primera línea, no una capa que añades después de que la demostración funciona.⁶

El método

Lee a lo ancho de Dynamo, la consistencia eventual, la orientación a servicios y “tú lo construyes, tú lo operas”, y vuelven los mismos compromisos. El método de Vogels es menos un eslogan que un conjunto de hábitos permanentes.

Diseña primero para el caso de falla. A escala, la falla es el estado estacionario, no la excepción, así que la pregunta nunca es “¿esto funciona?” sino “¿qué pasa cuando cada pieza de esto muere?”.⁶ La lección se transfiere mucho más allá de la escala de Amazon: no escribas el camino feliz y parches el manejo de errores – enumera primero los modos de falla y deja que el camino que funciona se desprenda de un sistema que ya los sobrevive. Es la puerta de evidencia aplicada a la confiabilidad – “funciona en la demostración” no es prueba; “se mantiene disponible cuando mato un nodo a mitad de una solicitud” es el mismo estándar de autorreparación que Radia Perlman integró en redes que reconvergen sin un humano en el ciclo.

Elige tu consistencia, no la heredes. El movimiento más profundo en Dynamo es rechazar el valor por defecto de que toda lectura deba ver toda escritura previa. Vogels convierte la consistencia en una perilla que ajustas por carga de trabajo – fuerte donde la corrección lo exige, eventual donde la disponibilidad importa más – y es preciso sobre qué garantía provee realmente un sistema.⁴⁷ La disciplina es saber exactamente sobre qué se apoya tu afirmación de consistencia y nunca pagar por una garantía que una carga de trabajo no necesita. Es la misma precisión sobre la corrección que Leslie Lamport aportó al tiempo distribuido: no asumas la propiedad, defínela con exactitud y sabe cuándo se cumple.

Desacopla para contener el radio de impacto. Servicios independientes detrás de API firmes significan que una falla queda atrapada donde ocurre en lugar de provocar una cascada.⁵ El hábito permanente es trazar las fronteras de modo que el peor caso sea una función degradada, nunca un sistema caído – preguntar de cada dependencia “cuando esto falla, ¿qué tan grande es el agujero?” y hacer el agujero pequeño. Es la forma arquitectónica del producto mínimo digno: la frontera más limpia es la que hace exactamente su trabajo y falla sola.

Haz que quienes construyen sean dueños de la operación. “Tú lo construyes, tú lo operas” pone a las personas que diseñan un servicio al frente del busca por él, cerrando el ciclo entre una fragilidad y la persona capaz de arreglarla.⁵ La lección es que el dolor operativo es la señal de calidad más honesta que existe – un equipo aislado de producción subinvertirá en resiliencia, porque el costo de la fragilidad cae sobre otro. La propiedad es un mecanismo de confiabilidad, que es la calidad es la única variable convertida en un organigrama: la única manera de garantizar la calidad es hacer que quien construye sienta la consecuencia de su ausencia.

Explica el compromiso a cielo abierto. La influencia de Dynamo no provino de su código – que nunca se liberó – sino de un artículo que enunció con llaneza a qué garantías se renunciaba y por qué.²³ El hábito es hacer legible el razonamiento: nombrar el compromiso, justificar el lado que elegiste y enseñar al siguiente ingeniero a razonar sobre él en lugar de imitar el resultado por inercia. La claridad sobre el porqué es lo que permite que un diseño sobreviva a su autor – la misma disciplina explicativa que hizo que los artículos de Perlman y Lamport siguieran siendo enseñables décadas después.

Cadena de influencia

Quién lo formó

Ken Birman y la tradición de sistemas distribuidos confiables de Cornell. La década de Vogels en Cornell, dentro del grupo de Birman y el linaje de Isis y la comunicación grupal confiable, es la fuente de su premisa fundacional.¹ La pregunta central de esa tradición – cómo un grupo de máquinas se mantiene correcto y disponible mientras sus miembros fallan y se recuperan – es precisamente la pregunta que responde “todo falla todo el tiempo”. No acuñó un eslogan; reformuló el primer principio de su campo para una audiencia planetaria. (Influencia formativa)

Andrew Tanenbaum y la academia de sistemas distribuidos. Su doctorado en la Vrije Universiteit fue supervisado en parte por Tanenbaum, uno de los maestros fundacionales del campo en sistemas operativos y distribuidos.¹ La base se nota: Dynamo se lee como una síntesis funcional del canon de los sistemas distribuidos – hashing consistente, relojes vectoriales, quórums, gossip – ensamblada por alguien que conocía la literatura al dedillo. (Influencia formativa)

Eric Brewer y el compromiso CAP. El argumento de Vogels a favor de la consistencia eventual se apoya explícitamente en la observación CAP de que un sistema tolerante a particiones debe negociar consistencia contra disponibilidad.⁴⁷ Brewer encuadró la imposibilidad; Vogels operacionalizó la elección a la escala de Amazon e hizo de “elige disponibilidad y converge” un valor por defecto respetable. (Influencia directa)

A quién formó

Todo el movimiento NoSQL. El artículo de Dynamo es el ancestro directo de Cassandra, Riak y Voldemort, y el homónimo de DynamoDB – el patrón de diseño sin líder y eventualmente consistente se propagó desde un artículo de 2007 hacia la capa de datos de una generación de sistemas.³

La arquitectura nativa de la nube y la cultura DevOps. “Tú lo construyes, tú lo operas” se convirtió en una de las ideas fundacionales del DevOps moderno – la propiedad de servicio completa, los desarrolladores de guardia y la disolución del muro entre dev y ops se remontan directamente al modelo que Vogels describió en 2006.⁵

Una generación de arquitectos de la nube. A través de los principios de diseño de AWS y su evangelización sostenida, “diseñar para la falla”, “minimizar el radio de impacto” y “desacoplar mediante servicios” se convirtieron en el vocabulario por defecto que los ingenieros usan para razonar sobre la construcción de sistemas confiables en la nube.⁶

El hilo conductor

Vogels es la clave de bóveda de escala operativa de esta serie – la figura que tomó la teoría de los sistemas distribuidos y la corrió sobre un planeta entero de máquinas. Leslie Lamport le dio sus cimientos a los sistemas distribuidos: cómo definir el tiempo, el orden y el consenso con precisión, y cómo mantener un sistema correcto cuando los participantes fallan o se comportan de forma arbitraria. Vogels es lo que esos cimientos parecen cuando tienen que servir a un carrito de compras de Black Friday – las mismas preguntas de consistencia y falla, respondidas no en una pizarra sino bajo carga real, con ingresos reales apostados a mantenerse disponible.⁴ Y Radia Perlman construyó redes que tratan el caso de falla como el centro del diseño, sanándose solas sin un humano en el ciclo; Vogels construyó servicios sobre exactamente ese instinto, una capa más arriba en la pila – replicar, desacoplar, contener el radio de impacto y dejar que el sistema converja por su cuenta. Donde Lamport dice define la corrección y prueba que sobrevive a la falla y Perlman dice constrúyelo para que se sane solo, Vogels dice: todo falla todo el tiempo, así que deja de tratar de prevenirlo – diseña para que el sistema se mantenga disponible directamente a través de la falla, y deja que quienes lo construyen y lo operan sientan cada grieta. (Puente de la serie)

Lo que tomo de esto

La lección que conservo de Vogels es tratar la falla como el caso normal, no la excepción. Mi instinto, como el de la mayoría de quienes construyen, es escribir el camino donde la llamada tiene éxito, la dependencia responde, el disco está ahí – y luego atornillar un try/catch una vez que funciona. “Todo falla todo el tiempo” es el reproche: a cualquier escala real la falla no es un evento raro que le ocurre a mi sistema, es una condición constante en la que mi sistema vive. Así que cuando construyo algo ahora – un trabajo de sincronización, un cliente de API, un consumidor de cola – intento partir de “¿qué muere, y el resto sigue sirviendo cuando lo hace?” en lugar de llegar ahí al final. La versión honesta de “funciona” no es la demostración en verde; es matar una dependencia a mitad de una solicitud y ver al sistema degradarse con elegancia en lugar de venirse abajo. Un sistema que solo sobrevive al camino feliz es un sistema que no he terminado de diseñar.

La segunda lección es que la disponibilidad y la consistencia son un compromiso que tengo que hacer a propósito. Es tentador quererlas ambas – que toda lectura vea toda escritura, y que el sistema nunca diga que no – y para una sola máquina puedes tenerlas. En el momento en que replico cualquier cosa, esa comodidad se acabó, y la disciplina de Vogels es elegir el lado deliberadamente para cada carga de trabajo en lugar de optar por defecto por la garantía más fuerte en todas partes por costumbre. La mayor parte de lo que construyo no necesita que una lectura refleje al instante la última escritura; necesita no rechazar jamás al cliente. La consistencia eventual reformuló eso para mí: de un compromiso temible a una herramienta precisa: nombrar exactamente qué tan desactualizado puede tolerar estar un lector, comprar disponibilidad con ese margen y dejar de pagar por una garantía que la función nunca necesitó. La habilidad no es buscar siempre la promesa más fuerte – es saber qué promesa requiere realmente el trabajo.

Preguntas frecuentes

¿Qué significa “todo falla todo el tiempo”?

Es la compresión que hace Werner Vogels de una lección ganada con esfuerzo sobre la escala: cuando operas suficientes máquinas, la falla de componentes deja de ser una excepción rara y se convierte en una condición constante, garantizada estadísticamente.⁶ Un modo de falla lo bastante raro como para ignorarlo en un solo servidor ocurre en algún punto de una flota grande constantemente. La consecuencia práctica es la inversión de la ingeniería normal: en lugar de tratar de prevenir la falla, asumes que cada disco, servidor, enlace y dependencia fallará, y diseñas sistemas que se mantienen disponibles a través de la falla – mediante redundancia, desacoplamiento y radio de impacto contenido – de modo que cualquier fallo individual sea sobrevivible y, idealmente, invisible.¹⁶

¿Qué es el artículo de Dynamo?

“Dynamo: Amazon’s Highly Available Key-value Store” es un artículo de SOSP de 2007, coescrito por Vogels, que describe el sistema de almacenamiento que Amazon construyó para mantener servicios como el carrito de compras escribibles incluso durante fallas y particiones de red.²³ Combinó hashing consistente para el particionado, relojes vectoriales para rastrear escrituras concurrentes, quórums laxos y entrega con pista para mantenerse disponible bajo falla, anti-entropía con árboles de Merkle para la reparación y gossip para la membresía descentralizada – todo al servicio de aceptar siempre una escritura y reconciliar después. Amazon nunca liberó el código, pero el artículo se volvió fundacional para el movimiento NoSQL, influyendo directamente en Cassandra, Riak, Voldemort y Amazon DynamoDB.³

¿Qué es la consistencia eventual?

La consistencia eventual es un modelo de consistencia relajado que Vogels impulsó y definió en su ensayo “Eventually Consistent”: “si no se realizan nuevas actualizaciones sobre el objeto, eventualmente todos los accesos devolverán el último valor actualizado”.⁴ En un sistema replicado, una escritura puede llegar a algunas réplicas antes que a otras, así que durante una ventana breve distintas réplicas pueden devolver respuestas diferentes – pero ninguna rechaza jamás una solicitud. El sistema se mantiene disponible y converge en segundo plano en lugar de bloquearse hasta que cada réplica esté de acuerdo. Es el lado de la disponibilidad del compromiso CAP: cuando la red se particiona, un sistema puede ser consistente (negarse a responder hasta que todos estén de acuerdo) o disponible (responder con lo que tiene y reconciliar después), y la consistencia eventual elige disponible.⁴⁷

¿Qué significa “tú lo construyes, tú lo operas”?

“Tú lo construyes, tú lo operas” es la descripción de Vogels, de una conversación de ACM Queue de 2006, del modelo de Amazon de propiedad de servicio completa: el equipo que construye un servicio es “completamente responsable del servicio – desde delimitar la funcionalidad hasta diseñar su arquitectura, construirlo y operarlo”.⁵ No hay un muro entre desarrollo y operaciones – los ingenieros que escribieron el código cargan con el busca por él. Vogels argumentó que esto “pone a los desarrolladores en contacto con la operación cotidiana de su software” y “en contacto cotidiano con el cliente”, y que el ciclo de retroalimentación resultante es lo que impulsa la calidad.⁵ La idea se convirtió en uno de los principios fundacionales de la cultura DevOps moderna.

Fuentes