Challenges In Solutions Engineering

Challenges In Solutions Engineering

24. Januar 2023 | Code Comments Team

Anwendungsmodernisierung

Partner

Code Comments • • Challenges In Solutions Engineering | Code Comments

Challenges In Solutions Engineering | Code Comments

About the episode

Change may seem exciting for some. But for those who are moving from one platform, or one technology, to the next, it can be a daunting, anxiety-filled experience. For Dynatrace’s Markie Duby, keeping empathy at the center of one’s work is crucial for building trust and for collaborating with customers as they adapt to an industry that never stops moving.

Code Comments Team Red Hat original show

Transkript

I have spent a lot of years thinking about how customers and users adapt to the ever-changing technology landscape that we live in. For people who actually produce new technological solutions, we think about how cool our amazing widget or gadget is our new code, our new process, our new API, our new SaaS product. Yet we also have to think a lot about what it means for that user to adopt that technology, and most importantly, enable a new superpower in that user. Give them the time to value that they seek. I'm Burr Sutter and this is Code Comments, an original podcast from Red Hat. For today's discussion I talked to Markie Duby, Principal Solutions Engineer at Dynatrace. She has been in a customer facing role throughout her 10-year career at Dynatrace and has a ton of experience related to helping customers adopt new technology.

I started on our professional services side where I was actually a full-time consultant for some of our customers. So I was in their offices working with them side by side, setting up, configuring our systems and helping them out. And then I moved over more into a training role where I would visit multiple customers in any given month and walk them through if they were brand new, especially, "This is how you set things up, this is how you can use this, this is how it's going to help your teams." And then just a few years ago, I actually moved over into the solutions engineering side of the house. So now I help prospects look at the product and see what they can do and walk through proof of concepts and how they can actually build that out, which is great.

Well, I really love that journey that you described there because I've also been a consultant myself, a trainer and educator myself, and a pre-sales person as well in terms of supporting sales teams and things of that nature. And what I love about that arc when it comes to career path is it helps you build a lot of empathy for the user base and for the customer base. So can you talk to me more about maybe some specific examples where you might have had to meet a customer where they were, you were in their offices, but sometimes it's hard to move them along the path when it comes to the learning journey of the product?

No, it absolutely is. And it's one of those things that, it's kind of interesting because you meet all different kinds of groups. Sometimes you walk into a group and they're ready to start installing and rolling things out and they've got all their automation and everything built out on day one. And sometimes you walk in, it's like, "Okay, wait, we don't have our server ready yet. So we have to kind of think about it a little bit." But I think one of my favorite examples is when I came into a customer's environment and they're getting ready to set everything up and I said, "and now once we install everything, we're going to start base lining your systems and we're going to start tracking the normal behavior and we'll tell you when it degrades." And they said, "Well wait, we have to set up alerts." I said, "No, it does it for you." And they didn't quite believe me. And they're like, "No, you know what? We're going to set up our own anyways." I said, "Okay, let's go through. We went through and set those up." And they had our out-of-the-box alerting and they had their alerting set up and then I came back actually two weeks later to chat with them again and see how things were going. And they had turned off all of their custom alerts because they were like, "You know what? You're right, it worked." But it's just a mind shift of, "Wait, we can actually let the system think for itself and we can let it tell us what's going on." We get so used to the way that we're traditionally doing things that we just have that mindset. And sometimes it's a matter of, "All right, let's straddle a little bit for a while before we really take off on this new journey."

I think that's super interesting because I think a lot of people, especially with technical backgrounds, especially representing technical vendors like often and I represent Red Hat to customers and you're representing Dynatrace as an example, we tend to forget that that audience member sitting in front of us, that person we're training, teaching, consulting with is on their own individual learning journey. And it's fun and exciting to watch them go through that evolutionary process and get to the point where they had that, what I call the aha moment. It's like, "Ah, this is what I was looking for. I didn't believe you. I wasn't sure. I didn't understand. But I got there." And I think that's a very powerful moment, a very interesting aspect of what we do.

Yeah, my team actually, they make fun of me a little bit because everyone always asks me, "Why do you do what you do and what drives you?" And everybody's got different answers on, "I like the puzzle", "I like the challenge sometimes just this is what I do for a living, this is what I get paid for." Mine is always, "It's that aha moment." That's what I like to see. Because when you see somebody look at that and go, "Wait, that, oh..." That's the fun part, right? I can actually do that. That for me is what I get the charge from.

