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