HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
Netflix
SimianArmy
Java2012–2022
Netflix / SimianArmy · Archived

SimianArmy

Tools for keeping your cloud operating in top form. Chaos Monkey is a resiliency tool that helps applications tolerate random instance failures.

DevOps & Cloud
Explore on GitHubRead Hacker News discussions
31Distinct people
32Mentions
1Explicit recommenders
8KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Tools for keeping your cloud operating in top form. Chaos Monkey is a resiliency tool that helps applications tolerate random instance failures.

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

As always I recommend people practice Chaos Engineering [0] to minimize the impact of such events. Even if the complexity of cross-region failover is to expensive, having some…

Slippery_John used a recommendation phrase. One indexed comment matches. This is a phrase match, not a verdict.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year32 dated mentions

Observed mentions: 2012-07-31 00:21:36 UTC to 2022-03-16 06:46:22 UTC.

02468102012-01-01 00:00:00 UTC to 2013-01-01 00:00:00 UTC (exclusive): 3 mentions; 1 submissions, 2 comments20122013-01-01 00:00:00 UTC to 2014-01-01 00:00:00 UTC (exclusive): 1 mentions; 1 submissions, 0 comments2014-01-01 00:00:00 UTC to 2015-01-01 00:00:00 UTC (exclusive): 7 mentions; 0 submissions, 7 comments2015-01-01 00:00:00 UTC to 2016-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 10 mentions; 3 submissions, 7 comments2017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 5 mentions; 1 submissions, 4 comments20172018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2022

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20122012-01-01 00:00:00 UTC2013-01-01 00:00:00 UTC312
20132013-01-01 00:00:00 UTC2014-01-01 00:00:00 UTC110
20142014-01-01 00:00:00 UTC2015-01-01 00:00:00 UTC707
20152015-01-01 00:00:00 UTC2016-01-01 00:00:00 UTC202
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC1037
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC514
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC101
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC202
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC000
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC000
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC101

From the project README

An excerpt from the repository, fetched Nov 13, 2026.

Read the project’s introduction
PROJECT STATUS: RETIRED The Simian Army project is no longer actively maintained. Some of the Simian Army functionality has been moved to other Netflix projects: A newer version of Chaos Monkey is available as a standalone service. Swabbie is a new standalone service that will replace the functionality provided by Janitor Monkey. Conformity Monkey functionality will be rolled into other Spinnaker backend services. DESCRIPTION The Simian Army is a suite of tools for keeping your cloud operating in top form. Chaos Monkey, the first member, is a resiliency tool that helps ensure that your applications can tolerate random instance failures DETAILS Please see the wiki. SUPPORT Simian Army Google group Because the project is no longer maintained, there is a good chance that nobody will be able to answer a support question. LICENSE Copyright 2012-2016 Netflix, Inc. Licensed under the Apache License, Version 2.0 (the “License”); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an “AS IS” BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.
Read the full README on GitHub

What Hacker News says