I am totally right there with you and I still go out and do a little training today myself. And that is the thing I appreciate also is when you actually see the light bulb go off and they go, "Wait, I got it. Now, I understand better why this thing works this way or how it works." And I think that's a very powerful moment.

Yeah, absolutely. I'm actually doing an internal training showing new employees how to work in the product, how to work with it, and not all of them are customer facing, but some of them are just maybe new to the industry, could be just new to the company in general. So this allows them to really be able to go through and get hands on and see exactly what our customers are seeing. So it's nice to have those conversations as well as they have that same experience that some of our customers do.

For those of you who don't know, Dynatrace is an observability platform. It is designed for application performance level monitoring where they're looking at response times and failures all the way down into the infrastructure from the browser or mobile application into the actual data center and helping you drill down into the root cause of those performance problems. It's pretty fascinating what you guys have had to do in the observability industry to think about what it means to scale that platform, especially when it comes to multi-cloud architecture or even on-premise architecture, hybrid cloud architecture or across many data centers. Can you tell me more about what you guys have been doing when it comes to moving to this cloud to multi-cloud world we're now living in?

Yeah, absolutely. I mentioned I've been with the company about 10 years, but the company's been around a little bit longer than that. And we have been going on that along the same journey as a lot of our customers have where we're moving from things like our own data centers, from monolithic applications into more microservice based applications, more distributed in the cloud using cloud native technologies. And we've actually done several iterations over the years. We did a pretty big shift about five, six years ago where we built a brand-new platform from the ground up, meant to run with cloud native environments. It was just one of those things where everybody knows in the technology industry, sometimes you can upgrade and you can upgrade and you can upgrade and patch software, but eventually you might just have to do a rebuild. And we did a rebuilt and we started from the ground up purpose built to use things like the AI engine that I talked about, purpose-built to be able to go through and actually track through these distributed systems, make sure it works with hybrid cloud and multi-cloud environments and that we could handle the dynamic changes of those type of environments. Traditional monitoring, you could go in and you could set specific thresholds, you could set specific trackers, but that doesn't work in a distributed cloud-based environment. That's changing too frequently. You might have five containers today, you might have 50 tomorrow. You can't go in and actually make that shift. So you need something that can grow and adapt with you. So we did that a few years ago and we've built up that platform and now we're actually taking a step back again and looking and saying, "Okay, now we've got to this point, we're actually able to handle this. What's next?" So we're actually on a brand-new journey right now where we still are building on that same platform. It's still the same heart and soul of what we built out with the AI engine and root cause analysis, but now we're actually expanding into a space where we can take a look and say, "Okay, we have all this data now what else can we do with it? It's great that we can do root cause analysis, it's great that we can do performance monitoring, but what else do we need?" And there's a lot of details there around business analytics and being able to take advantage of that data that we already have and translate it and pull it into other spaces. So we're actually now branching into more of an analytics space as well.

And that actually makes a lot of sense to me, right. I think a lot of customers have discovered that if they capture more data, and in your case even as a vendor, if you're capturing more data, you actually have access to all the inputs and outputs of that system. In this case when user transactions are flowing in, where the bottlenecks might be, what the performance characteristics are of different aspects of the overall distributed system, they're going to be opportunities for you guys to then perhaps provide optimization recommendations. As you mentioned, the AI engine and also just general, the wellbeing of the business. You guys have greater insight into that also, since now everything is a digital business. I'm really interested in this evolutionary path you guys have been on. So can you tell us more about that? What aspects of this would a customer have noticed along this path that you guys have been on and the path that they've been on in working with you on this?

Yeah, and it really is interesting because when we made the shift a few years ago, a lot of our customers hadn't made that jump yet. We had a few that had started moving into the cloud and started thinking about distributed systems, but a lot of them looked at us and said, "Wait, what are you guys doing?" We're still running at our data center. And what was interesting is we were still able to support those customers very, very well, right, in their traditional applications. But then as they started to take a look at how we were building things out and how we were actually rolling things out, we could also be kind of used as a model for, okay, this makes sense, this is actually a more efficient way to do this. And we can actually help through the platform itself, show them different ways of being able to do that. And that's exactly the same thing that we're doing now. In fact, in this case, we've actually had customers for a few years asking us, you have this data, I know this is in the system, I know what's going inbound, what's going outbound. We have this business report that we need to build. Can you help us out? Can we actually extract that data out and use it? And up to this point, we do have the data. We did allow the ability to do things like extract and do some custom reporting and being able to do that, but it wasn't necessarily native. It wasn't what the system was originally designed for. And now what we're actually doing is saying, "Look, yeah, we do have this data and we've spent some time working on it." This is not something that's been an overnight decision. This has been several years in the making. But now we actually are making a shift in such a way that all of that can also now be done natively. So not only are we doing the same performance tracking and analysis that way, we're also now providing the opportunity to get direct access to that underlying data, pull it out and do that business reporting and have it in context with everything else and have the ability to actually access that. And we're getting customers that are really excited about this because they have that flexibility. They can actually kind of touch that data and be able to get to it because they knew it was there because we were using it, right? But now they can actually do their own right reporting and analytics and build on top of it, which is what they're really excited about

