I would start by breaking services. E.g. "disconnecting" S3 or DDB to check if your functions can handle that or go into endless loops.
-
-
-
Good point. I can see some loops happening, for example with processing of the dead letters queue.
Kraj razgovora
Novi razgovor -
-
-
The role of serverless is to inject errors and latency to engineering
-
And the role of engineers is to inject chaos and latency.
- Još 2 druga odgovora
Novi razgovor -
-
-
Yeah both of those. In general much higher level stuff because the runtime is managed, so generally its around connectivity, resilience to unexpected data formats and catastrophic data centre failures. Any non-serverless component is good to emphasize testing around (RDBMS).
-
Good points. How are injections usually triggered? Is, say, a new Lambda deployed?
- Još 3 druga odgovora
Novi razgovor -
-
-
I'd say that you should use chaos engineering to confirm that your serverless architecture is as resilient as intended but as important to confirm that your application can handle that the "promises" of serverless isn't delivered by the provider. That can be through error and...
-
...latency injection but also by removing downstream services, creating configuration/permission issues, causing exceptions, concurrency problems and so on. The easy part is usually creating experiments and hypothesis around what I control. The other part contains more unknowns.
Kraj razgovora
Novi razgovor -
Čini se da učitavanje traje već neko vrijeme.
Twitter je možda preopterećen ili ima kratkotrajnih poteškoća u radu. Pokušajte ponovno ili potražite dodatne informacije u odjeljku Status Twittera.