¿Qué tan comunes son los apagones de servicios en plataformas en la nube como AWS, Azure, Google?

Su pregunta tiene varias partes, y solo unos pocos componentes están bajo el control del proveedor. Primero, para cualquier conexión a Internet, está el ISP del usuario, los dos ISP de tránsito, el ISP del proveedor, la estructura interna del centro de datos y, finalmente, su servicio / aplicación.

La mayoría de los centros de datos modernos, incluidos todos los proveedores de primer nivel y casi todos los proveedores de segundo nivel, son ultra confiables (menos de 1 segundo de pérdida de energía por año, garantizado por contrato).

Si se configura correctamente, la red del centro de datos casi nunca falla físicamente, pero puede sobrecargarse si el centro de datos no está bien diseñado, aunque todas las redes de nivel superior y la mayoría de segundo nivel están lo suficientemente bien diseñadas.

Esto deja a los ISP, que generalmente están diseñados para una confiabilidad súper alta, el mismo nivel que un centro de datos para ISP de tránsito y, para los locales, alrededor del 95% de la calidad. Todavía se sobrecargan.

…… Algún idiota con un tractor siempre puede desenterrar la fibra; puede haber problemas de enrutador; algo podría romper el cable transatlántico, aunque es muy poco probable, ya que un experto como Stan Hanks necesitaba abordar el aspecto del cable transoceánico.

Todo se suma a una solución un poco menos confiable que un sistema de oficina excelente y eficiente, pero no por mucho. La mayoría de los “apagones” que experimenta se deben a picos en la carga más allá de lo que un segmento de red fue diseñado para manejar. Por ejemplo, muchos de los recientes “apagones” que Quora ha experimentado se deben a una sobrecarga, no a una falla.

Sucede menos de lo que piensas.

Parte de la razón es que cada uno de estos proveedores tiene múltiples servicios en múltiples centros de datos. Es raro tener un apagón amplio que afecte más que un servicio en un centro de datos.

Todos los sistemas son propensos a fallas. Si bien es importante comprender la propensión a fallar de una plataforma en la nube, existen otras consideraciones que son tan importantes:

1. ¿Cuál es el SLA del proveedor de la nube (en detalle) para infraestructura
2- ¿Cuál es su arquitectura recomendada? Por ejemplo, la filosofía de AWS es que las cosas fallarán, es su responsabilidad manejar las fallas y construir su sistema utilizando múltiples zonas de disponibilidad. Otros, como Rackspace, tienen servicios donde garantizarán un tiempo de actividad del 100%.
3 – ¿Qué harás cuando algo falla? ¿Cuál es su plan DR / HA y cómo garantizará la continuidad?
4 – Lo importante no es el tiempo de actividad del hardware o del centro de datos, es el tiempo de actividad de la aplicación. ¿Cómo puede diseñar su aplicación para que sea resistente a las fallas?

Ocurre de vez en cuando, en el caso de Azure tienen un sitio de estado donde publican el estado de la plataforma y también el historial de hasta 90 días atrás.

https://azure.microsoft.com/en-u

https://azure.microsoft.com/en-u

Además, vale la pena echar un vistazo a los SLA de la plataforma para considerar las implicaciones del tiempo de inactividad

Acuerdos de Nivel de Servicio