 From around the globe, it's theCUBE with digital coverage of IBM Think 2021, brought to you by IBM. Everybody, welcome back to theCUBE's continuous coverage of IBM Think 2021, the virtual edition, my name is Dave Vellante and we're going to talk about observability, front and center for DevOps and developers. Things are really changing. We're going from monitoring and logs and metrics and just this mess and now we're bringing in AI and machine intelligence. And with us is Pablo Baron, who's the CTO of Instana, which is an IBM company that IBM acquired in November of 2020. Pablo, great to see you. Thanks for joining us from Munich. Thanks for having me. Thanks a lot. You're very welcome. So, you know, I always love to talk to founders and co-founders and try to understand sort of why they started their companies and congratulations on the exit. That's awesome after five, I'm sure grinding, but relatively short years. Why did you guys start in Instana and what were some of the trends that you saw and that you're seeing now in the observability space? Yeah, that's a very good question. So, the journey began as we worked in the company called CodeCentric, the majority of the founders and we actually specialized in troubleshooting, well, real hard customer performance problems. We used all different kinds of APM solutions for that. You know, we've built expertise of like collectively maybe 300 years of the whole company. So, we would go from one adventure into the other and see customers suffer and tell them, you know, overcome this trouble. At some point we started seeing architectures coming up that were not well covered by the classic APM solutions. Like people went after this pseudo, pseudo, pseudo virtualization all in containers, you know, just dropping random workloads into container running this maybe in Kubernetes, well, not actually not five, six years ago, but you get the point. We started with the heavy containerization and we've seen that a classic APM solution that is heavily, you know, like machine oriented and then some of them even counted by the number of CPU et cetera, et cetera, et cetera. Very well suited for this. Plus, all of the workloads are so dynamic they keep coming and going. You cannot really, you know, place your agent there that is not adopting to change continuously. We've seen this coming and we really, we've seen the trouble that we cannot really support the customers properly. So after looking around, we just said, hey, I think it's time to just implement a new one, right? So we started that adventure with the idea of a constant change with the idea of everything is containers with the idea of everything goes towards cloud native. People just run random workloads and all different versions that are linked all together that this whole microservices trend came up where people would just break down their monoliths and resilience of literally very small components that could be deployed independently. Everything keeps changing all the time. The classic solution cannot keep up with that. So let me pick it up from there, if I can. So it's interesting, your timing is quite amazing because as you mentioned, it really wasn't cute. Kubernetes, when you started in the middle part of last decade, you know, containers have been around for a long time but Kubernetes weren't, it wasn't mainstream back then. So you had some foresight and the market has just come right into your vision. But maybe talk a little bit about the way APM used to work. It was, I started to talk about this. It was metrics, it was traces, it was logs. It was make your eyes bleed type of stuff. And maybe you could talk about how you guys are different and how you're accommodating the rapid changes in the market today. Right, so well, there is very, very many cases in this. So first of all, we always have seen that the work that you should not be doing by hand, I mean, we already said that you should not be doing this and you should be automating as much as possible. We see this everywhere in the IT industry that everything gets more and more automated. We want to automate through the whole continuous delivery cycle. Unfortunately, monitoring was the space that probably never was automated before Instana came into place. So our idea was, hey, just get rid of the unnecessary work because you keep people busy with stuff they should not be doing like manually watching dashboards, setting up agents with every single software change like adopting configuration, et cetera, et cetera, et cetera. All of these things can be done automatically to a very, very, very large extent. And that's what we did. We did this from the beginning. Everything we approach, we think twice about can we automate the maximum out of it? And only if we see that it's too much an effort, et cetera, we will probably not do this, but otherwise we don't do this and you can compromise. Got it. The other aspect is, so this is different to the classic APM world that is typically very expert heavy. The expert comes into the project and really starts configuring, et cetera, et cetera, et cetera. This is a totally different approach. The other approach is continuous change and adapting to the continuous change. Container comes up, you need to know what this kind of workload, what kind of workload this thing is, how it is connected to all the others. And then at some point, probably it's gonna go through the change and get a new version, et cetera, et cetera. You need to capture this whole lifecycle without really changing your monitoring system. Plus, if you move your workloads from the classic monolith through microservices onto Kubernetes, you're kind of transitioning, it's a journey. And in this journey, you wanna keep your business abstractions as stable as possible. The term application is nothing that you should be reconfiguring. Once you figure out what is payment in your system, this is a stable abstraction. It doesn't matter if you deliver it on containers, it doesn't matter if this is just a huge JVM that owns the whole box alone, it simply doesn't matter. So we decoupled everything infrastructure from everything logic. And the foundation for this is what we call the dynamic graph. Technically it's pretty much a data structure, a regular graph data structure with connections in multiple directions from different nodes. But the point is that we actually decompose the whole IT geography. This is the term I like to use because there is no other. It's infrastructure, it's topology, it is on the other hand just, same size of the same thing. When you have a Linux process, it can be a JVM, it's just at the same time, it can't be appropriate application. It's the same thing, but you give it different names and this different facets of this thing can be linked with everything else in a totally different way. So we decomposing this from the beginning in the product, which allows us to have a very deep and hierarchical understanding of problem when it appears. So we can mail it not down to a metric that probably doesn't make sense to any user, but really name the cause by, look, in this JVM, drop wizard metric, XYZ is misbehaving, this indicates that this particular piece of technology is broken. And here's how it's broken. So there's a built-in explanation to a problem. So the classic APM, as I said, it is a very expert heavy territory. We try to automate the expert. We have this guy called Stan, this is your kind of virtual DevOps engineer. It has AI in there, it has some artificial brain. It never sleeps, it observes all of the problems. It really is an amazing guy because nobody likes them because he always tells you what's broken. You don't need to invite them to the party and give them a raise, they're just there and observing the systems. I like Stan, I like Stan better than Fred, no offense to Fred, but Fred's the guy in the lab coat that I have to call every time to help me fix my problems. And what you're describing is end-to-end visibility or observability in terms that either normal people can understand or certainly Stan can understand and can automate. And that kind of leads me to this notion of anti-patterns. And in software, we think of anti-patterns as, you know, you have software hairballs and software bloat, you've got stovepipe systems, you're a data guy by background and so you well understand stovepipe data systems. There's organizational examples of anti-patterns like micromanagement or over-analysis by paralysis, if you will. How do anti-patterns fit into this world of observability, what do you see? Oh, there's many. I could write a whole book actually about that. Let me just list a few. So first of all, it is valid for any kind of automation. What you can automate, you should not be doing by hand. This is a very common anti-pattern. People are just doing work by hand just because they're lazy or like repetitive work or there is no kind of foundation to automate whatever the reason, this is clearly an anti-pattern. What we also see in the monitoring space are very interesting things like normally, since the problems in the observability monitoring space are so hard, you normally sent your best people watching ads who want them to contribute to the business value rather than waste the time observing charts that like 99% of them are normal. The other aspect of course is what we also have seen is the other side of the spectrum where people just send total novices into the problem of observability and let them learn on the subject, which is also not a good thing because you cannot really, I mean, there's so many unknown unknowns for people who are not experts in the space, they will not catch the problem. You will go through pain, right? So it's not the learning project, it's not the research project. This is very essential to the operation of your business and your IT. And there's many examples like that. Right. Yeah, so I want to end by just sort of connecting the dots. So this makes a lot of sense. And if you think about, you know, Arvind Krishna said that IBM's got to win the architectural battle for hybrid cloud. And when I think of hybrid cloud, I think of on-prem connecting to public cloud, not only the IBM public cloud, but other public clouds going across clouds, going to the edge, bringing OpenShift and Kubernetes to the edge and developing new, supporting new workloads. So as IT is like the universe that it keeps expanding and it gets more and more and more complicated. So to your point, humans are not going to be able to solve the classic performance problems in the classic way. They're going to need automation. So it really does fit well into IBM's hybrid cloud strategy. Your thoughts, and I'll give you the last word. Yeah, totally. I mean, IBM generally is, of course, very far ahead in regards to research, AI and all these things. This, sorry, those could be combined with Instana very, very natively, right? We are prepared to automate using AI, all of the, well, I would want to claim that all of the monitoring observability problems. Of course, there is manual work in some cases, you simply don't know what people want to observe. So you kind of need to give them names and that's what people come in. But this is more a creative work. Like you don't want to do the stupid work with people. It doesn't, there is no, it doesn't make any sense. And IBM, of course, acquiring Instana gets the foundation for all of the things that used to be done by hand, now fully automated, combined with Instana, combined with Watson AI Ops. This is huge. This is like a real great story. Like the best research of the world, meeting probably the best APMs. That's great, Pavlo, really appreciate you taking us through Instana and the trends and observability and what's going on at IBM. And congratulations on your success. And thanks for hanging with us with all the craziness going on at your abode. And really it was a pleasure having you on. Thank you. Thanks a lot. All right, and thank you for watching everybody. This is Dave Vellante in the ongoing coverage of IBM Think 2021. You're watching theCUBE.