Resilience Rhythms: Embracing Chaos Engineering

Listen on the go!

Chapter 1: A Curious Introduction

In the heart of the bustling city of Hyderabad, a cozy coffee shop was abuzz with a lot of activity. Among the patrons was Murthy, a young and enthusiastic software engineer, nursing a cup of steaming coffee. As Murthy perused his laptop, a friendly voice chimed in from the neighboring table.

“Chaos engineering, huh? Quite the hot topic these days,” the voice said. Murthy looked up to find Mr. Shan, a seasoned expert in the field, smiling warmly.

“Hey there! Yeah, I’ve been hearing a lot about it lately,” Murthy replied with a mixture of curiosity and eagerness.

Chapter 2: Unveiling the Essence

“Chaos engineering is like exploring the unknown in the realm of software,” I began, leaning back in my chair. “It’s all about intentionally introducing disruptions and failures into your system to understand how it responds.”

Murthy nodded, intrigued. “So, you’re saying that by causing chaos, we learn how to make our systems more resilient?”

“Exactly,” I affirmed. “And that’s where tools such as Chaos Monkey, Chaos Toolkit, Gatling, Pumba, Powerful Seal, Gremlin, Chaos Blade, Litmus Chaos, etc. come into play. These tools help orchestrate chaotic experiments in Docker or Kubernetes environments.”

Chapter 3: The Journey Begins

As the conversation flowed, I shared stories of real-world successes with chaos engineering. Murthy’s eyes lit up with fascination. “But where do you even start?” Murthy asked, leaning forward.

“Good question,” I said with a smile. “It’s like embarking on an adventure. You begin with simple experiments, like introducing network latency, simulating a pod failure, increasing CPU utilization, or running packet loss experiments, etc.”

Murthy nodded slowly, imagining the thrill of uncovering hidden vulnerabilities before they became significant issues.

Chapter 4: The Learning Curve

“But what if things go wrong during these experiments?” Murthy asked, a hint of concern in his voice.

“That’s the beauty of it,” I reassured. “Chaos engineering is all about learning from failures. It’s not about pointing fingers, but about collaborating and improving.”

I continued, “That’s the reason why I encourage all Chaos engineers and Site Reliability Engineers to start small, then scale up, minimize blast radius, and always keep rollback plans ready.”

Chapter 5: A Practical Approach

I leaned forward, his eyes shining with enthusiasm. “Imagine you’re a pilot in a flight simulator. You intentionally create engine failures to learn how to handle emergencies. Chaos engineering does something similar for software.”

Murthy’s face brightened with understanding. “So, by simulating disasters, we become better equipped to prevent them?”

“Precisely,” I affirmed. “And Litmus Chaos provides the platform to do just that. It lets you define experiments, observe the impact, and analyze the results.”

“What about other tools like Pumba?” Murthy asked.

“Great Question,” I said and continued, “Pumba is also a great Chaos engineering tool that works seamlessly with Docker and Docker Containers. Using this tool, Chaos Engineers would be able to disturb docker containers by crashing containerized applications, emulating network failures, and stress-testing container resources (such as CPU, memory, fs, io, and others)”

Murthy leaned back, deep in thought, and said, “So, many tools are available, and many more might come in the future. That’s great news, but as a budding Site Reliability Engineer (SRE), How do I determine which tool to use? When to use? How to use?”

“Indeed, that’s a very pertinent inquiry,” I went on, “This is where the principles of Chaos Engineering prove invaluable. Honestly, there’s no universal solution. In due course, you’d organically grasp the ins and outs as well,” I grinned and carried on. “In my experience, grasping Your Objectives, Assessing Tool Suitability, delving into Community and Documentation, comprehending the Flexibility you have in conducting Experiments, the Integrations required for your system, absorbing and interpreting Community Feedback can lead you to the right tool for the right scenario,” I paused for a moment and resumed, “You might stumble at times, learn from them, and swiftly embrace new methods, Iterate and Learn.”

Chapter 6: Building Resilience

Murthy leaned back, deep in thought. “So, by embracing chaos, we build resilience?”

“Absolutely,” I agreed. “Think of it as stress-testing your system. By exposing weaknesses through controlled chaos, you can address them before they become catastrophic failures.”

Chapter 7: Embracing Change

Murthy glanced out the coffee shop window, lost in thought. “But shifting to a chaos engineering mindset – getting everyone on board – how do you do that?”

“It’s a cultural shift,” I explained. “Teams need to see failures as learning opportunities, not as blame. Chaos engineering promotes collaboration and shared responsibility.”

Chapter 8: Embarking on a New Path

Murthy closed his laptop, a newfound determination in his eyes. “I want to learn more about chaos engineering tools. Where should I start?”

I smiled, “Start by installing open-source tools like Pumba and Litmus Chaos. Then, dive into the documentation. And remember, I’m here to guide you every step of the way.”

Chapter 9: The Unforeseen Awaits

Days turned into weeks, and Murthy immersed himself in the world of chaos engineering. He experimented with Litmus Chaos and Pumba, ran tests, analyzed results, and collaborated with the development team. Along the way, Murthy discovered vulnerabilities they never thought existed and gained a profound appreciation for the power of chaos engineering.

Chapter 10: A Resilient Future

As time passed, Murthy’s projects became more robust and more reliable, and the team’s approach to failures transformed. Failures were no longer dreaded but anticipated, for they brought valuable insights. The culture of resilience blossomed.

Ultimately, it was not about mastering a tool or a concept. It was about embracing the unforeseen, adapting to change, and building systems that could stand tall against the unpredictability of the digital world.

Epilogue: A Journey Unveiled

And so, Murthy’s journey into chaos engineering continued. With each experiment and analysis, Murthy took one step closer to becoming a true champion of resilience. With the help of Shan, he completed Chaos Engineering Practitioner and Professional certifications from Gremlin. As for Shan, He watched with pride as Murthy flourished, knowing that the lessons learned would reverberate through the ever-evolving landscape of technology.


Cigniti Technologies, a global digital assurance and engineering leader, offers various services, including Chaos Engineering. They have 150+ experienced engineers skilled in designing and executing chaos experiments using various tools like Chaos Monkey, Gremlin, and Chaos Toolkit.

Over five years, Cigniti has demonstrated expertise in delivering engagements for Banking and Financial Services clients, identifying weak points, and ensuring system recoverability. These experiments validate the system’s ability to handle adverse conditions and ensure service continuity with 3rd party systems.

Need help? Contact our Chaos Engineering experts to learn more about embracing chaos engineering.


  • Ravi Bhushan Konduru

    Ravi Bhushan Konduru (aka Shan Konduru), brings over 26 years of extensive experience within the IT industry, with more than 8 years dedicated to Cigniti. His extensive list of certifications includes GCCEPro, GCCEP, SPC, CSP, CSM, SA. Shan's expertise spans across various methodologies such as SAFe, Agile, Scrum, Kanban, RUP, and Six Sigma, with a strong track record of overseeing projects and programs. He has played a pivotal role in enhancing delivery processes and methodologies through technological innovation, benefiting numerous Fortune enterprises.

Leave a Reply

Your email address will not be published. Required fields are marked *