As an organization. Dynatrace has had to adapt and Markie and her team have been out there helping customers evolve and meet their expectations and of course the experience around that technology. So Dynatrace has been working on the rollout of their next generation of their new backend system, and Markie told me how she and her team were out there supporting customers as they go through that transition.

So the new piece of the platform, which is actually currently being launched is something called Grail. And what Grail is is it's a data lake house, which is purpose built for observability and analytics to be able to rerun. And it's being built completely cloud native through some pretty massive parallel processing that we're building out. So we can actually be able to handle things like the data and the individual pieces that are actually coming into play. And one of the things we're actually doing is we're doing a controlled rollout of this. So we're starting with just small portions of our platform. And one of the things that we're starting with is logs. Because logs are just an abundant resource of business information, performance information, triage information, everything across the board. And everyone, when they look at this, there's always the question of, "Okay, how do we handle the logs because we have to worry about scale, we have to worry about retention sometimes for auditing purposes or regulatory purposes." So it's always a really large question of how do we handle this? So this was the first thing that we decided to tackle with Grail. And what we've actually been able to build out is something that allows our users to be able to access logs, to be able to do things like query the logs process, parse out those logs, be able to pull analytics and reporting from those logs and the data within them. Even if the logs are two months old, three months old, six-month-old, you don't actually have to go back and reprocess everything. You can simply go back and say, "Hey, I have these old logs, I want to parse those out. I want to do some calculations with these. I want to be able to pull that in." And that's something that's really hard to do in traditional systems because a lot of times when you pull the logs in, you're doing a lot of scraping and pulling out the individual pieces. Well, then three months from now, if somebody asked you for a brand-new report, you probably didn't pull out the right metrics, you probably didn't pull out the right pieces of that log. So you have to go back and reprocess those. Grail is built in such a way that we don't have to reprocess anything. We can simply pull it out on the fly and be able to build those type of reports and those type of analytics in real time, which is really great.

So this almost sounds like you guys have indexed the stream, and that may be the wrong term, but people don't really appreciate when it comes to log systems or the product that you guys have, the volume of data that's coming your way and then still be able to process it well in real time, just like you were saying there. Can you tell me more about that?

Yeah, it's really interesting the way that we've actually built this out. And again, I mentioned massive parallel processing before. That truly is what it is. And we are doing this by building out cloud native technologies. So we're actually able to roll that out very, very broadly. And we can have this as a shared infrastructure that all of our customers can access and be able to take advantage of that large system. And we're doing some auto indexing as things are coming in to the environment, but we're not completely reliant on just that index. We can actually grab any of the metadata that's being attached to that individual log. So we're looking at things like what process wrote the log, what host wrote it, what application that belonged to, what Kubernetes cluster did that run from? All of those individual pieces can then later on be searched and be parsed out. And I can build reports on those, which is really great because we're not dependent on traditional indexing solutions. One of the things that we are doing is as we're building out this new grail piece of our platform, it is actually being built in localized regions alongside our existing Dynatrace environments. So the nice thing about that is as our existing customers are already working with and utilizing localized instances of Dynatrace, they now don't have to change. They have that data local to their region so we can make sure we're staying within things like regulations for them as well as they have that low latency and everything is pretty seamless from their perspective because they're using the exact same Dynatrace environment, the exact same interface that they're used to. Now, what they have though is just a little bit more kind of power under the hood and they have more access to some of that underlying data.

So I have maybe a crazy question for you. When you were describing this concept of data locality, that low latency being in multiple regions, I love that concept and I love that architecture because that is very much a cloud architecture. That means I don't have to go build data centers all over the place. I can take advantage of these different clouds, different regions and get access locally to customers, right. How are they receiving the information? You've been out there talking to some of them I assume at this point. What are they saying?

