>>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.

>>from >>around the >>globe, it's the cube >>with digital coverage of >>IBM think 2021 >>brought to >>you by IBM >>everybody welcome back to the cubes, continuous coverage of IBM think 2021 the virtual edition, my name is Dave Volonte and we're gonna talk about observe ability 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 a I and machine intelligence and with us is Pablo Baron, who is the Ceo of inst ana, 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 55 I'm sure grinding but relatively short years. Why did you guys start in stana? And what were some of the trends that you saw in that you're seeing now in the observe ability space? >>Yeah, that's a very good question. So, um, the journey began ah, as we worked in the company called code centric, the majority of the founders and uh, we actually specialized in troubleshooting uh, well, real hard customer performance problems. We used all different kinds of A PM solutions for that. You know, we, we've built expertise like collectively maybe 300 years in the whole company. So we would go from one um, adventure into the other and see customers suffer and help them, you know, overcome this trouble. At some point we started seeing architectures coming up that were not well covered by the classic KPM sellers, like people went after this. Sudha, Sudha, Sudha virtualization all in containers, you know, just dropping random workloads into container running this maybe in cabinet as well. Not not actually not 56 ago, but years ago. But you get the point, we started with the heavy continues container ization and we've seen that a classic A PM solution that is heavily, you know, like machinery rented and and some of them you've encountered by the number of CPU etcetera etcetera. They were 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, uh, 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 idea of everything goes towards glove needed. People just run random uh workloads of all different versions that are linked altogether than 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 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 uh and and the market has just come right into your vision but but maybe talk a little bit about the way A. P. M. 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 type of stuff. Um, and maybe you can 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 um cases 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 industry that everything gets more and more automated. We want to animate through the whole continuous delivery cycle. Unfortunately monitoring was the space that probably never was automated before installing a came into place. So our idea was, hey, just 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 etcetera, etcetera, etcetera. All of these things can be done automatically, you know, to very, very, very large extent. And that's what we did. We did this from the beginning, everything we approached, we, we, we think twice about can we automate, you know, the maximum out of it And only if we see that it's, it's, you know, too much an effort, etcetera. We will, we will probably not do this, but otherwise we're not, we don't do the same thing. You know, you can compromise the other right? The other aspect is, so this is different to the classic A PM world that is typically very expert heavy. The expert comes into, you know, into the project and really starts configuring etcetera, etcetera etcetera. This is this is a totally different approach the other approaches continuous change and you know, adapting to the continuous change, container comes up, you need to know what this kind of workload, what kind of work load this thing is, how it is connected to all the others. And then at some point probably it's gonna it's gonna go through the change and get a new versions etcetera etcetera. 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 on to cuba needs, you kind of transitioning, you know, it's a journey and 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 figure out what is payment in your system. This is a stable abstraction. It doesn't matter if you deliver it on containers. Doesn't matter if this is just a huge JBM 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 ground. It technically is pretty much a data structure. Regular graph data structure with, you know, connections in multiple directions from different notes. But the point is that we actually decompose the whole, I teach geography. This is the term I like to use because there is, there is no other its infrastructure, its topology, it is on the other hand, just, you know, same sides of the same thing. When you have a limits process, it can be HIV m it's just at the same time, it can be approached with an application, it's the same thing and given different names and this different faces of this thing can be linked with everything else in a totally 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 problems 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 J. V. M, the drop wizard metric exercise 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 the classic eight pm as I said, it is a very expert heavy um, territory we try to automate the expert. We have this guy called stan this is your you know, kind of virtual devoPS engineer has a I 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 him because he always tells you what's broken. You don't need to invite them to the party and give them a raise just there and conserving your systems. >>I like stand, I like stand better than fred, no offense to fred but friends of 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 observe ability in terms that norm either normal people can understand or certainly stand, can understand and can automate. And that kind of leads me to this notion of anti patterns um getting software, we think of anti patterns as you know you have software hairballs and software bloat, you've got stovepipe systems, your your data guy by background and so you will understand stovepiped data systems, there's organizational examples of of of anti patterns like micromanagement or over an analysis by paralysis. If you will, how do anti patterns fit into this world? Of observe ability? What do you see? >>Oh there's many, I could write a whole book actually about that. Um 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 entire pattern. People are just doing work by hand just because the lazy word, you know like repetitive work or there is no kind of foundation to automate that whatever the reason, this is clearly an anti pattern. What we, what we also see in the monitoring space are very interesting things like normally since the problems in the observe ability monitoring space is so hard, You normally send your best people watching grants 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 mobilizes into the, into the problem of observe ability and let them learn on the subject. Which is also not a good thing because you cannot really I mean there are 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, that's not the research from a project. This is very essential to the operation of humor, business and humanity. 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, Ivan Kushner 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 open shift and kubernetes to the edge and developing new supporting new workloads. So as I. T. 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 gonna need automation. So it really does fit well into iBMS hybrid cloud strategy, your, your thoughts and I'll give you the last word. >>Yeah, totally. I mean, I'm IBM generally is of course very far ahead in regards to research AI and all these things this death, sorry, those could be combined with an stand a 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 observe ability problems. Of course, there is manual work in some, 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 where people come in. But this is more 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 in stana gets, you know, the foundation for all of the things that used to be done by hand. Now, fully automated, combined within standard, combined with Watson, the ions, This is, this is huge. This is like a real great story, like the best research of the world eating. Uh, probably the best a PMC. >>That's great Pablo, really appreciate you taking us through Astana and the trends and observe ability and what's going on at IBM. And congratulations on your, 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. >>All right, and thank you for watching everybody says Dave Volonte and our ongoing coverage of IBM, think 2021 you're watching the Cube? Yeah. Mhm