KubeCon + CloudNativeCon Europe 2024 | Alois Reitbauer | Dynatrace

Clips
News
More from KubeCon + CloudNativeCon Europe 2024

Alois Reitbauer

Chief Technology Strategist

Dynatrace

Unlocking observability: Dynatrace expands open-source efforts with latest CNCF projects

Navigating observability’s intricacies, especially in the cloud-native landscape, can feel like wading through murky waters. Companies such as Dynatrace LLC, however, are doing their share to enhance enterprise observability within open-source deployments.“This week, we actually launched our own distribution for the OpenTelemetry collector where we bundle everything up, make it secure, make it enterprise-ready, take care of end-to-end testing and even provide it open source back to everybody who’s out there who wants to use it,” said Alois Reitbauer (pictured), chief technology strategist at Dynatrace

play_circle_outline Dynatrace: Empowering the Open Source Community through Standards and Collaborative Contributions

play_circle_outline Dynatrace's own open source projects: CNCF Captain and OpenFeature

play_circle_outline Advancing Observability and Automated Processes: AI's Impact, Feature Flagging, Security, and OpenTelemetry Growth

Info

Alois Reitbauer | Dynatrace

Alois Reitbauer

Chief Technology Strategist Dynatrace

search

(upbeat music)

>> Hello and welcome back to KubeCon + CloudNativeCon EU Paris. Glad to have you on board here and we got some exciting stuff. We're continuing down the observability path and really unpacking this and trying to get a better understanding because I think there's still a lot of confusion about how you get started, how you get into things. There's a lot of projects out there. And today we're joined by Alois Reitbauer.

>> Yes, hello.

>> Chief Technology Strategist from Dynatrace.

>> Hello. Thanks for having me.

>> Thank you, and again, joined by Dustin Kirkland who's going to help me unpack this. I think this is one, I mean, one of my passions is observability. And I think that when I come here and understand all of the stuff that's going on and really is being unpacked, it's incredible the amount of work that's going in on the observability side. And I think there's still a lot to be done, but I think there's progress being made. Now Dynatrace, when I think Dynatrace, I don't immediately think open source. Help the people sitting at home who are like, why is Dynatrace on and what do they have to do with cloud native? You know, open source. What is really Dynatrace contributing back in here?

>> Yeah, it's actually good that you brought this up because a lot of people don't associate us as a commercial software vendor with open source. While we are like very active in the open source community, it have been for a very long time. Open source on a one, but also contributing to standards for even a longer time. And we contributed to WWs, several Ws with C standards along the way. And within the CNCF, we were part of OpenTelemetry from day one. We even were part of the group that was working on the observability topics before like the project merged, and the OpenTelemetry eventually merged. We have people in the governance board, we have people in the technical committee. With this week, actually launched our own distribution for the OpenTelemetry collector where we bundle everything up, make it secure, make it enterprise ready, take care of end-to-end testing and even providing it open source back to everybody who's out there who wants to use it. We also funded two of our own open source projects within the CNCF captain, which has been around for quite some time. It's observability for GitHubs basically when you roll out applications, getting tracing, getting your metrics and DORA metrics when you deploy something. So either works for GitHub scenarios or kubectl scenarios, understand really why your deployment is not working or going wrong or what's going on in there. And also being able to hook into these processes obviously works out of the box with Argo and other GitHub tools. And the OpenFeature project, which has been very successful. So OpenFeature, the goal is to have a unified SDK for feature flagging that you put into your application because up to now it was either proprietary solutions that the companies built or it was a vendor specific solution that was out there. We kind of figured out all of these SDKs are doing the same things, all of them are actually open source, so why don't create the standard around it. We got a lot of people in the industry joining in working on this project and also have a feature management solution. And this week announced the availability of our web SDKs.

>> Yeah, the feature flag feature is quite interesting. That's not an easy thing for many projects to simply add. Can you tell us just a little bit, you know, unpack one more layer of how you're able to do that, you know, in a general case and then provide that observability? From I'm guessing what you're able to do is see what's happening going down one path or the other path, right?