32 sources
sdoering·Mar 16, 2022
Maybe companies need some kind of "Chaos Monkey" system [0] in place for regular employees. Not in "terminating" random employee's contracts, but a culture were regular, maybe even some kind of random transferals onto other projects, or onto internal work regularly happens. Everybody knows this and everybody should be prepared to a situation that tomorrow they are not working on the same problem they work on today. How would they structure work? How would they share knowledge? What can the organization to to ensure there always are fallbacks to everybody? At least fallbacks that if not perform at 100% but still on 80 - 90%. Sadly in my org this would not work of the get go, as we often have personal access tokens to our clients' systems. This is sometimes even a contractual obligation as for specific clients we need to be vetted. But even
Read the rest
in these cases we could be reassigned/reshuffled towards a slightly different proposition or at least be reassigned to an internal topic for a few days - just like we would not be able to work if we fell ill. [0]: https://github.com/Netflix/SimianArmy/wiki/Chaos-Monkey
In On Being Indispensable
Slippery_John·Sep 14, 2017Recommendation phrase
As always I recommend people practice Chaos Engineering [0] to minimize the impact of such events. Even if the complexity of cross-region failover is to expensive, having some sort of graceful failure is preferable to simply dying. Netflix's Simian Army [1] toolset is particularly useful here, though I don't see an OSS version of Chaos Kong (which simulates the failure of an entire region) sadly. [0]: http://principlesofchaos.org/ [1]: https://github.com/Netflix/SimianArmy/wiki
In S3 was down
alpha_squared·Apr 21, 2017
> Google, Facebook, Baidu, Amazon, the self driving car companies are doing cutting edge stuff in terms of scalability and analysis, but not Netflix. I think you're missing a quantifier of some sort. Perhaps "consumer-facing"? Of any AWS customer, Netflix is far and away the leader in understanding and making use of AWS. It pushes the limits more often than not. Their scalability, failure/recovery handling and (assumed) cost-effective deployments are _the_ standard in AWS and cloud computing. They even have an open-source toolset[0] for testing your infrastructure against failures and recovery that's quickly being picked up by several other companies to harden their infrastructure. Then you realize that regularly, throughout the day, they're intentionally bringing their own infrastructure down and they can still operate with nary a hiccup
Read the rest
. I wouldn't call that over-engineered. [0] https://github.com/Netflix/SimianArmy
In The Evolution of Container Usage at Netflix
computerex·Feb 16, 2017
You can plan all you'd like, failures happen not necessarily due to poor planning but because in real life, shit happens. Pokemon Go for instance experienced like 50x the amount of traffic they planned for. Secondly, software companies like Microsoft, Google and IBM might know a thing or two about running data centers. Due to economies of scale, these companies are inherently in a better position to supply hardware at scale. > If entire region is down do you think other regions can handle the load. If you think so you're kidding yourself Netflix routinely does just this to test the resilience of their systems. They pick a random AWS region, and they evacuate it. All the traffic is proxied to the other regions and eventually via DNS the traffic is routed entirely to the surviving regions. No interruption of service is experienced by the us
Read the rest
ers. Here's a visualization of Netflix simulating a failure on the US-east-1 region and failing over to US-west-1/US-west-2 https://www.youtube.com/watch?v=KVbTjlZ0sfE The top right node is the one that fails. As the error rate climbs, traffic starts getting proxied over to the surviving nodes, until a DNS switch redirects all traffic to the surviving nodes. Netflix does this monthly, in production. They also run https://github.com/Netflix/SimianArmy on production. The cloud enables fault tolerance, resiliency and graceful degradation.
In Introducing Cloud Spanner, a Global Database Service
richdougherty·Feb 14, 2017
Some interesting stuff in https://cloud.google.com/spanner/docs/whitepapers/SpannerAnd... about the social aspects of high availability. 1. Defining high availability in terms of how a system is used: "In turn, the real litmus test is whether or not users (that want their own service to be highly available) write the code to handle outage exceptions: if they haven’t written that code, then they are assuming high availability. Based on a large number of internal users of Spanner, we know that they assume Spanner is highly available." 2. Ensuring that people don't become too dependent on high availability: "Starting in 2009, due to “excess” availability, Chubby’s Site Reliability Engineers (SREs) started forcing periodic outages to ensure we continue to understand dependencies and the impact of Chubby failures." I think 2 is really interest
Read the rest
ing. Netflix has Chaos Monkey to help address this (https://github.com/Netflix/SimianArmy/wiki/Chaos-Monkey). There's also a book called Foolproof (https://www.theguardian.com/books/2015/oct/12/foolproof-greg...) which talks about how perceived safety can lead to bigger disasters in lots of different areas: finance, driving, natural disasters, etc.
In Introducing Cloud Spanner, a Global Database Service
lsc·Sep 15, 2016
Chaos Monkey is actually a reference to a tool that I think netflix released? huh. yeah, I see it on github: https://github.com/Netflix/SimianArmy I remember someone giving a talk on it in the mid aughts, and I think it's a wonderful way to describe what happens in real-world networks and systems. >Assuming our hardware was reliable was a mistake. Writing code so that it's chaos-monkey-proof is a great step forward. Hah. Part of it is that I am the guy who is responsible for keeping that multi-year uptime (and on most of my own hardware, this is mostly a matter of vetting updates, security and otherwise, and implementing workarounds) - but I like to point out that building a system that can deal with the chaos monkey is... well, it's way harder than throwing up a reliable SQL server with a reliable backup and someone like me on pager.
Read the rest
Especially if you want to beat the "the system fucks up once a year" record that even mediocre server-grade hardware can achieve. That said, if you can write such software, I agree that the end result is better, I mean, like half my skillset is in Linux/BSD and environments where reboots cost big bucks, but I'm not going to cry about turning in my pager. I'm just saying, it's hard and most people screw it up and end up building something less reliable than well-managed hardware with a competent oncall. >As for the generational thing... meh, we're ugly. People like hiring the beautiful folks. Startup folks think they're immortal, having some greying old fart in the corner wheezing away reminds them that they're not. Eh, I think that most of the startups that only hire pretty people also tend to pay such that they can't afford someone who is good who has a few decades of experience, so it might be more of a budgetary/age thing; young people, generally, will work for less. I think it might also be a San Francisco thing. The fitness of the people interviewing me goes up and the wages they offer me go down when I head up that direction.
In Old Geek

Showing the 15 most recent of 32 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.