Welcome back to theCUBE's coverage of DockerCon 2021. I'm John Furrier, host of theCUBE. We're here to talk about observability in the enterprise, enabling developers. Vivian Lang, VP of engineering and co-founder of Instana, now part of IBM. Vivian, congratulations on everything and great to have you on theCUBE here for DockerCon. Thank you. Thanks for having me. So I'm in Palo Alto, you're in Germany, we're doing the remote thing. Obviously virtual second year in the row for DockerCon soon, real life is coming back. No real impact to 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 observability. This is an area you guys are playing in aggressively and you got some product observability. What's the big deal about DockerCon, Docker containers, observability, Kubernetes? Why is observability at the center of all these conversations and the center of the value? So observability basically means you understand what's going on. And today it's more important than ever to understand what's going on because there's so much more going on. If you think back five years, maybe before Docker even was featured prominently, you had very little things that you needed to control that you needed to understand. And then microservice and cloud native became more popular and it became really more important to understand what all those moving parts are doing. And that's where observability was born out of what we have been doing before. At that time it was called application performance monitoring, APM. It's now called observability. It's really understanding all those parts of your architecture of the 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. And because today so many things are moving, so many things are maybe even outsourced into cloud providers. It's more important than ever to know what's going on. Well, we're here at DockerCon 2021 virtual. I want to get you to take a minute, if you don't mind explaining to the folks why Docker and DockerCon is important to Instana. So I said we were founded like six years ago and at that time Docker 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 way. Microservices were enabled by Docker before you had to deploy those things somehow. You had CD-ROM 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 were either oriented to infrastructure monitoring. So you understand the quality of your host if it's running slow or to look into application. If an application was throwing errors, but everything was disconnected and unique functionality of Instana 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. David, talk about the problem that you guys solve. Obviously with those availability, I mean the general concept, we kind of get that great overview on your part. But when you start to get into DevOps teams, you start looking at DevSecOps, start looking at cloud native applications. Obviously Docker containers provides all that goodness and Kubernetes orchestration, et cetera. What problem do you guys solve and what's the benefit? The main problem that Instana solves is getting all this understanding that I said is required to provide a good experience to your users, to your end customers without requiring you to do all the instrumentation work or the caption configuration work because Instana is very automatic. It automatically sees all the workloads that are running in your Kubernetes, for example, that are running in Docker containers, but it also connects to legacy databases fully automatic. So no configuration required also means that with the high rate of change that some of those applications 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 observability. So it's really a return of investment on observability solution that we provide and we provide a lot of this insight that you can get and that enables you to provide better service for your users. So you guys aren't just a Docker monitoring service and company, you guys actually run on Docker, right? Is that true? That's correct. So we are not only monitoring Docker and all these things connected to applications, but we are running on Docker or platform as a service. So software as a service we run for you. So you don't need to operate Instana. We are running it on managed Kubernetes clusters in IBM cloud, in Amazon cloud, in Google cloud. We have all that and it's all running on Docker containers. And that gives us so many features that are really great with Docker. So all the configurations that's specific to microservices are being baked into the images and you can just roll it out. Especially for a monitoring product that is dependent on the data, that the performance depends on the data our customers send. These ease of scalability with Docker is just so much bigger than it would be with a traditional deployment type. We can just add worker nodes to our cluster and have ports autoscale to new nodes. And this is functionality that wasn't there before and that's great and that's important essentially for our business. You know, one of the conversations that's being talked about here at DockerCon and in the industry at large is this idea of happy developers. You know, everyone wants to keep developers happy. I've been hearing that conversation. Have many chats with folks. You know, productivity is obviously innovation and productivity and happy developers is the concept. But also, you know, on the business side or on the developer side, it's more accelerated pipeline, right? So how to manage the flow, keep that productivity going but also enabling happy developers. What do you guys do to help there? I mean, if someone asks you, hey, how do you make my developers happier and accelerate my pipeline? Well, that's really depending 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 skipping out a lot of the manual configuration work that's boring and not really appealing to developers helps everything is prepackaged and configured automatically. So that's a big plus. And the installer monitoring, as I said, is also automatic. So you don't need to configure 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. Yeah, automations create, that's great. I mean, that's a benefit. Can you talk about the on-prem version of Instana? That's something that you guys are talking about and featuring. What is that about? Can you take a minute to explain the on-prem version of Instana for Docker containers? Yeah, it's an interesting topic, especially at the conference like DockerCon where it's all about virtualization, containerization and going into the cloud that there are still companies, enterprises, governmental 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 deploying. So we knew when we founded Instana 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's a little bit complicated to on-premises customers to have them self host the solution, we saw that Docker solves a lot of problems for us. We don't need to manually patch 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 deployments 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 what was the motivation behind that? Was this customer demand more efficiency? What was the motivation behind moving to supporting the on-prem version? For a startup, it's all about addressable market share, right? So you want to have everything you can get and you don't want to spend any extra money on it. And as I said, the enterprise market is big. There was 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 Instana because we were able to target and help those customers even in a fully air-gapped scenario, for example, where they don't even have internet access. Take me through the process of dockerizing the product, say the on-prem product, you got that and you got the thing going on there, you're 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 docker as a technology from the beginning. So there wasn't really like a shift and lift 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-sales 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 in Kubernetes. You'll make a customer resource, for example, and then have an operator run the product, any kind of product, but also Instana, you run on-premises with an operator that just works on the single configuration file 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 Docker 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 service on-premises very easily, very quickly and that makes them happier. We talked about developer happiness, it makes them happy because now they are not lagging behind but it also enables us to give better quality support, roll out fixes faster and helps us to no longer support very old versions because they don't exist, they are frequently updated. I think this is really a benefit of containerization is also how easy it is to upgrade because you just stop a port and start a port in the new version and then you have a new version. That's also great insight, baby, great to chat with you on that.  I was been chatting with other VPs of engineers and we were talking about the shift in engineering and with DevOps, you got kind of SR reaction, you have some, you know, just straight-up application coding, just modernized that cloud-nated application and you got kind of under the DevOps. As the world 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, it might be crap. So this notion of iterating code and crafting good product, because with now this modularization with containers, you're doing a lot more design work. So Kraft seems to be coming back to coding. Not only is it coming back, it's been there but it just seems more of like, hey, let's do this right. Let's not just ship code. What's your take on that? So I think this always was there. It's just that traditionally companies approach software engineering similar to how companies approach manufacturing. So somebody writing a design spec and somebody verifying it and then it's going on to the line to mass production but software doesn't work that way. We make way more changes. It's way harder to understand it upfront. So the DevOps, the iterative and agile development that has been ongoing is really what people want. And DevOps, well, there is this notion of being waking up in the middle of the night and that's what developers don't want. So you need to prepare your application. We need to make it resilient against that. And the 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's a high rate of risk, as you said. And I think the ability to deploy a thousand 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 we always riff on the other two pizza team or having more agility. And you have this democratization because 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, it's 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 argument, so wait, that's my job. Who's the, this kind of changes. What's your thoughts? How do you manage that dynamic? Because as you have more, I won't say surface here, more democratized engineering with virtual teams and whatnot, you have composability with code, you have more of a systems, 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 follows the organization that the company has that creates. So I think what you want, when you want to have a microservice architecture, you want to have a microservice teams. You want to have teams. We call them at Instano delivery teams that work more or less independently on a certain set of features and are responsible for them end 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 in 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 form those cross-functional teams dynamically and when it's no longer needed, hit the spans. And I think that's a major difference to assigning a person through a role. Yeah. And then also that with you have new trends like observability, enterprise observability, new things are happening and new net new things like new architectures and also new roles and responsibilities. I'll see new patterns too with the data. You have services being stood up and turned down all the time. You have a lot of dynamic environments. So having a happy developer is one, eliminate the manual work which you do, but also giving them good work assignments to work on some good, hard problems. So 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, dev 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 then 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 or it should also be cheap. Big data and AI is usually very expensive because it requires so much hardware. So not only try to make it fast but maybe even make it efficient. This whole domain is very appealing. There's new technology to be invented, tough problems. And I think that's really exciting to develop. Fabian Lang, vice president of engineering and co-founder of Instana. Great to have you on theCUBE. Great insight. Thank you for sharing that knowledge there and the overview of Instana here at DockerCon. You know, observability, very relevant for next gen, next level solutions. Thanks for coming on theCUBE. You're welcome. Okay, I'm John Furrier with theCUBE here at DockerCon 2021 coverage. Thanks for watching.