>> Yeah, so what do you think about deployment and release? These are two processes. We kind of separate it. Deployment is where I think of a blue/green deployment. So you're checking it for a new release, whether the code actually works. But you do not necessarily turn on the feature. And then you start to gradually, progressively turn on the feature and you might just, I'm turning it out for you but not for you. So it sounds very simple. When people think about feature flag, they think about an on and off switch.

>> Right. >> But it's actually more. You can pick and choose which functionality you're seeing and on top of the flag you have what is called a targeting rule. The targeting rule basically specifies who's seeing the feature. People say from Paris will seeing it, but not from other countries. And usually applications do not have just one feature, but they have multiple, even thousands. I think at Dynatrace we roughly run about 2000 features in parallel.

>> Wow.

>> So what does this mean for observability and for application execution? In the past you thought, okay, if you understand how like the transaction is working, like buying a product or doing something online, you kind of understood how it's working. It was pretty much the same for all of us, but most likely in an advanced environment, each one of us has different features turned on and off or different features with running different, what you call variance, like behaviors. So suddenly every transaction starts to be different and just from seeing which version of software is processing your transaction or your (indistinct), does no longer help us. So you get more or less this massive vector of, okay, for this transaction, this was on, this was off, this was set to this value, this was set to that other value. So the analytics challenge and the observability becomes key. That's also why observability and OpenTelemetry is natively built into OpenFeature. So you get all that observability data and then you can figure out, okay, why is this feature working for you but not for you? Maybe because you have another feature enabled. So the analytics complexity is actually massive that you have to deal with.

>> Oh, so that's really interesting. So it's not only that you're helping with the feature flagging actual project, it's how do you look at that from an observability standpoint so that you can actually understand why different things are happening underneath the hood?

>> Exactly, because there's just so many possibilities, like how features can be to an on and off. It's very hard to analyze it from, especially for us, at least, it might just even feel like random somehow how the application's behaving. So that's why the analytics component is key. And that's also where OpenFeature really helps because once you have a standard SDK that you're using, you can't just switch out the backend provider. You could use open source project, the commercial provider, but all the observability is really there. And it's also, you're also getting the same data across your environments. 'Cause like for testing, you might choose another feature flagging provider than you're running in production.

>> Yeah, let's bring this to AI, okay? Right. What sort of, can you tell us just a little bit about your capabilities and how, you know, your roadmap forward, how you're thinking about observability around, AI integrations for code?

>> I think for observability, any idea, it's actually two directions that you can think. It is like one is how can observability, how can AI help us to get better observability? We at Dynatrace with have been using AI, not generative AI, but AI in general for like roughly 10 years.

So this is more- >> Like on your backend?

>> On your backend, like, these are prediction models, these are faulty analysis models, these are like traditional machine learning models and kind of like combining them together and now adding gen AI as a layer on top. I think gen AI can help with a couple of, in a couple of areas. One is user input. People ask more and more questions, they just want to explore the data more and more, which means that the queries that you have to write are getting more and more complex and powerful and you want to make this easier and make it easier for people to access it. That's one area. Another area is especially around remediation, when you have like root cause analysis, you know how things need to change or how you need to modify, for example, Kubernetes manifest, have GenAI simply rewrite it. And also configuration overall is a key area. I think you want to build a dashboard. Building a dashboard is a lot of work. So now by combining different sorts of AI, you can ask AI, just build me a dashboard for all my conversion critical services. And the AI can then go in there. So this is not like that one ChatGPT type of query. These are really AI programs or AI agents that check back what does your environment look like, what is critical in there, what needs to be modified? And then these AI programs are really built at runtime. So that's more how AI can help observability, but observability can also help AI. If you think about like all these new solutions in the market, this is another layer you add to your application where you also need observability on a number of fronts.

>> And can you tie that back to the feature flag work? 'Cause that feature flag capability, is that also tied back to some of the AI insights that you're able to derive?

>> I think especially on the analytics side, you want to understand what features to roll out. Even like creating optimal configurations for you by learning on how it actually work, like which configurations work. Or even handing over to an AI agent. Like now thinking a bit further ahead, like thinking also about generative AI, more about its planning capabilities versus the pure generation capabilities. Asking an AI agent to safely roll out a new application feature by always like asking other observability data, then deciding on the strategy, what to modify and getting analytics feedback in and automating more and more of those processes. Because I think that's what we can really achieve with AI. There is a certain amount of DevOps and SRE work that is not just simple automation, but there is this cognitive step in between where you have to do some analysis to decide which direction to go and what to do exactly. And there the combination of AI can actually help to make this simpler and also start automating these tasks.

