>>Welcome welcome back to the cubes coverage of dr khan 2021. I'm john for a host of the cube. We're here to talk about observe ability in the enterprise, enabling developers. Fabian lang VP of engineering and co founder of Istana, now part of IBM. Fabian, Congratulations on everything and great to have you on the cube here for dr gone. >>Thank you. Thanks for having me. >>So I'm in Palo Alto, you're in Germany were doing the remote thing obviously virtual second year in a row for dr khan. Soon real life is coming back. Uh no real impact of developers as they continue to be more productive than ever. The hottest conversation topic being discussed, being funded by venture capitalists and private equity is observe ability. This is an area you guys are playing in aggressively and you got some product observe ability. What's the big deal about Docker con Docker containers observe ability kubernetes, Why is observe ability at the center of all these conversations and the center of the value. >>So observe ability basically means you understand what's going on and today it's more important than ever to understand what's going on because there is so much more going on. If you think back five years maybe before Dr even was featured prominently, you had very little things that you needed to control that you need to understand and then micro service and coordinative became more popular and became really more important to understand what all those moving parts are doing. And that's where observe ability was born out of what we have been doing before at that time it was called application performance monitoring A PM. It's now called observe ability. It's really understanding all those parts of your architecture, of your stack of the application and in the end of the end user experience, you want to know if a user is experiencing a slow service and what's the reason for that? Because today, so many things are moving so many things that maybe even outsourced into cloud providers, it's more important than ever to know what's going on. >>Well we're here at Dunkirk on 2021 virtual. I want to get you to take a minute if you don't mind explaining to the folks why Dr and Dr Khan is important to Astana. >>So I, I said we were founded like six years ago and at that time Doctor was the rising star. It was promoting a lot of new technology. It was giving developers new abilities to develop applications in a very agile away. Microservices were enabled by Doctor before you had to deploy those things somehow it was a city Rome and then you needed to install >>debian >>package but with microservices you have so many more things to install. So it was really, I would say instrumental to the success of microservices to have a platform like docker that was really the next gen of technology that helped to enable those applications. And for us it was really an important driver to understand the whole stack, the traditional tools where eyes are oriented to infrastructure monitoring. So you understand the quality of your host if it's running slow or to look into application of an application was throwing errors but everything was disconnected and unique functionality of Astana is to connect all those bits and pieces of the application together and for that containers. And now kubernetes is a really important part to understand because it is part of this whole picture. >>Did you talk about the problem that you guys solve? Um obviously with those availability, I mean the general concept, we kind of get that great, great overview on your part, but when you start to get into devoPS teams, you start looking at def sec off, start looking at cloud native applications. I see Docker containers provides all that goodness and kubernetes, orchestration, etcetera. What problem do you guys solve? And um what's the benefit? >>The main problem that in stana solves is getting all this understanding that I said is required to provide a good experience of to your users, to your end customers uh without requiring you to do all the instrumentation work or the capture and configuration work because in stana is very automatic, it automatically sees all the works lords that are running in your communities, for example, that are running in Dr containers, but it also connects to legacy databases, fully automatic. So no configuration required also means that with a high rate of change that some of those applications hard have is that we will see all those change happening in real time. And you can't forget to make a configuration to enable your observe ability. So it's really return of investment on the viability solution that we provide and we provide a lot of this insight uh that you can get and that enables you to provide better service for your users. >>So you guys aren't just a doctor monitoring service and company, you guys actually run on Docker. Right, is that true? >>That's correct. So we are not only monitoring doctor and all these things connected to applications, but we are running on a doctor or platform as a service. SaAS software as a service. We run for you so you don't need to operate and stana, we are running it on managed kubernetes clusters and uh, IBM cloud and amazon cloud in google cloud. We have all that and it's it's all running on docker containers and that gives us so many features that are really great with DACA. So all the configuration that specific to microservices are being baked into the images and you can just roll it out, especially for monitoring products that is dependent on the data, that the performance depends on the data our customers send. Um, these ease of scalability with doctor is just so much bigger than it would be with a traditional deployment type. We can just add worker notes to our cluster and have ports auto scale to new notes and this is functionality that wasn't there before and that's great and that's important, essential for our business. >>You know, one of the conversations that's being talked about here at dr khan and in the industry at large is this idea of happy developers and everyone wants to keep developers happy. I've been hearing that conversation, have many chats with folks, you know, productivity and innovation, um but productivity and happy developers of the concept, but also, you know, on the, on the business side or on the developer side, it's more accelerated pipeline. Right? So, so how do you manage to flow, keep that productivity going, But also enabling happy developers, what do you guys do to help there? I mean what if someone asks you, hey, how do you make my developers happier and accelerate my pipeline? >>Well, that's really dependent on what makes the developers happy. I think most developers really want to get their functionality. They are working on their passionate about into production into the hands of end users. So um, skipping out a lot of the manual configuration work that's boring and not really appealing to develop us, helps everything is pre packaged and configured automatically. So that's a big, big plus. And the standard monitoring as I said, uh, is also automatic. So you don't need to configure it, your, your application on how to monitor it. So developers can just focus on delivering features and whenever there is something we will tell them, I think they enjoy that >>innovations creates great, that's a benefit. Can you talk about the on prem version of installing a, that's something that you guys are talking about and featuring um what is that about? Can you take a minute to explain beyond prem version of in Astana for dr containers? >>Yeah, it's a, it's an interesting topic, especially at the conference like dr khan, where it's all about virtualization, container realization and going into the cloud, that there are still companies, enterprises government mental entity that are very heavily invested on an on premise solution. They want to have control or are legally required to have control over what they have been deployed. So we knew when we founded in Astana that our solution, unlike our competitors, can't be only software as a service. We want to have a fantastic software as a service product and experience, but it should be equally good on premises as well. And when we were looking at ways how to actually do it, how to deliver an architecture that a little bit complicated to on premises customers to have themselves as the solution. We saw that doctor solves a lot of problems for us. We don't need to manually petra around operating system that customers, we don't have different versions of packages installed. It's all the same and actually it's not only all the same for all the deployment of all our customers, but it's also the same technology that we run as a software. As a service customers can run it now on their own. So we have feature parity, it's not lagging behind and this is also ease of support for us. >>So why was it, what was the motivation behind that was just customer demand? Um, more efficiency? What was the motivation behind moving on, supporting the on prem version? >>Uh, so for a start up, it's all about addressing the market share. Right? So you wanna have everything you can get, you don't want to spend any extra money on it. And as I said, the enterprise market is big. There are still many players that want to have the data in house. This is potentially sensitive data that's being tracked. So an on premise solution having, it was really instrumental to the success of in Stana because we were able to target and help those customers even in a fully adapt scenario, for example where they don't even have internet access. >>Take me through the process of DACA rising the product sitting on prime product that you get the thing going on there, like okay, let's do this. What does that look like? How did that work out? >>So as I said, we looked at this from the beginning and we picked DACA as a technology from the beginning, so there wasn't really like a shift and left type of scenario that other customers might be having. We were doing it from the beginning and we were aligning our architecture so that there are no fundamental differences between an on premise solution and anti size solution. That's of course configuration, that's different. But that configuration we just put into a single configuration file and that turned out to be a great idea because this is how you nowadays configure your application kubernetes, you'll make a customer resource for example, and then have an operator run the product, any kind of product, but also in stana, you run on premises with an operator that just works on the single configuration that you give it. And this is actually great because our customers are used to operating products like that, their own software, everything customers are running in dhaka in kubernetes, they are used to operating it that way. And that helped us because our customers now get the same functionality that we offer as a, as a service on premises very easily very quickly. And that make them happier. We talked about developer happiness that makes them happy because now they are not lagging behind but it also enables us to give better quality support, lot fixes faster and helps us to no longer support very old presence because they don't exist. They are frequently updated. I think this is really a benefit of container realization is also how easy it is to upgrade because you just stop apart and start a part in the new version and then you have a new verse. >>That's also great insights may be great to chat with you on that. I got to ask you on a personal note, you've been in the industry for a while and your leader, um you know, that's a performance geek, you'll have to build fast code. I was been chatting with other VPs of engineering and we were talking about the shift in engineering and with devops you've got kind of s our reaction, you have some just straight up application coding, just modernize that cloud native applications and you've got a kind of under the devoPS as the world's shifts. It seems like there's more of an architectural systems engineering approach or a systems mindset and that seems to be changing the mindset of a developer from Iterate fast. And then the line I heard was you can iterate and pump out code fast, but it might not be good, might be crap. So, so this notion of iterating code and crafting good product because with now this module Ization with containers, you're doing a lot more design work. So craft seems to be coming back to coding. Uh, I don't think it's coming back, it's been there, but it just seems more of like, hey, let's do this, right? And it's not just ship code. What's your take on that? >>So I think this always was there. It's just that traditionally companies approached software engineering similar to how companies approach manufacturing. So somebody writing a designs back and somebody verifying it and then it's going onto the line to mass production. But software doesn't work that way. We make way more changes, it's way harder to understand it up front. So the developed the iterative and exile development that has been ongoing is really, is really what people want and develops well. There is this notion of being a being waking up in the middle of the night and that's what developers don't want. So you need to prepare your application, you need to make it resilient against that. And developers are very eager to build in functionality that helps them to troubleshoot to make their application available. With a high rate of change. There is a high rate of risk as you said and I think the ability to deploy 1000 times per day is great but you don't necessarily need to do that. I think it's also important for your users that you find the right pace of when you deliver functionality and when you deliver fixes. >>I was just talking to a friend the other day and we were just talking about organizations and teams and yeah, we always riff on the the two pizza team or having more agility and you have this democratization because of the agility is also a benefit for any developer to add value if they have the right perspective or creativity. But it kind of disrupts the kind of the old way of thinking. I'm the principal engineer is my job. No, I'm the chief architect. So you have these titles and you have roles, the roles are changing and sometimes just the arguments. Oh wait, that's my job is that I'm this kind of changes. What's your thoughts on, how do you manage that dynamic? Because as you have more, uh, I won't say surface here more democratized engineering with virtual teams and whatnot You have compose ability with, with with code. You have more of a systems are a lot more going on. It's not your standard engineering mindset. What's your thinking on this as a leader in engineering and visionary? >>Well as we know the architecture of a software full of the organization that the company has. That creates. All right. So I think what you want when you want to have a micro service architecture, you want to have a micro service teams. You want to have teams, we call him at and standard delivery teams that work more or less independently on a certain set of features and are responsible for them and to end. So my engineers, they are talking to our customers figuring out how to make a feature better. They are then designing this with our user designers and then they are developing and deploying it and this really entry and responsibility. And we don't really have those titles like architect anymore. I think those roles are still there but it's more like a shared responsibility. So you of course want an architecture, you want to have your components talk to each other in an efficient way and it's more really communities of practice that are establishing. So you will find out that you have people and your teams who have specific skills who like to work on architecture. Some of them like to work on continuous delivery systems And then you you form those cross functional teams dynamically and when it's no longer hit this bands. And I think that's a major difference to assigning a person to a road. >>Yeah and and also that with you have new trends like observe ability, enterprise observe ability you know new things are happening um And new net new things like new architecture and also new roles and responsibilities. I'll see new patterns to with the data you have services being stood up and turned down all the time. You have a lot of dynamic environment. So you know having a happy developers one eliminate the manual work what you do but also giving them good work assignments to work on some good hard problems. So what is what are those hard problems that engineers like to work on these days? Is it like design? Is it coding? I mean I know it depends as you mentioned on the personalities but generally speaking as dev ops def sec Ops becomes much more of an agile edge hybrid play. What's the hard problem? >>I think big data is not really a new term but I think this is still a very interesting territory because you can apply various aspects to it. You have this data science aspect to it to understand how to detect pattern in it. And then automation is actually artificial intelligence. Right? So you automate data science and that's very interesting because those are large scale problems and new problems and new solutions. So yes there are existing frameworks but there's so much innovation to be found and making this work efficiently is another dimension of the same problem. That's also not easy and challenging problems. Make developers happy and then you can even have people think about the financial aspects. So it should also be cheap Big data and AI is usually very expensive because it requires so much hardware. So not only tried to make it fast but maybe even make it efficient. So this whole domain is very appealing. There is new technology to be invented, tough problems and I think that's really exciting to developed. >>Fabian Lang, vice president of engineering co founder and stand a great to have you on the q Great insight. Thank you for sharing that knowledge there. And the overview of installing here at dr khan observe ability very relevant for next gen next level solutions. Thanks for coming on the cube. Right, okay. I'm john Fury with the queue here. Dr khan 2021 coverage. Thanks for watching. Mm.

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