3 ms·
I wrote the initial version of Toxiproxy back in 2014, but Jacob Wirth took it way beyond during his internship at Shopify. It came out of a need for writing in
by Sirupsen 5y ago
I wrote the initial version of Toxiproxy back in 2014, but Jacob Wirth took it way beyond during his internship at Shopify. It came out of a need for writing integration tests for resiliency work we did at Shopify back then. [1] We didn't want someone to suddenly re-introduce a hard dependency on e.g. Redis on Shopify's storefronts. The initial prototype was a shell script that used lsof(1) and gdb(1) to close the file descriptor of the various connections. But, besides being dodgy, we needed to also simulate latency and make sure it worked on everyone's MacOS laptop's (otherwise e.g. tc(1) would have been intriguing). I wrote a little bit more of the history of Toxiproxy on Twitter. [2] It's stable and has proxied everything in dev and CI at Shopify for over half a decade.
[1]: https://shopify.engineering/building-and-testing-resilient-ruby-on-rails-applications https://shopify.engineering/building-and-testing-resilient-r...
[2]: https://twitter.com/Sirupsen/status/1455622640727728137 https://twitter.com/Sirupsen/status/1455622640727728137
- westurner 5y agoWhat a useful tool for resilience engineering. https://github.com/dastergon/awesome-chaos-engineering#notable-tools https://github.com/dastergon/awesome-chaos-engineering#notab... does list toxiproxy. Any general pointers for handling network connectivity issues (from any OSI layer) in client and server apps? Many apps lack 'pending in outbox' functionality that we expect from e.g. email clients. - [ ] Who could develop a set of reference toxiproxy 'test case mutators' (?) for simulating typical #DisasterRelief connectivity issues? (In Python, Pytest + Hypothesis + Toxiproxy-python would be useful.)