>> Yeah, I mean I think, again, to your point and exactly the questions that Dustin is asking is, you've had Davis AI for quite some time and now exposed it and you're doing AI for, using AI for tracking of LLMs and helping with that observability. Also, you made an acquisition of Runecast recently and you're bringing in security into that. Talk about how the feature flag and security kind of play together. Because that would, to me, would make a lot of sense where the feature flag might also be, Hey, we need to make sure that this is never turned on in these situations and things like that. And where observability could kind of tie that all together.

>> Yeah, I mean obviously you can look into whether like a feature flag is like enabling a security fault or not, but also think about feature flags, not just about turning on our features, but also providing more or less an API how to reconfigure your replication at runtime. These are the so-called operational flags, like how you at runtime want to change the behavior of your replication. So it's giving application developers also to entirely new API how to change behavior. Like I could say as a remediation action, like for like this IP address, which is the targeting rule, enable this feature which reroute traffic for example, not to the production but to even like a handy PO type of database where they can work on. So even this type of application configurations you can build in. And by those feature flags you're really extending the capabilities in your application to do this. And creating like why those feature flags is additional API. The very nice thing about it is as well, it doesn't require any complex deployment that will take time. Feature flags can be switched immediately. So you can have much faster response times, in the case of security incidents. If you gimme a list of IPs, I could try turn off the entire application functionality immediately at the application layer. Or even if you already have an intruder in the system, you can block out all traffic and all API calls coming from that service host, whatever, in real time.

>> Yeah, I think that's one of the things that hasn't gotten a lot of airtime this week so far is security. Hopefully we have OpenSSF tomorrow and some others. But let me kind of roll back to OpenTelemetry as well because I'm interested in, you guys, obviously there must be an uptick in OpenTelemetry use that you went and built that package and secured it. And again, a testation, attestation of that source so that people can go and use it. How do you see the uptick of OpenTelemetry?

>> We see more people use it, especially for custom instrumentation that they put into their code. More cloud native environments, just exposed more data in various formats and OpenTelemetry is definitely one of them. I think in the past it was pretty much a boutique thing for people to do. You build telemetry in there. Now people are way more open to add this telemetry code to their application. Obviously it's done by OpenTelemetry these days. We also see enterprise starting to adopt it, but obviously we get more enterprise requirements, which was driving a lot of our work for the Dynatrace version of the OTel Collector, say, okay, you wanted enterprise ready, you want it fully secure and we want to support people in both directions. So if you want to use our own agent technology, you're fine. If you want to go all in on OpenTelemetry, you're good to go either. So that's why we will see more and more support from the observability providers and also creating their own distribution. Because we heard this from our customers and there's actually a large number of customers who are using the OTel Collector. But they wanted us to take care of it. And just to give you an idea and the popularity of this, in the first couple of days since the release, we had over 3000 downloads already of our OpenTelemetry collector distribution.

>> Wow. Wow.

>> Incredible. >> I think the fact that it's open, I mean again, that others can use it, I think that's amazing then. And it's great contributions back into the community that you're making. It seems like Dynatrace is making a lot of contributions back for not getting a lot of airtime on it, but you are today.

>> Oh, we are working more behind the scenes on it, but I think we can't review to open source where it makes sense for us. We are not the traditional, we take an open source project and commercialize it. But we think, okay, this is where the industry as a whole needs to evolve, where we need to have a standard, where we need to collaborate. That's usually where we also put our open source efforts where we think it makes more sense for a larger group of people to collaborate on something versus having a pure open core business model around it. And that the contributions on OpenTelemetry have always been there. And for us it was actually natural to make it available openly. But the only difference really is if you are a Dynatrace customer, you can write, you can file a support case and get like the support contract response times that we agreed on. But beyond that, it's exactly the same code. So everybody can now run our version of OTel Collector that is secured has all of this components in there. And we also take the complexity out of the upstream development for some of our customers because sometimes they want to see components on the OpenTelemetry Collector, like receivers that are not yet GA. So we'll then also take on the further development of those components to reach GA status and maintain them.

