febrero 20, 2025|10:40 AM
Whether it’s IT operations, cloud migration, or AI-driven innovation – let’s explore how we can support your success.
Crear aplicaciones modernas utilizando tecnología sin servidor y servicios gestionados significa que cualquiera puede construir sistemas distribuidos y altamente disponibles sin preocuparse de la infraestructura subyacente. Pero no todo es diversión y juegos. Esta charla que di en AWS re:Invent 2019 con el título «Realizando ingeniería del caos en un mundo sin servidor» explica algunos de los desafíos con serverless, debilidades comunes en las aplicaciones sin servidor, así como los desafíos con el uso de la ingeniería del caos en serverless. Consulta el vídeo.
Aunque todo esto empezó con la inyección de latencia, como en los artículos de Yan Cui, la latencia está lejos de ser el único fallo posible que podemos tener en nuestras aplicaciones sin servidor. En fallo-lambda, fallo-azurefunctions y fallo-cloudfunctions hay ahora cinco modos de fallo diferentes entre los que elegir:
Inyecta latencia a la función ejecutada, controlada mediante un intervalo mínimo y máximo de milisegundos. Esto puede utilizarse, por ejemplo, para simular la latencia del servicio o para probar y ayudar a establecer tus valores de tiempo de espera.
Lanza una excepción en la función. Te ayuda a probar cómo tu aplicación y tu código gestionan las excepciones.
Tu función devolverá un código de estado a elegir, por ejemplo 502 o 404 en lugar del normal 200. Esto te da la posibilidad de probar qué ocurre cuando hay errores.
Llenará tu disco temporal de archivos para crear un fallo. Si utilizas un disco para almacenar archivos temporales, puedes probar cómo se comporta tu aplicación si ese disco se llena o no puedes almacenar en él.
Bloquea las conexiones a los hosts especificados. Utilízalo para simular que los servicios o terceros no están disponibles.
Todos estos modos de fallo pueden utilizarse junto con un índice de fallo que tú establezcas. Por defecto, se inyecta un fallo en cada invocación, pero en realidad, es probable que, por ejemplo, un tercero no esté disponible en el 50% de las llamadas realizadas a ese host o que se lance una excepción en una cuarta parte de las invocaciones. Fijar la tasa te permitirá conseguirlo.
