>>From around the globe. It's the cube with digital coverage of IBM. Think 20, 21 brought to you by IBM, everybody welcome back to the cubes. Continuous coverage of IBM think 20, 21, the virtual edition. My name is Dave Volante, 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 as Pablo Baron, who's the CTO of Instana, which is an IBM company that IBM acquired 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, you know, five, five, I'm sure. Grinding, but relatively short years. Uh, why did you guys start in Stoneleigh 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, um, the journey began, uh, as we worked in the company called code centric, the majority of the founders, and, uh, we actually specialized in troubleshooting, um, well, real hard customer performance problems. We used all different kinds of APM solutions for that. You know, we we've built expertise, uh, like, uh, collectively, maybe 300 years of the whole company. So we will go from one, um, adventure into the other and see customers suffer and to help them, you know, overcome this trouble. At some point we started seeing architectures, uh, coming up that were not well covered by the classic APM solutions. Like people went off to the suit, a suit, a suit of the virtualization, all in containers, you know, just dropping random, uh, workloads into container running this maybe in Cubanitos. Well, not, not actually not five, six ago but years ago, but you get the point we started with having continued containerization. >>And we've seen that a classic APM solution that is having the, you know, like machine oriented. And then, uh, some of them even counted by the number of CPU, et cetera, et cetera. The world 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 adapting 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, uh, it's time to just implement the new one, right? This is, we started that adventure with the idea of a constant change to the AGL. If everything is containers with idea of everything goes towards cloud native people just, uh, run random, uh, um, workloads of all different versions that are linked all together that this whole microservices trend came up where people would just break down their model and resilience of, uh, literally very small components that could be deployed independently. Everything keeps changing all the time. The classic solution cannot keep up with it, >>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, like containers have been around for a long time, but Coobernetti's, weren't that wasn't mainstream back then. So you had some foresight, uh, and, and the market has just come right into your vision, but, but maybe talk a little bit about the way APM used to work. It was, I started this talk about this. It was metrics, it was traces, it was logs. It was make your eyes bleed type of type of stuff. Um, and maybe you could talk about how, 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 pieces to 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 shouldn't be automating as much as possible. We see this everywhere in the it industry that everything gets more and more automated and want to automate it through the whole continuous delivery cycle. Unfortunately, monitoring was the space that probably never was automated before installer came into place. So our idea was, Hey, just, just get rid of the unnecessary work because you keep people busy with stuff that they should not be doing, like manually watching dashboards, setting up agents, uh, with every single software change, like adopting configuration, et cetera, et cetera, et cetera, all of these things can be done automatically, you know, to very, very, very large extent. >>And that's what we did. We, we did this from the beginning, everything we approach, uh, we, we, we think twice about, uh, can we automate, you know, the maximum out of it. And only if we see that it's, it's, you know, too much in effort, et cetera, we will, we will problem in onto this, but otherwise we're not, we don't do this. And yet, you know, you can compromise the other, right? The other aspect is, so this is different to the classic APM world that is typically very expert heavy. The expert comes into, you know, into the project and really starts configuring, et cetera, et cetera, et cetera. This is, this is a totally different approach. The other approach is continuous change and, uh, you know, 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, it's gonna, you know, go through the change and get a new version, et cetera, et cetera. You need to capture this whole life cycle without really changing your monitoring system. Plus if you move your workloads from the classic monolith through microservices onto cause the need is you kind of trans transitioning, you know, it's a journey in this journey. You want to keep your business abstractions as stable as possible. The term application is nothing that you should be reconfiguring. Once you figured out what is payments in your system? This is a stable obstruction. It doesn't matter if you deliver it on containers. It doesn't matter if this is just a huge, you know, JVM that owns the whole box alone. It simply doesn't matter. So we, we decoupled everything infrastructure from everything logic and, uh, the foundation for this is what we call the dynamic graph. >>It's technically, it's pretty much a data structure. The regular route, the dispatcher would do no connections, uh, in, in, 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, there is no other it's infrastructure. It's typology. It is on the other hand, just, you know, same sides of the same thing. When you have a Linux process, it can be a JVM. It just, at the same time, it can be a problem with application. It's the same thing. I can give a different names and this different, you know, facets of this thing can be linked with everything else in a different way. So we're decomposing this from the beginning of the product, which allows us to, to have a very deep and hierarchical understanding of the problem when it appears so we can nail 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, the drop wizard metric XYZ that 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, um, the cloud, the classic APM, as I said, it is a very expert, heavy, um, uh, territory. We try to automate the expert. We have this guy called Stan. This is your, you know, kind of, uh, virtual dev ops engineer has AI in there. It has some, 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 body and give them a raise. They're just there and conserving the system. >>I liked Stan. I liked Stan better than Fred. No offense to Fred, but Fred's is the guy in the lab coat that I have to call every time to help me fix my, and what you're describing is end to end visibility or observability, uh, in, in terms that the normal either normal people can understand, or certainly Stan can understand and can automate. And that kind of leads me to this notion of, of anti-patterns. Um, getting in software, we think of anti-patterns is, you know, you have software hairballs and software bloat. You've got stovepipe systems. You're, you're a data guy by background. And so you will understand, you know, stovepipe data systems, there's organizational examples of, of, of anti-patterns like micromanagement or over-analyze analysis by paralysis. If you will, how do anti-patterns fit into this world of observability? What do you see? >>Oh, there is many, I could write a whole book actually about that. Um, let, 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 pattern. People are just doing work by hand, just because the lazy where you know, like repetitive work or there is no kind of foundation to automate the, whatever, the reason, this is clearly an impact pattern. What we, what we also see in the monitoring space are very interesting things like normally since the problems in the observability and monitoring space are so hard, you would normally send your best people, watching rats want them to contribute to the business value rather than waste the time of serving charts. That's like 99% of them are marble. The other aspect of course, is what we also have seen is the other side of the spectrum where people just send total mobilizes into the, into the problem of ops observability and let them learn on the subject, which is also not a good thing, because you can not really, I mean, there are so many unknown unknowns for people who are not experts in this space. >>They will not catch the problem. You will go through pain, right? So it's not a learning project. It's not the research from a project. This is very essential to the operation of your business and to 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, Auburn Christian said that IBM has 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 workload. So as it is like the university 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. Uh, they're going to need automation. So it really does fit well into IBM's hybrid cloud strategy, your, your thoughts, and I'll give you the last word. >>Yeah, totally. I mean IBM generally is of course, very far ahead in, in regards to AI and all these things, this desk, sorry, those could be combined within standard, very, very, you know, natively, right. We, 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, uh, you know, 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, you know, there is no, it doesn't make any sense. And IBM of course, um, requiring and Stan, I guess, you know, the foundation for all of the things that that used to be done by, by hand now fully automated, combined within starlet, combined with Watson AI ops. This is, this is huge. This is a real great story. Like the best research at the world meeting, uh, probably the best APM summit. >>That's great. Uh, Pablo really appreciate you taking us through and Stata 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, uh, really, it was a pleasure having you on. Thank you. Thanks a lot. Thank you for watching everybody. This is Dave Volante and the ongoing coverage of IBM. Think 2021. You're watching the cube.