>> Yeah, so I think that's fantastic and I think, again, it's always eye opening to me to see people who are contributing back in, like you said, where it make sense, where you have actual capabilities to contribute something back into the community where it totally helps everybody, including your customers. I think that's fantastic. And I want to thank you for coming on board today. And thanks and hopefully you had a good time here.

>> Definitely. Thank you. >> Yeah. And thank you Dustin. Thanks for joining us again for this one, and you know, this is going to be a great day. We got a little bit more coming up, so stay tuned here at KubeCon + CloudNativeCon EU Paris. Thanks, and stay tuned. (upbeat music)

Alois Reitbauer | Dynatrace

search

(upbeat music)

>> Hello and welcome back to KubeCon + CloudNativeCon EU Paris. Glad to have you on board here and we got some exciting stuff. We're continuing down the observability path and really unpacking this and trying to get a better understanding because I think there's still a lot of confusion about how you get started, how you get into things. There's a lot of projects out there. And today we're joined by Alois Reitbauer.

>> Yes, hello.

>> Chief Technology Strategist from Dynatrace.

>> Hello. Thanks for having me.

>> Thank you, and again, joined by Dustin Kirkland who's going to help me unpack this. I think this is one, I mean, one of my passions is observability. And I think that when I come here and understand all of the stuff that's going on and really is being unpacked, it's incredible the amount of work that's going in on the observability side. And I think there's still a lot to be done, but I think there's progress being made. Now Dynatrace, when I think Dynatrace, I don't immediately think open source. Help the people sitting at home who are like, why is Dynatrace on and what do they have to do with cloud native? You know, open source. What is really Dynatrace contributing back in here?

>> Yeah, it's actually good that you brought this up because a lot of people don't associate us as a commercial software vendor with open source. While we are like very active in the open source community, it have been for a very long time. Open source on a one, but also contributing to standards for even a longer time. And we contributed to WWs, several Ws with C standards along the way. And within the CNCF, we were part of OpenTelemetry from day one. We even were part of the group that was working on the observability topics before like the project merged, and the OpenTelemetry eventually merged. We have people in the governance board, we have people in the technical committee. With this week, actually launched our own distribution for the OpenTelemetry collector where we bundle everything up, make it secure, make it enterprise ready, take care of end-to-end testing and even providing it open source back to everybody who's out there who wants to use it. We also funded two of our own open source projects within the CNCF captain, which has been around for quite some time. It's observability for GitHubs basically when you roll out applications, getting tracing, getting your metrics and DORA metrics when you deploy something. So either works for GitHub scenarios or kubectl scenarios, understand really why your deployment is not working or going wrong or what's going on in there. And also being able to hook into these processes obviously works out of the box with Argo and other GitHub tools. And the OpenFeature project, which has been very successful. So OpenFeature, the goal is to have a unified SDK for feature flagging that you put into your application because up to now it was either proprietary solutions that the companies built or it was a vendor specific solution that was out there. We kind of figured out all of these SDKs are doing the same things, all of them are actually open source, so why don't create the standard around it. We got a lot of people in the industry joining in working on this project and also have a feature management solution. And this week announced the availability of our web SDKs.

>> Yeah, the feature flag feature is quite interesting. That's not an easy thing for many projects to simply add. Can you tell us just a little bit, you know, unpack one more layer of how you're able to do that, you know, in a general case and then provide that observability? From I'm guessing what you're able to do is see what's happening going down one path or the other path, right?

>> Yeah, so what do you think about deployment and release? These are two processes. We kind of separate it. Deployment is where I think of a blue/green deployment. So you're checking it for a new release, whether the code actually works. But you do not necessarily turn on the feature. And then you start to gradually, progressively turn on the feature and you might just, I'm turning it out for you but not for you. So it sounds very simple. When people think about feature flag, they think about an on and off switch.

>> Right. >> But it's actually more. You can pick and choose which functionality you're seeing and on top of the flag you have what is called a targeting rule. The targeting rule basically specifies who's seeing the feature. People say from Paris will seeing it, but not from other countries. And usually applications do not have just one feature, but they have multiple, even thousands. I think at Dynatrace we roughly run about 2000 features in parallel.

>> Wow.

