2009 - 2014:

Zuckerberg announced that the company would be changing its internal motto from "Move fast and break things" to "Move fast with stable infrastructure".The earlier motto had been described as Zuckerberg's "prime directive to his developers and team" in a 2009 interview in Business Insider, in which he also said "Unless you are breaking stuff, you are not moving fast enough.

Yeah, IKR. Agree to disagree.

2014-2016:

I was working at this tech company with super fun culture: There was a picture hanging next to me saying:

"Move fast and break things. Unless you are breaking stuff, you are not moving fast enough." ~ Mark Zuckerberg

I was working in a company with a great culture and yes, my three mentors, yeah the two of you who have been making such a great impact in the past and until right now and I am pretty sure even in the future: Varun Bhargava Jason Blackman Jane Ooi

I can't thank you enough for everything. I was bought a ticket in December 2014 to go to one of the most expensive annual conferences in Melbourne and when someone mentioned a concept called Chaos Engineering and Chaos Monkey by Netflix and I became enchanted by it.

2016-2018:

I was working at another tech company with the same fun and great culture. I had another really great mentor, yeah I meant you Mohamed (Ed) Barwani.

One of many great quotes he told me. and it inspired my engineering principle up till today

There's no such thing as perfect systems, everything will fail the question is what will you do when it fails

It's similar to the concept of "Design for Failures"

2018-2021:

It's my first time jumping from organisations with 1000+ people to a small start-up and we were just 25 people at that time, at some point, it was just me yeah just myself building the technology for this start-up.

It has now grown and become a global scale-up.

Long story short, I have inherited the systems with no proper handover developed by resources both on-shore and off-shore.

Not too much documentation and kinda struggling all the time.

Guess what, my predecessor was a great coder and build high-quality code but the off-shore was a big ball of mud deployed in a single file.

But guess what? I almost have to firefight every day because something somewhere fails, and the systems weren't designed for failure

I felt like "Moving fast and break things" is undeniably the best running tech in the start-up, but I preffer "Move Fast With Stable Infra" and backed by a proper IaC.

During my tenure, we had a proper AWS Well Architecture review and the output of that was clear.

Lately, even after leaving the company, I had mutiple enquiry from my previous emplyee about "broken" stuffs

There were 2 ways of dealing with this:

• Technology: Design for Failure
• People/Process: Have regular gameday and write a playbook

The aim of writing this repository is to explore options and available way to mitigate failures.

I hope that other people out there will learnt something by reading this repository.

TO DO:

• Write README.md
• References
• Diagrams
• Examples
• Explore technologies

• Netflix Chaos Monkey: https://netflix.github.io/chaosmonkey/
• AWS 5 Pillars: https://aws.amazon.com/blogs/apn/the-5-pillars-of-the-aws-well-architected-framework/
• AWS Playbook: https://wa.aws.amazon.com/wat.concept.playbook.en.html
• AWS Game Day: https://wa.aws.amazon.com/wat.concept.gameday.en.html
• AWS Fault Injection Simulator: https://aws.amazon.com/fis/