It's funny because a lot of times the reaction that I get is almost the exact same reaction that I get the first time they see the Dynatrace platform and the way that we can do things like root cause analysis. They don't quite believe it at first. I get this, wow, but I know that's a demo environment. I want to see it on real data. That's usually the response I get, which, "Hey, great, let's try it. Let's try it with your data. Let's go see what it looks like." Because it is one of those things sometimes you just can't quite believe until you see it, which is nice. And again, it is the same reaction that I get when I do the demo of the traditional just root cause analysis and automatic detection engine that Dynatrace already has. It's usually the same reaction, is "I don't believe you guys can actually do that. That looks truly cool, but let me try it because I have to see it to believe it."

Well, if a customer does want to actually see it on their data, what does it take to actually set up that proof of concept and get them going on that journey?

Well, what's really great is for our existing customers, it's actually pretty easy to do because, again, it's the same setup from their side. They have the same environment, they have the same data. Nothing really changes from their side. From our side, we go in and we can actually make a shift and say, "Okay, instead of sending log data to the traditional storage, let's switch that over." And our team has been really great on just making this as seamless as possible. I really have to give kudos to our lab on that because it's been so nice just to do that quick switch. It's a switch on our side in our customers environment. They actually get the opportunity to say, "Okay, yep, I'm ready to go." They click a button and it's switched over and now all of the new data that comes in actually will then flow into this new grail platform and they get the full advantage of what that looks like. So it really is pretty seamless from their side. There's really no lifting that the customer needs to do. And that's one of my favorite things about this so far is it doesn't impact what the customer's already doing. It's really just augmenting what they've already got. So we're collecting the data the same way we're pulling everything in. They don't have to change it.

It sounds like when you guys were designing this next generation platform though, you were thinking about that time-to-value, right? That time to the aha moment that we talked about earlier. And so it seems like it is relatively easy for the customer to basically migrate from the old version to the new version.

It is. It is, absolutely. And it's something that took a lot of work on our side to make sure that that happened. And it was definitely a focus to make sure that it was as seamless as possible because as I mentioned, we did do a shift a few years ago and we really built from the ground up, brand-new platform, brand-new settings, move everything over. That was a much bigger shift. This, although it is still a very big shift for us, is much more seamless from the customer perspective because of everything that we're doing internally to make sure that from their side it's as seamless as possible. It's a matter of, "Yep, I want to try this. Let me click the button. And they're off and running."

Now, based on the fact that you guys had done this before, you've been down this road before, right? You've seen this rodeo or whatever the right phrase is here. Did you learn from that previous experience, was there a difficulty? Was there hardship for yourselves and/or customers and then this time you decided, okay, we're going to do this in a more automated way or a more seamless way?

I think so. I mean, again, I'm looking at it really from the customer's perspective and working with them and learning the new platform. I can remember when that first shift happened. I looked at it and I was a little bit scared. I was like, "Wait, I have to learn something all new all over again." Now, I look at it and go, "Wait, that's really cool. I get to do that." And, "Oh, by the way, everything else that I already know is still there." So I can actually expand into it. And I think that's something that we really did put a lot of work and effort into, especially as we're moving forward with the existing customers, is we want to make sure that they're comfortable with it. And those are the conversations. A lot of the conversations I'm having right now is, yeah, we're making this change, but everything you already know and love is still there. That's still the core of the platform. We're just making a shift to make things a little bit better, give you a little bit more flexibility, give you a little bit more functionality, and at the end of the day, it's actually going to make it so that we can help support you better as well. Because we can be more flexible; we can add and augment a little bit more quickly.

Well, one thing I like about what you were just saying here is the concept of evolutionary architecture. We talk about that a lot in different software circles, right? Evolutionary architecture, but it's also the evolutionary experience of the user and the organization that's providing this new solution to the market. So I think even the customers that we're approaching now, right? Those big old enterprises that are handling their banking transactions or travel transactions or working for big government, they have to be thinking about the same thing themselves. How do they roll out incrementally new capabilities in an evolutionary way? At times, it's a little bit disruptive. You might have to make a significant change, but you do want to continue to improve and be on this continuous journey.

Absolutely, and that's really what we always try to strive for our customers, and it's why we do up to this point, push so many new releases, new functionality over time is we understand that we need to keep that core functionality. We understand we need to keep the core value, but in order to still actually deliver that value, we have to be able to move with what's going on in the industry, in the market. There's constantly new technologies out there that cloud providers are constantly releasing new services to make IT and digital environments better. And you said it earlier, every industry now is a digital industry. Everybody is working, and we especially learned this over the last few years where 90% of the workforce started working from home. So we had to be digital, we had to have that flexibility, and that's one of the things that we have to balance is we have to stay with new technology, but we also have to make sure we keep that core value and what that looks like. And you're absolutely right. It's something every group that I talk to now has to deal with. I talk to healthcare companies, I talk to finance companies. They're all having this type of conversation right now.

