¿Las interrupciones no serían cosa del pasado si todos los servicios de back-end se construyeran en sistemas infinitamente escalables como sin servidor y NoSQL?

Si existiera un sistema infinitamente escalable, entonces sí. En realidad, siempre habrá restricciones.

Pagerduty publicó recientemente una gran autopsia sobre la falla de la base de datos de Cassandra y los pasos que los ingenieros tomaron para resolverla:

Estado del PagerDuty – Notificaciones retrasadas

Cassaandra probablemente caería dentro de los tipos de bases de datos en las que está pensando.

También lo señalaré a la interrupción de AWS S3 este año. S3 es uno de los SLA más altos de la industria y, sin embargo, estuvo inactivo durante la mayor parte del día.

Resumen de la interrupción del servicio de Amazon S3 en la región del norte de Virginia (US-EAST-1)

Al final del día, la construcción de sistemas resilientes se trata de procesos y personas, no de ningún tipo de tecnología.

Los componentes de software en sí mismos son insuficientes para evitar interrupciones. Las interrupciones se evitan o al menos se mitigan al contar con una estructura organizativa que puede responder rápidamente a eventos inesperados. El nivel de automatización en el proceso de diagnóstico y gestión tiene un gran impacto en la fiabilidad del sistema.

Cualquier reclamo con respecto a los sistemas “infinitamente escalables” debe considerarse con un alto grado de escepticismo. Cualquier sistema, por grande que sea, siempre será finito y necesariamente debe especificarse para satisfacer la demanda máxima con un cierto (aceptable) nivel de redundancia.

No.

Sin servidor significa simplemente que, como ingeniero / desarrollador, no interactúa con su servicio de producción en la capa del servidor, sin embargo, depende de que esa capa de servicio esté realmente disponible.

Probablemente el servicio sin servidor más grande en el mercado hoy es el S3 de AWS.

Entonces, cuando S3 deja de funcionar, lo que hace que muchos sitios se vean afectados y dependiendo de cómo se integre el servicio, puede causar una interrupción parcial o total.

El hecho de que sea “sin servidor” no significa que no haya infraestructura física y código que deba mantenerse, lo que se vuelve más complejo a medida que el sistema continúa escalando.

Los sistemas sin servidor y NoSQL no hacen mágicamente ningún sistema infinitamente escalable: requieren un diseño cuidadoso que aproveche sus capacidades, y muchos sistemas no están tan cuidadosamente diseñados.

Además, todavía es susceptible a fallas sistémicas, como cortes de red, unidades que se llenan, cortes de energía del centro de datos, etc. También, por supuesto, siempre es susceptible a los errores de implementación, a la saturación de la red, a los efectos de latencia causados ​​por las reglas de coherencia, etc.

Dicho todo esto, un sistema bien diseñado con una capa lógica sin servidor y una capa de almacenamiento correctamente diseñada, con replicación / conmutación por error de múltiples centros de datos, será capaz de soportar bastantes fallas sistémicas.

Por ejemplo, utilizamos una combinación de Kafka, Drill, Cassandra, ElasticSearch, Spark, S3 / Parquet y algunas tecnologías personalizadas para cubrir las necesidades de nuestra plataforma de análisis. Cada sistema cubre un conjunto diferente de cargas de trabajo y se combinan cuidadosamente para permitirnos escalar tan rápido como adquirimos nuevos clientes / tan rápido como crecen los propios negocios de nuestros clientes.

No. Los sistemas escalables ayudan, pero siguen siendo vulnerables.

Por ejemplo, el servicio S3 de Amazon es muy escalable y altamente redundante, pero fue derribado hace unos meses cuando un ingeniero accidentalmente se metió con el sistema de indexación interno.

Y todavía hay otros aspectos vulnerables para cada aplicación. Cada vez que se introduce un cambio o se descubre un problema desconocido, existe la posibilidad de una interrupción.

Je, no Cuantos más componentes tenga algo, más hay que salir mal.