>> So what does this mean for observability and for application execution? In the past you thought, okay, if you understand how like the transaction is working, like buying a product or doing something online, you kind of understood how it's working. It was pretty much the same for all of us, but most likely in an advanced environment, each one of us has different features turned on and off or different features with running different, what you call variance, like behaviors. So suddenly every transaction starts to be different and just from seeing which version of software is processing your transaction or your (indistinct), does no longer help us. So you get more or less this massive vector of, okay, for this transaction, this was on, this was off, this was set to this value, this was set to that other value. So the analytics challenge and the observability becomes key. That's also why observability and OpenTelemetry is natively built into OpenFeature. So you get all that observability data and then you can figure out, okay, why is this feature working for you but not for you? Maybe because you have another feature enabled. So the analytics complexity is actually massive that you have to deal with.

>> Oh, so that's really interesting. So it's not only that you're helping with the feature flagging actual project, it's how do you look at that from an observability standpoint so that you can actually understand why different things are happening underneath the hood?

>> Exactly, because there's just so many possibilities, like how features can be to an on and off. It's very hard to analyze it from, especially for us, at least, it might just even feel like random somehow how the application's behaving. So that's why the analytics component is key. And that's also where OpenFeature really helps because once you have a standard SDK that you're using, you can't just switch out the backend provider. You could use open source project, the commercial provider, but all the observability is really there. And it's also, you're also getting the same data across your environments. 'Cause like for testing, you might choose another feature flagging provider than you're running in production.

>> Yeah, let's bring this to AI, okay? Right. What sort of, can you tell us just a little bit about your capabilities and how, you know, your roadmap forward, how you're thinking about observability around, AI integrations for code?

>> I think for observability, any idea, it's actually two directions that you can think. It is like one is how can observability, how can AI help us to get better observability? We at Dynatrace with have been using AI, not generative AI, but AI in general for like roughly 10 years.

So this is more- >> Like on your backend?

>> On your backend, like, these are prediction models, these are faulty analysis models, these are like traditional machine learning models and kind of like combining them together and now adding gen AI as a layer on top. I think gen AI can help with a couple of, in a couple of areas. One is user input. People ask more and more questions, they just want to explore the data more and more, which means that the queries that you have to write are getting more and more complex and powerful and you want to make this easier and make it easier for people to access it. That's one area. Another area is especially around remediation, when you have like root cause analysis, you know how things need to change or how you need to modify, for example, Kubernetes manifest, have GenAI simply rewrite it. And also configuration overall is a key area. I think you want to build a dashboard. Building a dashboard is a lot of work. So now by combining different sorts of AI, you can ask AI, just build me a dashboard for all my conversion critical services. And the AI can then go in there. So this is not like that one ChatGPT type of query. These are really AI programs or AI agents that check back what does your environment look like, what is critical in there, what needs to be modified? And then these AI programs are really built at runtime. So that's more how AI can help observability, but observability can also help AI. If you think about like all these new solutions in the market, this is another layer you add to your application where you also need observability on a number of fronts.

>> And can you tie that back to the feature flag work? 'Cause that feature flag capability, is that also tied back to some of the AI insights that you're able to derive?

>> I think especially on the analytics side, you want to understand what features to roll out. Even like creating optimal configurations for you by learning on how it actually work, like which configurations work. Or even handing over to an AI agent. Like now thinking a bit further ahead, like thinking also about generative AI, more about its planning capabilities versus the pure generation capabilities. Asking an AI agent to safely roll out a new application feature by always like asking other observability data, then deciding on the strategy, what to modify and getting analytics feedback in and automating more and more of those processes. Because I think that's what we can really achieve with AI. There is a certain amount of DevOps and SRE work that is not just simple automation, but there is this cognitive step in between where you have to do some analysis to decide which direction to go and what to do exactly. And there the combination of AI can actually help to make this simpler and also start automating these tasks.

>> Yeah, I mean I think, again, to your point and exactly the questions that Dustin is asking is, you've had Davis AI for quite some time and now exposed it and you're doing AI for, using AI for tracking of LLMs and helping with that observability. Also, you made an acquisition of Runecast recently and you're bringing in security into that. Talk about how the feature flag and security kind of play together. Because that would, to me, would make a lot of sense where the feature flag might also be, Hey, we need to make sure that this is never turned on in these situations and things like that. And where observability could kind of tie that all together.