Well, one thing that I'm seeing a lot in our industry, and I'm curious about your perspective on this is this concept of things happening ever faster. It feels like things are coming at us faster, like the pandemic and work from home and now more digital transactions than ever before. Therefore, from your perspective: more logs, more metrics, more data flowing in, more ingestion, and plus the transition from traditional private data centers to now these cloud hosted scenarios. It presents a whole new space for security and privacy and GDPR and things that are happening in that world. Can you describe how you guys have been thinking about that and how you navigate that new complexity?

Oh, absolutely. And it's always one of those things that we're kind of focused on and looking at. And in fact; here, I think about a year, year and a half ago, we also started looking at things like the security industry that you just mentioned. Again, we already have all this data. We have access to understand how systems talk to each other. So now we actually are branching into application security as well because we have the ability to show that in context of everything else that's happening. So it's definitely something that we're always keeping an eye on and we're always thinking about because there are different ways that this information can be used. Again, that's the whole point of something like the Grail platform is we don't necessarily know all the ways you might want to use your data, so let us open it up and let you guys decide how you want to run with it and be able to do that.

And that's very, very powerful. I can see exactly where you guys are going with that, and I can see how it's powerful for you as a company, but also powerful for your customers that it's going to enable. I had this question around the idea of, well, how many systems would you say your average customer has? How much data would you say you're ingesting from the average customer?

As far as how much data? That's a tricky one because it really does vary. We can go from a few hundred gigabytes to several terabytes at any given point in time, and we are having petabyte conversations with a lot of customers right now, so it really does range.

I can imagine even for the systems that we have here at Red Hat and the customers I've spoken to, I know they have hundreds of systems, hundreds of hosts if not thousands of hosts, and sometimes there are pods running in a Kubernetes backbone, maybe several hundred pods running in a cluster, or maybe it's a few hundred or a few thousand VMs, but if they're pointing all that data, all that logging data, all that metric data that you guys, that's just a massive amount of data heading your way. It's like a tidal wave.

Oh, absolutely, and that's one of the things that we've been really focused on is not only, "Hey, let's try this new functionality, but we've got to be able to scale it." We have to be able to handle this because that data that's coming in is not going to get any smaller anytime soon. That's just going to continue to grow and grow and grow because of just the nature of how IT and technology is moving. More and more, this is going to be something like logs or the data that's being collected, so thinking about how do we scale this, how do we grow this over time? It's definitely been in the forefront of our minds as this has been built out now.

That's fantastic. Well, I want to ask you a couple other things that take us back to maybe the beginning of the conversation related to: what does it mean to be the person who's really interacting with customers, understands the user and customer empathy, and having to take them through these rollouts, through these iterations, if you will, of architectural change, product change, and of course their own changes that are happening in their own worlds. What kind of advice would you actually give to others who are looking at their own customer journeys, and not customers per se, but the vendors who have to basically take customers on this evolutionary path? What are some of the key lessons learned there?

I think one of the biggest things is empathy, right? Understand that as technology changes, as they're making this shift into more modern architectures, into cloud architectures, as we as vendors are changing things, we have to understand that that shifts their world a little bit and understanding that, "Yep, we went through the same thing. We understand how that change happened." And sometimes I walk into a room and I say, "Okay, guys, this is something new. I know it's going to look scary when you first see it, but I promise this is going to be cool, right? This is going to be really good." And that's really what it is. It's just acknowledging the fact that it's not always an easy transition. It's not always an easy shift and acknowledging that, say, "Yep, it's not going to be necessarily the easiest thing in the world, but we're going to help. I understand what you're looking at and this is how we're going to handle it."

It. I think that's powerful from the perspective of when you have the empathy that the customer facing person can also take that back, let's say to the core engineering team and the core product management team, so they can also have a little understanding of that customer need, customer pain. I think that's really important. And really important, both from what you do and of course what your team can now receive from that, the benefit they received from that.

