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.
With expertise in both open-source technologies and SAP, Guilherme shares how he’s bringing modern practices to SAP environments at AWS. He explores how Chaos Engineering can be used to test and improve the resilience of SAP systems, focusing on HANA, SAP’s in-memory database. The discussion also touches on the challenges of integrating these practices within the SAP framework and the broader implications for SAP users and the tech industry.
“You can inject failures on the network, so let's add some latency. 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.”
Episode Highlights:
- 01:20 What does it mean to apply chaos engineering to testing SAP installation?
- 05:05 What does it mean to have DevOps around SAP?
- 06:58 Guilherme’s approach to DevOps practices around SAP
- 11:01 The challenge of handling installation and migration
- 12:50 How to start applying Chaos Engineering to your SAP instance
- 17:57 The 12 scenarios when you inject failures on SAP
- 18:24 How Guilherme ended up at AWS working on SAP
- 24:14 What’s next in DevOps Guilherme is excited about
Episode Transcript:
(Disclaimer: may contain unintentionally confusing, inaccurate and/or amusing transcription errors)
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.
Ad Read
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 LinearB is introducing free door metrics for all. Say goodbye to spreadsheets and manual tracking or paying for your door and metrics. LinearB is giving away a free. Comprehensive Dora dashboard pack the central insights, including all Forkey Dora metrics tailored to your team's data. Industry standard benchmarks for gauging performance and setting data-driven goals. Plus additional leading metrics, including emerge, frequency, and pull request size. Empower your team with the metrics they deserve. Sign up for your free Dora dashboard today at LinearB dot IO slash Dora. Or follow the link in the show notes.
Conor Bronsdon: 1:03
Hey everyone, welcome back to day two of Dev Interrupted at DevOps Enterprise Summit. I'm your co host Conor Bronson and I'm joined by Gilerme 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
All right. It's a, it's a great pleasure to have you with us. I know you're, uh, a speaker here at the, 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 don't know, I'm pretty comfortable with regular languages 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. I don't know if everyone is familiar with, so it's a huge company, uh, 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 percent of world's transaction revenue pass through at least one SAP system.
Conor Bronsdon: 2:26
Wow.
Guilherme Sesterheim: 2:26
77 percent of everything, all the money, that flows through this world, touches at least one. That's incredible. That's amazing. I dunno, any company, any other company that has a, a, a metric huge like that. Right? So SAP is this very, mature and also, a risk adverse company. Yes. Uh, so yes, they are slower than other companies into like modernizing their, are their, their, 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 percent on HANA, which is the database from SAP, and in memory database. So basically approaching some concept of how do we inject failures? How do we check of, uh, how that, how things went? So did the database behave exactly like I was expecting before the failure injection, or I don't know 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 Uh, 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.
Guilherme Sesterheim: 4:30
Yes. Yeah. So it's hard for, I dunno, automating tests. So a very few, a very small number of companies is already using Git for SS a p, so Everybody's using it except, uh, SAP, uh, except the, the developers that go inside. SAP, right? Yeah. And the second bucket. So DevOps inside SAP? Yeah, it's very shy. It's, it's hard. There's not much value added to the companies that want to use it. Of course, there are some things that we can do, but again, not much value added. And on the second bucket we get then the DevOps around SAP and basically that's how I call it around SAP because you're not going inside, of course. Then you can get the servers, you can interact with the servers. So I work for AWS my examples go into the EC Choose and, and how we do things inside AWS Yeah, so basically when you install SAP in a server, you have there, your easy choose is standing and the regular procedure for, I dunno, any major application inside big organizations, is that okay, you installed something, it's working, you leave it there, you don't touch it. So that's the regular, how things go, right? Besides, I don't know, your patching windows, your security maintenances, you don't touch that very often. So all the suggestion presented yesterday was around, let's try to shift that mindset a bit more from that famous analogy from pets versus cattle, which is pretty famous for DevOps. Extremely new when we go to SAP. So let's try to shift that focus a bit more. So there are companies that used to do their high availability testings every six months. We can, yeah, so that's a lot. And the majority of them,
Conor Bronsdon: 6:03
If you're not watching on YouTube here, my eyes just got very big.
Guilherme Sesterheim: 6:08
But that's the typical. So the majority of companies, at least that I interact with, big companies here in the States, they do like every six months. Some of them, they do three months. And I heard about one customer that want to do that, uh, every two weeks. So that was the most aggressive one I've ever heard. So Yes, we can do some, we can combine some of the DevOps practices, some of the DevOps non technologies, so we can speed that up, we can do those testings more often, and we can be better prepared for, I don't know, failures and things that typically happen. And we are just waiting for them, right? So instead of just waiting here, seated at my chair, let's do something more proactive.
Conor Bronsdon: 6:47
Let's try to go ahead and solve the problem in advance. It makes total sense. Like, you've talked about a couple of examples here of how you're leveraging DevOps practices to extend SAP's capabilities, and enhance the approaches you can take around automated testing and other things. Are there different categories of DevOps practices that you're applying? Is it mostly around testing? What's your approach?
Guilherme Sesterheim: 7:07
Yeah, so what I've seen and the opportunities, so I come from a very strong SAP, again professional services inside AWS. So we interact with biggest companies here in the states, like huge shops of SAP. So we try to focus more on the opportunities and the struggles we see, like on the market. This is very nice because we interact and we learn a lot every single day, whenever we talk to a new customer or an existing customer about the struggles that they are having. So what I. What I guess that all of the automations and all of these improvements we've been working for the last two or three years, I guess they kind of categorizing something around the operations part.'cause again, we cannot go inside SAP, right? We do, but it's not very much nice. Uh, but then we go into the operations. So again, automating this, uh, chaos engineering part, um, automating the, the auto-scaling for SAP. So again, auto-scaling is something very. usual, I can say. But that's pretty tricky when you go to SAP and you cannot do all the scaling in the majority of the servers, so you do all the scaling in just one or two of them. Mm-Hmm. So even that. The automation is not like a streamline, it's not a simple flow like we have for with other applications. Totally. Uh, so you have to have a strategy of how do you want to, to autoscale and also the limit of your out scaling. So I can summarize that into the operations part.
Conor Bronsdon: 8:32
Yeah. I'd love to understand the, the strategy piece. What's the, what's maybe a typical or example strategy that you would take to, to implementing this?
Guilherme Sesterheim: 8:40
So, a typical SAP landscape, you have the database, so let's use Hanna here as a, as the example, right? So, uh, the in-memory database from SAP, you have an A SCS and ERS and I'm sorry, I don't remember all the, what, the, what does that mean?
Conor Bronsdon: 8:54
We're gonna use a lot of acronyms. That's okay.
Guilherme Sesterheim: 8:55
But basically that's an in Q server. So that guy centralizes all the requests between the platform internally, so it's pretty important. And here we already start seeing some stuff so different. names that SAP gives to common things that the open source world knows. So, D A S C S is always the primary one. And A S C S is always working. If that guy goes down, E R S takes up. Which is basically the same software, the same software installed, but once A SES is primary and ERS is secondary. That's the rule. So it's not the same application that you're deploying to different servers. So they are different applications, but they work in a high availability scenario. Now getting to your question, the third layer of this, of database, q server, and then the third layer is actually where your users connect to. So that is the PAS primary application server, something like that. That one I remembered. And when you want to auto scale SAP, so you don't talk about database, you don't talk about the NQ server, you just talk about where your users connect. And if you have just one server right now, and the database is working fine with that one server, that same database will have to handle well if you have 10 servers. So that's a struggle in planning from the very beginning. So that is the only guy, the PAS, that you can auto scale. I don't know, 1, 2, 3, 6, 10, 20, I don't know, 30 servers for the biggest shops out there. Then your users will connect there, and again, your database has to handle that. So you have to have a very powerful, big instance. Because again, just one of them, even though you have two databases, let's say, for high availability. Uh, two Q servers. Only one of them is always the primary, and the other one is just idle waiting for something to happen.
Conor Bronsdon: 10:37
Interesting. So, I mean, this is intriguing. Obviously there's a massive scale. This, as you mentioned, 77% of worldwide monetary transactions have at least one SAP connection in them. There's clearly some distinct challenges that you're facing in trying to extend the capabilities of DevOps to SAP because of, to your point, how, conservative they are about what moving forward. Are there other challenges you'd like to highlight, that maybe we haven't dug into so far? Areas you want to dive into more?
Guilherme Sesterheim: 11:04
Well, I guess that one of the biggest challenges, uh, we see out there is still this huge complex, uh, installation and migration process. And that's understandable, right? Because this is usually the spine of every organization is an SAT server, right? So if you are doing anything, I dunno, your your orders system, your, online cards. So all of that is working in a different layer. And after that, that's pushing data inside SAP. So SAP is usually the spine of every organization. So we are very much used to, I dunno, talk about integrations on SAP as well. One of the biggest challenges we still see, and honestly I dunno very much about how SAP's vision for that, for the future, how they're investing on that is still so breaking these huge I cannot say single, but few points of failure. So still, if you want an SAP, you have to go under a complex project some months for sure. Installing things. And so you cannot do SAP inside Kubernetes. That is one example. Hmm. So these common stack, I told you, of course there are examples, hybrids, which is SAP's, e-commerce runs on Kubernetes. That's nice. That's not as simple as, I dunno, installing SonarCube or uh, Atlassian Totally. Or these other guys. So those guys are pretty so simple. You just. Connect there and
Conor Bronsdon: 12:19
plug and play to some extent.
Guilherme Sesterheim: 12:20
Yeah, so they're very simple. So SAP doesn't work that way. So this is, I guess, the main challenge that still blocks a lot of things from, I dunno, for even modernizing even more. So you don't, still don't talk about microservices on SAP and it's a long journey to get to there. So for me, this is the biggest challenge because since we have so few big points, so many few, that's nice to say, so many, few big points of failure, breaking those should be simpler, I don't know, for further modernization.
Conor Bronsdon: 12:52
Right, yeah, and it's interesting to talk about this in a chaos engineering context, because it really limits the potential of the testing you can do. What advice would you have for people who either listen to your talk or listen to this podcast, but how to start approaching this and saying, Okay, I want to apply chaos engineering techniques to my SAP instance. I want to start trying to extend this. How would you recommend they get started?
Guilherme Sesterheim: 13:16
Yeah. So this is kind of the mindset that I've been applying since I started to interact with SAP again. So again, I mentioned that I did have some SAPs experience, then I shifted into the open source, and now I am, I am an SAP folk again. What I've been doing is, every time that you, talk to an SAP expert, you're gonna say, Hey, I wanna do chaos engineering for SAP. He's gonna laugh. He is gonna say, yeah. Are you nuts? What is chaos engineering, first of all, what is chaos Engineering? The same subjects. They don't flow with the, the SAP totally world as well.
Conor Bronsdon: 13:47
Do you wanna do a brief definition for folks? I, we've had episodes on this before, but I wanna make sure everyone here has a definition of chaos engineering, just to make sure they have something in their head.
Guilherme Sesterheim: 13:54
So basically chaos engineer is, is you injecting failures in your servers, in your applications. Not just, not just the servers on purpose in a controlled environment, in a controlled way, so that you can prepare for the worst scenario. Yeah. Some examples you can inject failures inside your servers. Like I said, I dunno. 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. I dunno, a system crash, let's inject, uh, some DNS failure, some resolution failure, and let's see what happens. So case engineering goes all around that, injecting things, errors on purpose, and hey, let's see what happens. And once we see what happened, let's come up with a plan so that thing doesn't happen for real when a real scenario is here.
Conor Bronsdon: 14:43
Totally. The, thing I really love about Chaos Engineering is it's, it's such an iterative way to drive continuous learning and to prepare your, your company, your team, your technology. for a worst case scenario. And particularly when we're thinking about something like SAP that is so integral to the way the world works with payments, uh, it seems like having that injection of failure so you can understand how to improve it and make it safer, uh, would be crucial. To your point, you've kind of alluded to this, like it's a little concerning that it's so hard to test failure because that means in a worst case scenario, which they do happen, even to companies like SAP, there is so much potential for us not to be prepared.
Guilherme Sesterheim: 15:23
So even on the newest releases of SS a P, which are, which is called BTP, uh, I guess it's business technology platform, which is like the very, very new, I dunno if it was released still in 2022 or 2021. I don't remember. But for SAP, that's extremely new, so a very few number of customers are already using that. So that guy's supposed to have microservices and a more modern approach, but again, it's extremely new for SAP users, and it's still blurry exactly what you can do. So I've been talking to some of my personal friends that work on SAP. They told me, okay, yeah, you can do this, you can do that.
Conor Bronsdon: 16:06
So there's potential, that's great to hear. So I sidetracked you a little bit, but I was wondering about the strategy that you'd recommend to folks who are trying to extend, uh, the capabilities of SAP and start doing some of this chaos engineering testing.
Guilherme Sesterheim: 16:18
Oh, yeah. So, so that's basically what I've been doing for the last three to four years. If you go to an SAP four and you say, Hey, let's do chaos engineering, SAP P Oh, wow. Who's gonna laugh? Yeah. Right. Uh, if you're gonna go, if you wanna talk to them and say, let's do unit testing, they just say, why? So they don't get the importance of that. So basically what I've been doing, I've been trying to ask the right questions on and, and trying to engage just on the right battles because everything that I've been here for, for this operation side, again, so not talking about DevOps inside SAP about this operation side, chaos engineering, out scaling, as I said, so some more regular maintenance operations that we have. Whenever I ask a question and they say, yeah, that's not possible, I ask why. So far, always the response is vague. So basically it's because I don't know, or I'm not sure. Yeah, in theory that can work, but I don't know. SAP is not gonna support that. Things like that. So SAP not supporting stuff is, is also another big blocker for that. Uh, but again, so my suggestion is. Let's, let's try to, to, to, to challenge those, those common nouns, that are out there. So usually SAP folks have been working for organizations, I don't know, for 20 years, 30 years. So they are very, um, uh, again, conservative on what, on the practices that they apply. And sometimes they don't know. What they don't know. So if they're not sim uh, uh, familiar with the chaos engineering concept, they are not sure, how can you tell me? We cannot do chaos engineering for SAP. Right? So my suggestion is let's challenge those things that we don't know. And because many of them so far per my, uh, researchers, my work with customers, uh, they are possible. We just are short of people implementing them.
Conor Bronsdon: 18:00
And my understanding is you have 12 scenarios of failure that you've identified in particular.
Guilherme Sesterheim: 18:05
Basically, so these are 12 scenarios where you inject failures on SAP and the example of yesterday was this Hanna database, uh, to again, see what happens. So basically there are some commands specifically to, to SAP, like HDB stop pacemaker. So pacemaker is a library that you used to put the, the nodes in synchronization. So it's a cluster, uh, tool clustering into, so basically you inject errors. Each one of these 12 items, it's one error that you inject on the server. So first one I said, HDB stop. It's not actually an error, but it's an unexpected behavior for the cluster. So you're basically, you have two servers running and you're going to go there into the primary and you're going to say, Hey, stop. Let's see what happens. So the first thing that it's going to tell is if your high availability is set up properly for this scenario, okay? Because this is just one of the scenarios. So all of the 12 go around something like this. The one that I find more interesting is the one that I guess it's So closer to what we hear from Netflix practices. So what do they do for injecting failures on their application? So one of the last one of these 12 is basically you go, they are into the Linux server, and you inject an error. You basically echo something into a very specific process that happens in Linux, and that's going to make the instance crash. So first the instance freezes, and again, so that's the Scenario I like the most because the instance freezes. So the instance doesn't tell its peer. Hey, I'm gonna go down the instance doesn't tell AWS, hey, I'm gonna go down So basically the instance freezes after two or three minutes AWS realizes that the instance finish Froze then AWS stops the instance and then yeah, there you go. So this is unexpected. So nobody ever told anyone that, hey, I'm going down, the first instance.
Conor Bronsdon: 19:54
Decent bit of lag time built in there.
Guilherme Sesterheim: 19:56
Yes, exactly. So let's monitor if the second one is going to pick up from there, like expected. And so this is my favorite scenario so far of these 12 you mentioned.
Conor Bronsdon: 20:05
Fantastic. Uh, it's interesting you mentioned Netflix. Obviously, they do a fantastic job of approaching chaos engineering. Um, I'll shout out that we had Nora Jones, formerly of Netflix's chaos engineering team. Uh, on the podcast earlier this year, great episode. If you're looking for someone to follow up on this and learn more about chaos engineering, these two will fit really well together. I'd love to dive into how you got here at Guilherme. How did you decide that this is the, this is what you wanted to work on next? How did you end up at AWS doing this?
Guilherme Sesterheim: 20:33
I like to say that no knowledge that we ever got it throughout our, our entire life is, is useless. Right. So when I started there with my 17 eighteens, yeah, I was an ab app developer. AB app is the language that we used to develop inside SAP. It's proprietary for SAP. So I started like that in so worked like three years doing that. After that, my career just. shifted focus into more the open source area, which, When I started learning Pro programming coding, I was in love with Java, so I always loved the open source part. Uh, so I saw some opportunities back at the company that I was, I was an web developer, but, but I was seeing like this big team working in Java and they were doing great stuff, amazing stuff. So things that were new, I dunno, 10 years ago that we are talking about. Nowadays like, I don't know, Service Smash, where load balancers were extremely expensive, right? There was no cloud, still. But the adoption was not as it is today. So I was seeing those guys doing this amazing stuff. 100% the open source part. And when I saw this opportunity at AWS, I always loved the company because when we started working with the cloud, AWS, it's the main player so far. Absolutely. Yeah. And I, Hey, I, I wanna work on AWS one of these days,
Conor Bronsdon: 22:02
Here you are.
Guilherme Sesterheim: 22:03
Yeah. So when I saw the listing for some DevOps inside SAP. DevOps sAP engineer or DevOps, SRE engineer. Maybe that's something that would be interesting. So I applied myself, I discussed with my, uh, previous manager, uh, and he said, yeah, that's basically what you're looking for, the questions I made, right? Yeah. So we were basically looking for more automations and doing things for our customers faster. That's when I landed AWS and it's been great. Fantastic.
Conor Bronsdon: 22:33
Are there other things happening at AWS that you wanna mention as far as. You know, exciting work being done, things that you see coming down the horizon.
Guilherme Sesterheim: 22:40
Yeah, so my team works directly, so I'm not from a services team, so everything that I do, you won't find in the co console, like looking for, I dunno, RDS or EC2 i, I don't do that. So basically I support customers that are doing, uh, I dunno, they are migrating or they are evolving there, they're doing something inside the WS. Let's say you are a customer, you are looking to, again, migrate or evolve or do something inside the WS and you want an expert to know how to best run E-R-S-A-P inside the WS, that's when my team comes in.
Conor Bronsdon: 23:09
Perfect.
Guilherme Sesterheim: 23:09
So the things that we do there the most, so again, we try to modernize and to acceler. It's the journey of customers to go into AWS. Because again, these projects for migrating stuff, they take years, so they are very expensive. And this is what we've been focusing a lot. So nowadays we have tremendous levels of automations and we can have, I don't know, just new joiners, guys that have just joined the organization. We have like this huge set of automations, Terraform, CloudFormation, Ansible, Bash, whatever, to help them to be Faster and to provision things faster and to help the customers faster. So this is something that we are always looking for because this is what customers, I dunno, are most talking about. Right. So AWS is just very customer obsessed company as everybody says. Absolutely. And, and, and, yeah. So we like to keep hearing what our, what our customers tell us and then invest on that. So again, shortening the time to, to, to, to deploy stuff or to modernize right now. Uh, so just from, from some experience, I'm working on this project where we are, uh, migrating, some applications into Kubernetes. So a few of them that SAP allows. Hmm. That's, that's really nice.
Conor Bronsdon: 24:17
Interesting. I, I'm also curious, given that we're here at DevOps Enterprise Summit, what are the things that are happening in DevOps and around the industry that you think are gonna be kind of the next applications of techniques or, or strategy that you see coming?
Guilherme Sesterheim: 24:31
For me, and I heard that yesterday in, in many different ways from many different speakers here at the conference, and this is something that for me is. It's, it's great to hear because it's something that I believe a lot. So something that we were not used to here like 10 years ago was this psychology part, getting more into organizations. So when I, whenever we talk that developers have to be happier to be more, productive whenever we talk that managers, they have to be happier or, I dunno, happier is not the word, but more comfortable, more, more empowered, more.
Conor Bronsdon: 25:11
There's research that shows that when teams feel empowered and that their work is impactful, they are happier and they perform better. And we're seeing more and more signs of that, to your point, like, with, like, happiness being such a predictor of retention and success on productivity.
Guilherme Sesterheim: 25:26
And so this is something that I believe and I keep following, so looking for the stuff that I'm reading and I'm learning, I'm studying about. So this entire, let me use, again, the psychology world work here for the organizations. So we are taking better care of people, we are taking better care of managers, of individual con contributors. Uh, so the entire organizations are talking about that right now. And this is like a great beginning. I'm not saying that we are just in the beginning, but this is something already, if we take a look like 10 years ago. It was just like you do as I say. So we are shifting this mindset and when this happens, and it's just not it, right? It's for the entire, I dunno, any other industry, when folks are more comfortable and when they, I dunno, they trust their employer. They do their jobs better. They're delivering better software, higher quality products, absolutely higher quality. And more than that, what catches me the most is that we are investing in that folks, on those folks lives. Because if you're happy, I dunno about you. I spend, I dunno, eight, 10 hours a day in my work every day. So if I'm awake. WorkerB, WorkerB, WorkerB, WorkerB, WorkerB, So if you're happy at work, you will be very more, very much likely to be happier, I don't know, with your spouse, with your children, with your family. And then you start like thinking broadly, you, you won't care just about yourself. You care about, I don't know, the environment, you help your community, you have your neighborhood.
Conor Bronsdon: 27:07
So great perspective.
Guilherme Sesterheim: 27:08
Yeah.
Conor Bronsdon: 27:09
Yeah. I think there's, there's too many folks, particularly years ago who kind of took this perspective of like, We're going to, like, use folks up in a way. We're going to use their efforts. We're going to push through it. And I think what we've discovered is, like, creating a more sustainable social circuitry that really programs teams to be more successful and happier is more sustainable for the team. It's better, to your point, for the individual and, I'm sure, their community. And it's also better for the company because it lets them be more customer obsessed. It lets them dive into their work more and be passionate. They're going to spend that extra care to understand and dive into it. And so I think it's a really wonderful thing we're seeing. And on that note, I'd love to ask you. You're very clearly passionate about chaos engineering, about the work you're doing at AWS. Are there any closing thoughts you want to share with us?
Guilherme Sesterheim: 27:59
Yeah, so loving the conference. So this is a very nice, um, I don't know, set number of talks here, speeches we've been hearing. And again, I love to hear that we are investing more and more with this, uh, culture thing. Definitely. So just, just about the book they, they released yesterday, uh, I was watching the presentation where they mentioned briefly what the book's gonna, uh, and,
Conor Bronsdon: 28:23
And just to clarify, this is Wiring the Winning organization by Dr. Steve Spear and Jean Kim. We interviewed, uh, Dr. Spear on the podcast. I'm not sure if it's gonna be out already by the time we release this, but definitely check it out if it is. It's great. Great talk.
Guilherme Sesterheim: 28:35
Awesome. Yeah, so basically that book, from what I understood of their speech, introducing the book, they're basically, Approaching same culture, same, uh, concepts that we are used to know, but in a different way.
Conor Bronsdon: 28:48
And I love that. And we program high performance teams.'cause there are exactly consistent, like there's consistent high performance across different companies, right? Like companies with the same resources, the same initial approach, build better teams and are more successful. Like, uh, the, the example Dr. Spear used on the podcast was Toyota, which is like vastly outperformed in what employees are capable of because they've intentionally built these happy, high performing teams that are, you know, cut down on friction points and are set up for success. That's a great highlight. I really appreciate you bringing that up, Guillermay, and thank you so much for coming on the It's been a fantastic pleasure chatting with you, getting to know you a little bit. Hope to talk to you again soon.
Guilherme Sesterheim: 29:25
Awesome. Thank you very much. Thank you for the invitation as well. It's been great. Thank you for the, I dunno, the partnership here in the conference.
Conor Bronsdon: 29:30
Our pleasure.
Guilherme Sesterheim: 29:30
That's awesome.
Conor Bronsdon: 29:31
If you want to hear more thoughts from incredible leaders like Gil, me, check out our substack devon opted.substack.com. We put out articles every Thursday, deep dives into concepts like Chaos Engineering on SAP and also, uh, our Tuesday editions include articles from our community. our partners, and of course our podcasts. I hope to talk to you all soon and thanks for listening.