>> Yeah, I mean obviously you can look into whether like a feature flag is like enabling a security fault or not, but also think about feature flags, not just about turning on our features, but also providing more or less an API how to reconfigure your replication at runtime. These are the so-called operational flags, like how you at runtime want to change the behavior of your replication. So it's giving application developers also to entirely new API how to change behavior. Like I could say as a remediation action, like for like this IP address, which is the targeting rule, enable this feature which reroute traffic for example, not to the production but to even like a handy PO type of database where they can work on. So even this type of application configurations you can build in. And by those feature flags you're really extending the capabilities in your application to do this. And creating like why those feature flags is additional API. The very nice thing about it is as well, it doesn't require any complex deployment that will take time. Feature flags can be switched immediately. So you can have much faster response times, in the case of security incidents. If you gimme a list of IPs, I could try turn off the entire application functionality immediately at the application layer. Or even if you already have an intruder in the system, you can block out all traffic and all API calls coming from that service host, whatever, in real time.

>> Yeah, I think that's one of the things that hasn't gotten a lot of airtime this week so far is security. Hopefully we have OpenSSF tomorrow and some others. But let me kind of roll back to OpenTelemetry as well because I'm interested in, you guys, obviously there must be an uptick in OpenTelemetry use that you went and built that package and secured it. And again, a testation, attestation of that source so that people can go and use it. How do you see the uptick of OpenTelemetry?

>> We see more people use it, especially for custom instrumentation that they put into their code. More cloud native environments, just exposed more data in various formats and OpenTelemetry is definitely one of them. I think in the past it was pretty much a boutique thing for people to do. You build telemetry in there. Now people are way more open to add this telemetry code to their application. Obviously it's done by OpenTelemetry these days. We also see enterprise starting to adopt it, but obviously we get more enterprise requirements, which was driving a lot of our work for the Dynatrace version of the OTel Collector, say, okay, you wanted enterprise ready, you want it fully secure and we want to support people in both directions. So if you want to use our own agent technology, you're fine. If you want to go all in on OpenTelemetry, you're good to go either. So that's why we will see more and more support from the observability providers and also creating their own distribution. Because we heard this from our customers and there's actually a large number of customers who are using the OTel Collector. But they wanted us to take care of it. And just to give you an idea and the popularity of this, in the first couple of days since the release, we had over 3000 downloads already of our OpenTelemetry collector distribution.

>> Wow. Wow.

>> Incredible. >> I think the fact that it's open, I mean again, that others can use it, I think that's amazing then. And it's great contributions back into the community that you're making. It seems like Dynatrace is making a lot of contributions back for not getting a lot of airtime on it, but you are today.

>> Oh, we are working more behind the scenes on it, but I think we can't review to open source where it makes sense for us. We are not the traditional, we take an open source project and commercialize it. But we think, okay, this is where the industry as a whole needs to evolve, where we need to have a standard, where we need to collaborate. That's usually where we also put our open source efforts where we think it makes more sense for a larger group of people to collaborate on something versus having a pure open core business model around it. And that the contributions on OpenTelemetry have always been there. And for us it was actually natural to make it available openly. But the only difference really is if you are a Dynatrace customer, you can write, you can file a support case and get like the support contract response times that we agreed on. But beyond that, it's exactly the same code. So everybody can now run our version of OTel Collector that is secured has all of this components in there. And we also take the complexity out of the upstream development for some of our customers because sometimes they want to see components on the OpenTelemetry Collector, like receivers that are not yet GA. So we'll then also take on the further development of those components to reach GA status and maintain them.

>> Yeah, so I think that's fantastic and I think, again, it's always eye opening to me to see people who are contributing back in, like you said, where it make sense, where you have actual capabilities to contribute something back into the community where it totally helps everybody, including your customers. I think that's fantastic. And I want to thank you for coming on board today. And thanks and hopefully you had a good time here.

>> Definitely. Thank you. >> Yeah. And thank you Dustin. Thanks for joining us again for this one, and you know, this is going to be a great day. We got a little bit more coming up, so stay tuned here at KubeCon + CloudNativeCon EU Paris. Thanks, and stay tuned. (upbeat music)