Absolutely, and I do, I go back to the product management team and I said, "Okay, this is the scenario we ran into today. These are their concerns. This is what they're seeing." And from that perspective, it helps our product management team understand, okay, maybe we need to make a shift here or that makes sense. We have this planned, we're going to work on that. They can make adjustments to that based on what the customer actually needs. And I think that's also important for the customer to know that I am doing that. I am going back and talking to my team and bringing them back the feedback. In fact, that happened a few weeks ago when I was working with a brand-new prospect. They were giving me some feedback on some of the new features that were rolling out, and I said, "You know what? You're right. That actually makes a lot of sense. Let me go talk to my team." I went back and I talked to the PMs and we went through a few scenarios and they said, "Oh, yeah, you're right. That actually makes sense." So about three, four weeks later, I went back to that customer and said, "Hey, look, they fixed it. See, they listened." Which was nice.

Well, that is a beautiful example of what we're describing here, because what you said earlier about the fear in the eyes of some people when you're rolling out different changes or making different things happen, so understanding that the human receiving this technology has to feel comfortable with it. We have to understand they're going to go through their own journey, their own learning curve to adopt it, and then if they actually have real feedback like you're describing here in this case with this customer, if you can show that you can take that and react to it relatively quickly, that's just a game changer for everybody, the customer and the vendor in this case.

Yeah, no, absolutely. And it's one of those things that you don't always see, right? You and I both work in technology industries and sometimes you run into a scenarios where it's like, "Nope, they just want to sell me something, right?" But it's about understanding what is this person actually going through, because that's my job is to make their life easier. My job is not to sell them software. My job is to make their life easier. So if I'm not doing that, I'm not doing my job.

Yeah. I love that point there because I wish all software vendors actually felt that way more, where we actually engage the customer, try to meet them where they are, help them on their evolutionary path, make them more successful. One of the phrases I love to use with my own engineering team is I'm looking for a way to give that customer, that user the net new superpower, and if I can't do that, I'm not helping them, and I'm not serving Red Hat either.

No, absolutely.

So is there any final advice you'd give to organizations or other customer facing individuals working in that solution's architecture world or working in that training or consulting world? How should they be thinking about their roles and this new world we're living in? This new cloud native world, this new world of vendors that are rolling out things quickly? How would you actually give some advice in that category?

Yeah, I think some of it is don't be afraid to lean into your own past experience. It may not be in the same industry, it may not be in the same scenario, but you have experience. You have seen some difficulties in your scenario or whatever it happens to be. You have the ability to go back and pull from that, and also make sure that you surround yourself with people who do also have those other experiences and talk to them about their experiences. I pull from my team all the time because I've been with Dynatrace for quite a while, but they've actually been customers of Dynatrace in some cases, so I'm constantly pulling from them, what does this look like in this scenario? What would you do here? And just having the people around you that can actually support you in that. It has been a big thing for me.

I think what you've just described there is a great summary. While it all looks like cool technology, cloud native Kubernetes, all this massive stuff, at the end of the day, it's still a people problem, people process, and people make the difference here.

Absolutely.

You can read more about Red Hat's partnership with Dynatrace at redhat.com/codecommentspodcast. Many thanks to Markie Duby for being our guest, and thanks to all of you for joining us today. This episode was produced by Brent Simoneaux and Caroline Creaghead, and our sound designer is Kristie Chan. Our audio team includes Leigh Day, Stephanie Wonderlick, Mike Esser, Johan Philippine, Kim Huang, Nick Burns, Aaron Williamson, Karen King, Jared Oats, Rachel Ertel, Devin Pope, Matias Faundez, Mike Compton, Ocean Matthews, Alex Traboulsi, and Victoria Lawton. I'm Burr Sutter, and this is Code Comments on original podcast from Red Hat.

About the show

Code Comments

On Code Comments, we speak with experienced professionals on the challenges along the way from whiteboard to deployment.

Challenges In Solutions Engineering

Challenges In Solutions Engineering | Code Comments

About the episode

Abonnieren

Transkript

More about application modernization

About the show

Code Comments

Produkte und Portfolios

Tools

Testen, kaufen und verkaufen

Kommunizieren

Über Red Hat

Wählen Sie eine Sprache

Red Hat legal and privacy links

Red Hat legal and privacy links

Challenges In Solutions Engineering

Challenges In Solutions Engineering | Code Comments

About the episode

Abonnieren

Transkript

More about application modernization

Friday Five — August 15, 2025 | Red Hat

Developing a standard AI OS: Unlocking production-grade AI at enterprise scale

About the show

Code Comments

Produkte und Portfolios

Tools

Testen, kaufen und verkaufen

Kommunizieren

Über Red Hat

Wählen Sie eine Sprache

Red Hat legal and privacy links

Red Hat legal and privacy links