The 12 Scenarios of Failure: Applying Chaos Engineering to SAP at AWS artwork

The 12 Scenarios of Failure: Applying Chaos Engineering to SAP at AWS

Dev Interrupted

February 6, 2024

On this week’s episode, host Conor Bronsdon sit down with Guilherme Sesterheim, SAP DevOps SRE Engineer at AWS. Guilherme delves into applying Chaos Engineering and DevOps principles to SAP, a domain traditionally seen as risk-averse and resistant to rapid innovation.
Speakers: Guilherme Sesterheim, Conor Bronsdon

Topics: Technology

**Guilherme Sesterheim** (0:00)
Let's break the application, let's kill some process, let's see what happens. You can inject failures on the network, so let's add some latency. And wow, latency in the SAP world is one of the hardest things to spot. Let's inject a system crash, let's inject some DNS failure, some resolution failure, and let's see what happens.

**Conor Bronsdon** (0:18)
Is your engineering team focused on efficiency, but struggling with inaccessible or costly Dora metrics? Insights into the health of your engineering team don't have to be complicated or expensive.
That's why Linear B is introducing free Dora metrics for all. Say goodbye to spreadsheets and manual tracking or paying for your Dora metrics.
Linear B is giving away a free, comprehensive Dora dashboard packed with essential insights including all four key Dora metrics tailored to your team's data, industry standard benchmarks for gauging performance and setting data-driven goals, plus additional leading metrics including merge frequency and pull request sites. Empower your team with the metrics they deserve. Sign up for your free Dora dashboard today at linearb.io/dora, or follow the link in the show notes. Hey, everyone. Welcome back to day two of Dev Interrupted at DevOps Enterprise Summit. I'm your co-host Conor Bronsdon, and I'm joined by Guilherme Sesterheim, SAP DevOps SRE engineer at Amazon Web Services. Gil, welcome to the podcast.

**Guilherme Sesterheim** (1:16)
Very nice to meet you guys. Thank you for the introduction.

**Conor Bronsdon** (1:18)
It's a great pleasure to have you with us. I know you're a speaker here at the summit. I know you had a really interesting talk on applying chaos engineering techniques to testing SAP installation.
Can you dive into that? Chaos engineering is a fascinating topic.

**Guilherme Sesterheim** (1:31)
I come from a very strong open source and DevOps culture, so I'm pretty comfortable with regular languages like Terraform, Jenkins, Ansible. So all of these open source technologies I'm very comfortable with.
Around three or four years ago, I joined AWS. I worked for the professional services, and I joined an SAP team. So I do have some SAP background as well, from, I don't know, the very beginning of my profession. But then I bring in all this load of knowledge and information around the open source part into the SAP world.

**Conor Bronsdon** (2:04)
Which is atypical for SAP.

**Guilherme Sesterheim** (2:06)
Very much.
I don't know if everyone is familiar with, so it's a huge company. Yesterday I brought one very nice number just to show how big they are on the presentation. So basically, if you look for that on their website, they say that 77% of world's transaction revenue passes through at least one SAP system. 77% of everything, all the money that flows through this world touches at least one SAP.

**Conor Bronsdon** (2:32)
That's incredible.

**Guilherme Sesterheim** (2:33)
That's amazing. I don't know any other company that has a metric huge like that. So SAP is this very mature and also a risk adverse company.
So yes, they are slower than other companies into modernizing their applications. So basically what we approached yesterday was then how do we bring some modern technologies, some modern practices actually, like the Chaos Engineering, into the SAP world. So basically there are some stuff that we can do right now, nowadays, testing how resilient your servers on SAP are. Yesterday we focused 100% on HANA, which is the database from SAP, an in-memory database.
So basically approaching some concept of how do we inject failures? How do we check how things went? So did the database behave exactly like I was expecting before the failure injection? Or did something go wrong while I was doing that? So there are some techniques, some things that we can do using open source technology into the SAP world without going inside the SAP. So that's when things get more strict when we talk about SAP. But when we are still talking about the server, there's a lot we can do around the operations already.

**Conor Bronsdon** (3:49)
Interesting. So it's more about using open source techniques and chaos engineering to extend SAP's capabilities.

**Guilherme Sesterheim** (3:55)
Exactly, exactly. So when we talk about DevOps for SAP, the most common question that I have, questions that I get, I can separate them into two. So DevOps inside SAP, and yeah, that's very complex. We don't have a lot to do there. And frankly, it's hard.
Of course, SAP has some offer because it's a buzzword. So it makes sense to talk about DevOps inside SAP. But honestly, there's not much, in my opinion, not much value that is generated by doing DevOps inside SAP because of the limitations.

**Conor Bronsdon** (4:29)
You're just so limited on what you can do.

24 more minutes of transcript below

Thousands of transcripts fetched by people building searchable podcast archives

Feed this to your agent

Try it now — copy, paste, done:

curl -H "x-api-key: pt_demo" \
  https://spoken.md/transcripts/1000651996090

Works with Claude, ChatGPT, Cursor, and any agent that makes HTTP calls.

From $0.10 per transcript. No subscription. Credits never expire. Prices exclude VAT, added at checkout for EU customers. Not what you expected? Email us within 14 days with 20 or fewer credits used and we refund the pack in full.

Using your own key:

curl -H "x-api-key: YOUR_KEY" \
  https://spoken.md/transcripts/YOUR_EPISODE_ID