>>Hey, welcome back everyone to cube Cod's coverage and cloud native con the I'm John for your husband, David Nicholson cube analyst, cloud analyst. Co-host you got two great guests, KIPP alumni, Jerry Chen needs no introduction partner at Greylock ventures have been on the case many times, almost like an analyst chair. It's great to see you. I got guest analyst and Martin mal who's the CEO co-founder of Chronosphere just closed a whopping $200 million series C round businesses. Booming. Great to see you. Thanks for coming on. Thank you. Hey, first of all, congratulations on the business translations, who would have known that observability and distributed tracing would be a big deal. Jerry, you predicted that in 2013, >>I think we predicted jointly cloud was going to be a big deal with 2013, right? And I think the rise of cloud creates all these markets behind it, right. This, you know, I always say you got to ride a wave bigger than you. And, uh, and so this ride on cloud and scale is the macro wave and, you know, Marty and Robin cryosphere, they're just drafted behind that wave, bigger scale, high cardinality, more data, more apps. I mean, that's, that's where the fuck. >>Yeah. Martin, all kidding aside. You know, we joke about this because we've had conversations where the philosophy of you pick the trend is your friend that you know, is going to be happening. So you can kind of see the big waves coming, but you got to stay true to it. And one of the things that we talk about is what's the next Amazon impact gonna look like? And we were watching the rise of Amazon. You go, if this continues a new way to do things is going to be upon us. Okay, you've got dev ops now, cloud native, but observability became really a key part of that. It's like almost the, I call it the network management in the cloud. It's like in a new way, you guys have been very successful. There's a lot of solutions out there. What's different. >>Yeah. I'd say for Kearney sphere, there's really three big differences. The first thing is that we're a platform. So we're still an observability platform. And by that, I mean, we solved the problem end to end. If thinking about observability and monitoring, you want to know when something's wrong, you want to be able to see how bad it is. And then you want to able to figure out what the root cause is. Often. There are solutions that do a part of that, that that problem might solve a part of the problem really well for a platform that does the whole thing. And 10 that's that's really the first thing. Second thing is we're really built for not just the cloud, but cloud native environments. So a microservices architecture on container-based infrastructure. And that is something that, uh, we, we have saw coming maybe 20 17, 20 18, but luckily for us, we were already solving this problem at Uber. That's where myself, my co-founder were back in 20 14, 20 15. So we already had the sort of perfect technology to solve this problem ahead of where the, the trend was going in the industry and therefore a purpose-built solution for this type of environment, a lot more effective than a lot of the existing. >>It's interesting, Jerry, you know, the view investing companies that have their problem, that they have to solve themselves as the new thing, versus someone says, Hey, there's a market. Let's build a solution for something. I don't really know. Well, that's kind of what's going on here. Right? It's >>That's why we love founders. Like Martin Marna, rod that come out with these hyperscale comes Uber's like we say, they've seen the future. You know, like there were Uber, they looked at the existing solutions out there trying to scale Promethease or you know, data dogs and the vendors. And it didn't work. It fell over, was too expensive. And so Martin Rob saw solid future. Like, this is where the world's going. We're going to solve it. They built MP3. It became cryosphere. And um, so I don't take any credit for that. You know, I just look fine folks that can see the future. >>Yeah. But they were solving their problem. No one else had anything. There's no general purpose software that managed servers you could buy, you guys were cutting your teeth into solving the pain. You had Uber. When did you guys figure out like, oh, well this is pretty big. >>Uh, probably about 20 17, 20 18 with a rise in popularity of Kubernetes. That's when we knew, oh wait, the whole world is shifting to this. It's not, no one could really it to just goober and the big tech giants of the world. And that's when we really knew, okay. The whole, the whole whole world is shifting here. And again, it's, it's sheer blind luck that we already had the ideal solution for this particular environment. It wasn't planned it. Wasn't what we were planning for back then. But, um, yeah. Get everything. >>It makes a lot of difference. When you walk into a customer and say, we had this problem, I can empathize with you. Not just say we've got solved. Exactly. Jerry, how do they compete in the cloud? We always talk about how Amazon and Azure want to eat up anything that they see that might, you know, something on AWS. Um, this castle in the cloud opportunity here. Okay. >>In the cloud. I mean, you know, we talked last time about how to fight the big three, uh, Amazon Azure and, uh, and Google. And I think for sure they have basic offerings, right. You know, Google Stackdriver years ago, they've done basically for Pete's offerings, basic modern offerings. I think you have like basic, simple needs. It's a great way to get started, but customers don't want kind of a piecemeal solution all the time. They want a full product. Like Datadog shows a better user experience, but full product is going to, you know, the better mousetrap the world will beat a path to your door. So first you can build a better product versus these point solutions. Number two is at some scale and some level complexity, those guys can handle like the demanding users that current affairs handling right now, right? The door dash, the world. >>And finally don't want the Fox guarding the hen house. You know, you don't want to say like Amazon monitoring, you can't depend on Amazon service monitoring your Amazon apps or Google service monitor your Google apps, having something that is independent and multi-cloud, that can dual things, Marta said, you know, see a triage, fixed your issues is kind of what you want. And, um, that's where the market's skilling. So I do believe that cloud guys will have an offering the space, but in our castle and cloud research, we saw that, yeah, there's a plenty of startups being funded. There's plenty of opportunity. And that the scoreboard between Splunk Datadog and all these other companies, that there's a huge amount of market and value to be created in this piece. So, >>So with, at, at the time, when you, you know, uh, uh, necessity is the mother of invention, you're an Uber, you have a practical problem to solve and use you look around you and you see that you're not the only entity out there that has this problem. Where are we in that wave? So not everyone is at, cloud-scale not everyone has adopted completely Kubernetes and cloud native for everything. Are we just at the beginning of this wave? How far from the >>Beach are we, we think we're just at the beginning of this wave right now. Um, and if you think about most enterprises today, they're still using on, and they're not even in perhaps in the cloud at all right. Are you still using perhaps APM and solutions, uh, on premise? So, um, if you look at that wave, we're just at the beginning of it. But when, but when we talked to a lot of these companies and you ask them for their three year vision, Kubernetes is a huge piece of that because everyone wants to be multi-cloud everyone to be hybrid eventually. And that's going to be the enabler of that. So, uh, we're just in the beginning now, but it seems like an inevitable wave that is coming. >>So obviously people evaluated that exactly the way you're evaluating that. Right. Thus the funding, right. Because no one makes that kind of investment without thinking that there is a multiplier on that over time. So that's pretty, that's a pretty exciting place. >>Yeah. I think to your point, a lot of companies are running into that situation right now, and they're looking at existing solutions there for us. It was necessity because there wasn't anything out there now that there is a lot of companies are not using their sort of precious engineering resources to build their own there. They would prefer to buy a solution because this is something that we can offer to all the companies. And it's not necessarily a business differentiating technology for the businesses themselves >>Distributed tracing in that really platform. That's the news. Um, and you mentioned you've got this, a good bid. You do some good business. Is scale the big differentiator for you guys? Or is it the functionality? Because it sounds like with clients like door dash, and it looks a lot like Uber, they're doing a lot of stuff too, and I'm sure everyone needs the card. Other people doing the same kind of thing, that scale, massive amount of consumer data coming in on the edge. Yeah. Is that the differentiation or do you work for the old one, you know, main street enterprise, right. >>Um, that is a good part of the differentiation and for our product thus far before we had a distributor tracing for monitoring and metric data, that was the main differentiation is the sheer volume of data that gets produced so much higher, really excited about distributor tracing because that's actually not just a scale problem. It's, it's a space that everybody can see the potential distributor tracing yet. No one has really realized that potential. So our offering right now is fairly unique. It does things that no other vendors out there can do. And we're really excited about that because we think that that fundamentally solves the problem differently, not just at a larger scale, >>Because you're an expert, what is distributed tracing. >>Yeah. Uh, it's, it's, it's a great question. So really, if you look at this retracing, it captures the details of a particular request. So a particular customer interaction with your business and it captures how that request flows through your complex architecture, right? So you have every detail of that at every step of the way. And you can imagine this data is extremely rich and extremely useful to figure out what the underlying root causes of issues are. The problem with that is it's very bit boast. It's a lot of data gets produced. A ton of data gets produced, every interaction, every request. So one of the main issues are in this space is that people can't afford cost effectively to store all of this data. Right? So one of the main differentiators for our product is we made it cost efficient enough to store everything. And when you have all the data, you have far better analytics and you have >>Machine learning is better. Everything's better with data. That's right. Yeah. Great. What's the blind spot out. Different customers, as cybersecurity is always looking for corners and threats that some people say it's not what you want. It's what you don't see that kills you. That's, that's a tracing issue. That's a data problem. How do you see that evolving in your customer base clients, trying to get a handle of the visibility into the data? >>Yeah. Um, I think right now, again, it's, it's very early in this space of people are just getting started here and you're completely correct where, you know, you need that visibility. And again, this is why it's such a differentiator to have all the data. If you can imagine with only 10% of the data or 1% of data, how can you actually detect any of these particular issues? Right. So, uh, uh, data is key to solving that >>Feel great to have you guys on expert and congratulations on the funding, Jerry. Good to see you take a minute to give a plug for the company. What do you guys do? And actually close around the funding, told you a million dollars. Congratulations. What are you looking for for hiring? What are your milestones? What's on your plan plan. >>Yeah. Uh, so with the spanning, it's really to, to, uh, continue to grow the company, right? So we're sort of hiring, as I told you earlier, we are, uh, we grew our revenue this year by, by 10 X in the sense of the 10 months of this year, thus far. So our team hasn't really grown 10 X. So, so we, we need to keep up with that grid. So hiring across the board on engineering side, on the go to market side, and I just continue to >>Beat that. The headquarters, your virtual, if you don't mind, we've gone >>Completely distributed. Now we're mostly in the U S have a bunch of folks in Seattle and in New York, however, we going completely remote. So hiring anyone in the U S anywhere in Europe, uh, >>Oh, I got you here. What's your investment thesis. Now you got castles in the cloud, by the way, if you haven't seen the research from Greylock, Jerry and the team called castles in the cloud, you can Google it. What's your thesis now? What are you investing in? >>Yeah, it is. It is hard to always predict the next wave. I mean, my job is to find the right founders, but I'd say the three core areas are still the same one is this cloud disruption to Martin's point we're. So early days, the wave, I say, number two, uh, there's vertical apps, different SAS applications be finance, healthcare construction, all are changing. I think healthcare, especially the past couple of years through COVID, we've seen that's a market that needs to be digitized. And finally, FinTech, we talked about this before everything becomes a payments company, right? And that's why Stripe is such a huge juggernaut. You know, I don't think the world's all Stripe, but be it insurance payments, um, you know, stuff in crypto, whatever. I think fintechs still has a lot of, a lot of market to grow. >>It's making things easier. It's a good formula right now. If you can reduce complexity, it makes things easy in every market. You're going to seems to be the formula. >>And like the next great thing is making today's crappy thing better. Right? So the next, the next brace shows making this cube crappy thing. Yeah, >>We're getting better every day on our 11th season or year, I'm calling things seasons now, episodes and season for streaming, >>All the seasons drop a Netflix binge, watch them all the >>Cube plus and NFTs for our early videos. There'll be worth something because they're not that good, Jerry. How, of course you're great. Thank you. Thanks guys. Thanks for coming on it. Cubes coverage here in a physical event, 2021 cloud being the con CubeCon I'm John farrier and Dave Nicholson. Thanks for watching.

>>Hello, and welcome. Very excited to see everybody here. DockerCon is going fantastic. Everybody's uh, engaging in the chat. It's awesome to see. My name is Peter McKee. I'm the head of developer relations here at Docker and Taber. Today. We're going to be talking about container first development now and in the future. But before we do that, a couple little housekeeping items, first of all, yes, we are live. So if you're in our session, you can go ahead and chat, ask us questions. We'd love to get all your questions and answer them. Um, if you come to the main page on the website and you do not see the chat, go ahead and click on the blue button and that'll die. Uh, deep dive you into our session and you can interact with the chat there. Okay. Without further ado, let's just jump right into it. Katie, how are you? Welcome. Do you mind telling everybody who you are and a little bit about yourself? >>Absolutely. Hello everyone. My name is Katie and currently I am the eco-system advocate at cloud native computing foundation or CNCF. My responsibility is to lead and represent the end-user community. So these are all the practitioners within the cloud native space that are vendor neutral. So they use cloud native technologies to build their services, but they don't sell it. So this is quite an important characteristic as well. My responsibility is to make sure to close the gap between these practitioners and the project maintainers, to make sure that there is a feedback loop around. Um, I have many roles within the community. I am on the advisory board for KIPP finishes, a sandbox project. I'm working with open UK to make sure that Elton standards are used fairly across data, hardware, and software. And I have been, uh, affiliated way if you'd asked me to make sure that, um, I'm distributing a cloud native fundamental scores to make cloud and they do a few bigger despite everyone. So looking forward to this panel and checking with everyone. >>Awesome. Yeah. Welcome. Glad to have you here. Johanna's how are you? Can you, uh, tell everybody a little bit about yourself and who you are? Yeah, sure. >>So hi everybody. My name is Johannes I'm one of the co-founders at get pot, which in case you don't know is an open-source and container based development platform, which is probably also the reason why you Peter reached out and invited me here. So pleasure to be here, looking forward to the discussion. Um, yeah, though it is already a bit later in Munich. Um, and actually my girlfriend had a remote cocktail class with her colleagues tonight and it took me some stamina to really say no to all the Moscow mules that were prepared just over there in my living room. Oh wow. >>You're way better than me. Yeah. Well welcome. Thanks for joining us. Jerome. How are you? Good to see you. Can you tell everybody who you are and a little bit about yourself? Hi, >>Sure. Yeah, so I'm, I, I used to work at Docker and some, for me would say I'm a container hipster because I was running containers in production before it for hype. Um, I worked at Docker before it was even called Docker. And then since 2018, I'm now a freelancer and doing training and consulting around Docker containers, Kubernetes, all these things. So I used to help folks do stuff with Docker when I was there and now I still have them with containers more generally speaking. So kind of, uh, how do we say same, same team, different company or something like that? Yeah. >>Yeah. Perfect. Yeah. Good to see you. I'm glad you're on. Uh, Jacob, how are you? Good to see you. Thanks for joining us. Good. Yeah. Thanks for having me tell, tell everybody a little bit about yourself who you are. >>Yeah. So, uh, I'm the creator of a tool called mutagen, which is an open source, uh, development tool for doing high performance file synchronization and, uh, network forwarding, uh, to enable remote development. And so I come from like a physics background where I was sort of always doing, uh, remote developments, you know, whether that was on a big central clusters or just like some sort of local machine that was a bit more powerful. And so I, after I graduated, I built this tool called mutagen, uh, for doing remote development. And then to my surprise, people just started using it to use, uh, with Docker containers. And, uh, that's kind of grown into its primary use case now. So I'm, yeah, I've gotten really involved with the Docker community and, uh, talked with a lot of great people and now I'm one of the Docker captains. So I get to talk with even more and, and join these events and yeah, but I'm, I'm kind of focused on doing remote development. Uh, cause I, you know, I like, I like having all my tools available on my local machine, but I also like being able to pull in a little bit more powerful hardware or uh, you know, maybe a software that I can't run locally. And so, uh, that's sort of my interest in, in Docker container. Yeah. Awesome. >>Awesome. We're going to come back to that for sure. But yeah. Thank you again. I really appreciate you all joining me and yeah. So, um, I've been thinking about container first development for a while and you know, what does that actually mean? So maybe, maybe we can define it in our own little way. So I, I just throw it out to the panel. When you think about container first development, what comes to mind? What w what, what are you kind of thinking about? Don't be shy. Go ahead. Jerome. You're never a loss of words >>To me. Like if I go back to the, kind of the first, uh, you know, training engagements we did back at Docker and kind of helping folks, uh, writing Dockerfiles to stop developing in containers. Um, often we were replacing, um, uh, set up with a bunch of Vagrant boxes and another, like the VMs and combinations of local things. And very often they liked it a lot and they were very soon, they wanted to really like develop in containers, like run this microservice. This piece of code is whatever, like run that in containers because that means they didn't have to maintain that thing on their own machine. So that's like five years ago. That's what it meant to me back then. However, today, if you, if you say, okay, you know, developing in containers, um, I'm thinking of course about things like get bought and, uh, I think it's called PR or something like that. >>Like this theme, maybe that thing with the ESCO, that's going to run in a container. And you, you have this vs code thing running in your browser. Well, obviously not in your browser, but in a container that you control from your browser and, and many other things like that, that I, I think that's what we, where we want to go today. Uh, and that's really interesting, um, from all kinds of perspectives, like Chevy pair pairing when we will not next to each other, but actually thousands of miles away, um, or having this little environment that they can put aside and come back to it later, without it having using resource in my machine. Um, I don't know, having this dev service running somewhere in the cloud without needing something like, it's at the rights that are like the, the possibilities are really endless. >>Yeah. Yeah. Perfect. Yeah. I'm, you know, a little while ago I was, I was torn, right. W do I spin up containers? Do I develop inside of my containers? Right. There's foul sinking issues. Um, you know, that we've been working on at Docker for a while, and Jacob is very, very familiar with those, right? Sometimes it, it becomes hard, but, and I, and I love developing in the cloud, but I also have this screaming, you know, fast machine sitting on my desktop that I think I should take advantage of. So I guess another question is, you know, should we be developing inside of containers? Is that a smart thing to do? Uh, I'd love to hear you guys' thoughts around that. >>You know, I think it's one of those things where it's, you know, for me container first development is really about, um, considering containers as sort of a first class citizen in, in terms of your development toolkit, right. I mean, there's not always that silver bullet, that's like the one thing you should use for everything. You know, you shouldn't, you shouldn't use containers if they're not fitting in or adding value to your workflow, but I think there's a lot of scenarios that are like, you know, super on super early on in the development process. Like as soon as you get the server kind of running and working and, you know, you're able to access it, you know, running on your local system. Uh that's I think that's when the value comes in to it to add containers to, you know, what you're doing or to your project. Right. I mean, for me, they're, um, they're more of a orchestrational tool, right? So if I don't have to have six different browser tabs open with like, you know, an API server running at one tab and a web server running in another tab and a database running in another tab, I can just kind of encapsulate those and, and use them as an automation thing. So I think, you know, even if you have a super powerful computer, I think there's still value in, um, using containers as, as a orchestrational mechanism. Yeah. Yeah, >>For sure. I think, I think one of the, one of my original aha moments with Docker was, oh, I can spin up different versions of a database locally and not have to install it and not have to configure it and everything, but, you know, it just ran inside of a container. And that, that was it. Although it's might seem simple to some people that's very, very powerful. Right. So I think being able to spin things up and containers very quickly is one of the super benefits. But yeah, I think, uh, developing in containers is, is hard right now, right. With, um, you know, and how do you do that? Right. Does anybody have any thoughts around, how do you go about that? Right. Should you use a container as just a development environment, so, you know, creating an image and then running it just with your dev tools in it, or do you just, uh, and maybe with an editor all inside of it, and it's just this process, that's almost like a VM. Um, yeah. So I'll just kick it back to the panel. I'd love to hear your thoughts on, you know, how do you set up and configure, uh, containers to develop in any thoughts around that? >>Maybe one step back again, to answer your question, what kind of container first development mean? I think it doesn't mean, um, by default that it has to be in the cloud, right? As you said, um, there are obvious benefits when it comes to the developer experience of containers, such as, I dunno, consistency, we have standardized tools dependencies for the dev side of things, but it also makes their dev environment more similar to all the pipeline that is somehow happening to the right, right. So CIC D all the way to production, it is security, right? Which also somehow comes with standardization. Um, but vulnerability scanning tools like sneak are doing a great job there. And, um, for us, it gets pod. One of the key reasons why we created get pod was literally creating this peace of mind for deaths. So from a developer's point of view, you do not need to take care anymore about all the hassle around setups and things that you will need to install. >>And locally, based on some outdated, REIT me on three operating systems in your company, everybody has something different and leading to these verbs in my machine situations, um, that really slow professional software developers down. Right. Um, back to your point, I mean, with good pod, we obviously have to package everything together in one container because otherwise, exactly the situation happens that you need to have five browser tabs open. So we try and leverage that. And I think a dev environment is not just the editor, right? So a dev environment includes your source code. It includes like a powerful shell. It includes file systems. It includes essentially all the tools you need in order to be productive databases and so on. And, um, yeah, we believe that should be encapsulated, um, um, in a container. >>Yeah. Awesome. Katie, you talked to a lot of end users, right. And you're talking to a lot of developers. What, what's your thoughts around container first development, right? Or, or what's the community out there screaming or screaming. It might be too to, uh, har you know, to, to two grand of the word. Right. But yeah, I love it. I love to hear what your, your thoughts. >>Absolutely. So I think when you're talking about continuing driven development, uh, the first thing that crosses my mind is the awareness of the infrastructure or the platform you're going to run your application on top of, because usually when you develop your application, you'd like to replicate as much as possible the production or even the staging environment to make sure that when you deploy your application, you have us little inconsistencies as possible, but at the same time, you minimize the risk for something to go wrong as well. So when it talking about the, the community, um, again, when you deploy applications and containers and Kubernetes, you have to use, you have awareness about, and probably apply some of the best practices, like introducing liveliness and readiness probes, to make sure that your application can restart in, in case it actually goes down or there's like a you're starving going CPU or something like that. >>So, uh, I think when it comes to deployment and development of an application, the main thing is to actually improve the end developer experience. I think there has been a lot of focus in the community to develop the tool, to actually give you the right tool to run application and production, but that doesn't necessarily, um, go back to how the end developer is actually enabling that application to run into that production system. So I think there has been, uh, this focus for the community identified now, and it's more, more, um, or trying to build momentum on enhancing the developer experience. And we've seen this going through many, uh, where we think production of many tools did what has been one of them, which actually we can have this portable, um, development environment if you choose so, and you can actually replicate them across different teams in different machines, which is actually quite handy. >>But at the same time, we had tools such as local composts has been a great tool to run locally. We have tool such as carefully, which is absolutely great to automatically dynamically upload any changes to how within your code. So I think all of these kinds of tools, they getting more matured. And again, this is going back to again, we need to enhance our developer experience coming back to what is the right way to do so. Um, I think it really depends on the environment you have in production, because there's going to define some of the structures with the tool and you're going to have internally, but at the same time, um, I'd like to say that, uh, it really depends on, on what trucks are developing. Uh, so it's, it's, I would like to personally, I would like to see a bit more diversification in this area because we might have this competitive solutions that is going to push us to towards a new edge. So this is like, what definitely developer experience. If we're talking about development, that's what we need to enhance. And that's what I see the momentum building at the moment. >>Yeah. Yeah. Awesome. Jerome, I saw you shaking your head there in agreement, or maybe not, but what's your thoughts? >>I was, uh, I was just reacting until 82. Uh, it depends thinking that when I, when I do training, that's probably the answer that I gave the most, uh, each time somebody asks, oh, should we do diesel? And I was also looking at some of the questions in the chat about, Hey, the, should we like have a negatory in the, in the container or something like that. And folks can have pretty strong opinions one way or the other, but as a ways, it kind of depends what we do. It also depends of the team that we're working with. Um, you, you could have teams, you know, with like small teams with folks with lots of experience and they all come with their own Feb tools and editorials and plugins. So you know that like you're gonna have PRI iMacs out of my cold dead hands or something like that. >>So of course, if you give them something else, they're going to be extremely unhappy or sad. On the other hand, you can have team with folks who, um, will be less opinionated on that. And even, I don't know, let's say suddenly you start working on some project with maybe a new programming language, or maybe you're targeting some embedded system or whatever, like something really new and different. And you come up with all the tools, even the ADE, the extensions, et cetera, folks will often be extremely happy in that case that you're kind of giving them a Dettol and an ADE, even if that's not what they usually would, uh, would use, um, because it will come with all of the, the, the nice stage, you know, the compression, the, um, the, the, the bigger, the, whatever, all these things. And I think there is also something interesting to do here with development in containers. >>Like, Hey, you're going to start working on this extremely complex target based on whatever. And this is a container that has everything to get started. Okay. Maybe it's not your favorites editor, but it has all the customization and the conserver and whatever. Um, so you can start working right away. And then maybe later you, we want to, you know, do that from the container in a way, and have your own Emacs, atom, sublime, vs code, et cetera, et cetera. Um, but I think it's great for containers here, as well as they reserve or particularly the opportunity. And I think like the, that, that's one thing where I see stuff like get blood being potentially super interesting. Um, it's hard for me to gauge because I confess I was never a huge ID kind of person had some time that gives me this weird feeling, like when I help someone to book some, some code and you know, that like with their super nice IDE and everything is set up, but they feel kind of lost. >>And then at some point I'm like, okay, let's, let's get VI and grep and let's navigate this code base. And that makes me feel a little bit, you know, as this kind of old code for movies where you have the old, like colorful guy who knows going food, but at the end ends up still being obsolete because, um, it's only a going for movies that whole good for masters and the winning right. In real life, we don't have conformance there's anymore mentioned. So, um, but part of me is like, yeah, I like having my old style of editor, but when, when the modern editorial modern ID comes with everything set up and configured, that's just awesome. That's I, um, it's one thing that I'm not very good at sitting up all these little things, but when somebody does it and I can use it, it's, it's just amazing. >>Yeah. Yeah. I agree. I'm I feel the same way too. Right. I like, I like the way I've I have my environment. I like the tools that I use. I like the way they're set up. And, but it's a big issue, right? If you're switching machines, like you said, if you're helping someone else out there, they're not there, your key bindings aren't there, you can't, you can't navigate their system. Right? Yeah. So I think, you know, talking about, uh, dev environments that, that Docker's coming out with, and we're, you know, there's a lot, there, there's a, it's super complex, all these things we're talking about. And I think we're taking the approach of let's do something, uh, well, first, right. And then we can add on to that. Right. Because I think, you know, setting up full, full developed environments is hard, right. Especially in the, the, um, cloud native world nowadays with microservices, do you run them on a repo? >>Do you not have a monitor repo? Maybe that would be interesting to talk about. I think, um, you know, I always start out with the mono repos, right. And you have all your services in there and maybe you're using one Docker file. And then, because that works fine. Cause everything is JavaScript and node. And then you throw a little Python in there and then you throw a little go and now you start breaking things out and then things get too complex there, you know, and you start pulling everything out into different, get repos and now, right. Not everything just fits into these little buckets. Right. So how do you guys think maybe moving forward, how do we attack that night? How do we attack these? Does separate programming languages and environments and kind of bring them all together. You know, we, we, I hesitate, we solve that with compose around about running, right about executing, uh, running your, your containers. But, uh, developing with containers is different than running containers. Right. It's a, it's a different way to think about it. So anyway, sorry, I'm rattling on a little bit, but yeah. Be interesting to look at a more complex, uh, setup right. Of, uh, of, you know, even just 10 microservices that are in different get repos and different languages. Right. Just some thoughts. And, um, I'm not sure we all have this flushed out yet, but I'd love to hear your, your, you guys' thoughts around that. >>Jacob, you, you, you, you look like you're getting ready to jump there. >>I didn't wanna interrupt, but, uh, I mean, I think for me the issue isn't even really like the language boundary or, or, um, you know, a sub repo boundary. I think it's really about, you know, the infrastructure, right? Because you have, you're moving to an era where you have these cloud services, which, you know, some of them like S3, you can, you can mock up locally, uh, or run something locally in a container. But at some point you're going to have like, you know, cloud specific hardware, right? Like you got TPS or something that maybe are forming some critical function in your, in your application. And you just can't really replicate that locally, but you still want to be able to develop against that in some capacity. So, you know, my, my feeling about where it's going to go is you'll end up having parts of your application running locally, but then you also have, uh, you know, containers or some other, uh, element that's sort of cohabitating with, uh, you know, either staging or, or testing or production services that you're, uh, that you're working with. >>So you can actually, um, you know, test against a really or realistic simulation or the actual, uh, surface that you're running against in production. Because I think it's just going to become untenable to keep emulating all of that stuff locally, or to have to like duplicate these, you know, and, you know, I guess you can argue about whether or not it's a good thing that, that everything's moving to these kind of more closed off cloud services, but, you know, the reality of situation is that's where it's going to go. And there's certain hardware that you're going to want in the cloud, especially if you're doing, you know, machine learning oriented stuff that there's just no way you're going to be able to run locally. Right. I mean, if you're, even if you're in a dev team where you have, um, maybe like a central machine where you've got like 10 or 20 GPU's in it, that's not something that you're going to be able to, to, to replicate locally. And so that's how I kind of see that, um, you know, containers easing that boundary between different application components is actually maybe more about co-location, um, or having different parts of your application run in different locations, on different hardware, you know, maybe someone on your laptop, maybe it's someone, you know, AWS or Azure or somewhere. Yeah. It'd be interesting >>To start seeing those boundaries blur right. Working local and working in the cloud. Um, and you might even, you might not even know where something is exactly is running right until you need to, you know, that's when you really care, but yeah. Uh, Johanas, what's your thoughts around that? I mean, I think we've, we've talked previously of, of, um, you know, hybrid kind of environments. Uh, but yeah. What, what's your thoughts around that? >>Um, so essentially, yeah, I think, I mean, we believe that the lines between cloud and local will also potentially blur, and it's actually not really about that distinction. It's just packaging your dev environment in a way and provisioning your dev environment in a way that you are what we call always ready to coat. So that literally, um, you, you have that for the, you described as, um, peace of mind that you can just start to be creative and start to be productive. And if that is a container potentially running locally and containers are at the moment. I think, you know, the vehicle that we use, um, two weeks ago, or one week ago actually stack blitz announced the web containers. So potentially some things, well, it's run in the browser at some point, but currently, you know, Docker, um, is the standard that enables you to do that. And what we think will happen is that these cloud-based or local, um, dev environments will be what we call a femoral. So it will be similar to CIS, um, that we are using right now. And it doesn't literally matter, um, where they are running at the end. It's just, um, to reduce friction as much as possible and decrease and yeah, yeah. Essentially, um, avoid or the hustle that is currently involved in setting up and also managing dev environments, um, going forward, which really slows down specifically larger teams. >>Yeah. Yeah. Um, I'm going to shift gears a little bit here. We have a question from the audience in chat, uh, and it's, I think it's a little bit two parts, but so far as I can see container first, uh, development, have the challenges of where to get safe images. Um, and I was going to answer it, but let me keep it, let me keep going, where to get safe images and instrumentation, um, and knowing where exactly the problem is happening, how do we provide instrument instrumentation to see exactly where a problem might be happening and why? So I think the gist of it is kind of, of everything is in a container and I'm sitting outside, you know, the general thought around containers is isolation, right. Um, so how do I get views into that? Um, whether debugging or, or, or just general problems going on. I think that's maybe a broader question around the, how you, you know, you have your local hosts and then you're running everything containers, and what's the interplay there. W what's your thoughts there? >>I tend to think that containers are underused interactively. I mean, I think in production, you have this mindset that there's sort of this isolated environment, but it's very, actually simple to drop into a shell inside of a container and use it like you would, you know, your terminal. Um, so if you want to install software that way, you know, through, through an image rather than through like Homebrew or something, uh, you can kind of treat containers in that way and you can get a very, um, you know, direct access to the, to the space in which those are running in. So I think, I think that's maybe the step one is just like getting rid of that mindset, that, that these are all, um, you know, these completely encapsulated environments that you can't interact with because it's actually quite easy to just Docker exec into a container and then use it interactively >>Yeah. A hundred percent. And maybe I'll pass, I'm going to pass this question. You drone, but maybe demystify containers a little bit when I talked about this on the last, uh, panel, um, because we have a question in the, in the chat around, what's the, you know, why, why containers now I have VMs, right? And I think there's a misunderstanding in the industry, uh, about what, what containers are, we think they're fair, packaged stuff. And I think Jacob was hitting on that of what's underneath the hood. So maybe drown, sorry, for a long way to set up a question of what, what, what makes up a container, what is a container >>Is a container? Well, I, I think, um, the sharpest and most accurate and most articulate definition, I was from Alice gold first, and I will probably misquote her, but she said something like containers are a bunch of capsulated processes, maybe running on a cookie on welfare system. I'm not sure about the exact definition, but I'm going to try and, uh, reconstitute that like containers are just processes that run on a Unix machine. And we just happen to put a bunch of, um, red tape or whatever around them so that they are kind of contained. Um, but then the beauty of it is that we can contend them as much, or as little as we want. We can go kind of only in and put some actual VM or something like firecracker around that to give some pretty strong angulation, uh, all we can also kind of decontam theorize some aspects, you know, you can have a container that's actually using the, um, the, um, the network namespace of the host. >>So that gives it an entire, you know, wire speed access to the, to the network of the host. Um, and so to me, that's what really interesting, of course there is all the thing about, oh, containers are lightweight and I can pack more of them and they start fast and the images can be small, yada yada, yada. But to me, um, with my background in infrastructure and building resilient, things like that, but I find really exciting is the ability to, you know, put the slider wherever I need it. Um, the, the, the ability to have these very light containers, all very heavily, very secure, very anything, and even the ability to have containers in containers. Uh, even if that sounds a little bit, a little bit gimmicky at first, like, oh, you know, like you, you did the Mimi, like, oh, I heard you like container. >>So I put Docker when you're on Docker. So you can run container for you, run containers. Um, but that's actually extremely convenient because, um, as soon as you stop building, especially something infrastructure related. So you challenge is how do you test that? Like, when we were doing.cloud, we're like, okay, uh, how do we provision? Um, you know, we've been, if you're Amazon, how do you provision the staging for us installed? How do you provision the whole region, Jen, which is actually staging? It kind of makes things complicated. And the fact that we have that we can have containers within containers. Uh, that's actually pretty powerful. Um, we're also moving to things where we have secure containers in containers now. So that's super interesting, like stuff like a SIS box, for instance. Um, when I saw that, that was really excited because, uh, one of the horrible things I did back in the days as Docker was privileged containers, precisely because we wanted to have Docker in Docker. >>And that was kind of opening Pandora's box. That's the right, uh, with the four, because privileged containers can do literally anything. They can completely wreck up the machine. Um, and so, but at the same time, they give you the ability to run VPNs and run Docker in Docker and all these cool things. You can run VM in containers, and then you can list things. So, um, but so when I saw that you could actually have kind of secure containers within containers, like, okay, there is something really powerful and interesting there. And I think for folks, well, precisely when you want to do development in containers, especially when you move that to the cloud, that kind of stuff becomes a really important and interesting because it's one thing to have my little dev thing on my local machine. It's another thing when I want to move that to a swarm or Kubernetes cluster, and then suddenly even like very quickly, I hit the wall, which is, oh, I need to have containers in my containers. Um, and then having a runtime, like that gets really intense. >>Interesting. Yeah, yeah, yeah. And I, and jumping back a bit, um, yeah, uh, like you said, drum at the, at the base of it, it containers just a, a process with, with some, uh, Abra, pardon me, operating constructs wrapped around it and see groups, namespaces those types of things. But I think it's very important to, for our discussion right. Of, uh, developers really understanding that, that this is just the process, just like a normal process when I spin up my local bash in my term. Uh, and I'm just interacting with that. And a lot of the things we talk about are more for production runtimes for securing containers for isolating them locally. I don't, I don't know. I'll throw the question out to the panel. Is that really relevant to us locally? Right. Do we want to pull out all of those restrictions? What are the benefits of containers for development, right. And maybe that's a soft question, but I'd still love to hear your thoughts. Maybe I'll kick it over to you, Katie, would you, would you kick us off a little bit with that? >>I'll try. Um, so I think when, again, I was actually thinking of the previous answers because maybe, maybe I could do a transition here. So, interesting, interesting about containers, a piece of trivia, um, the secrets and namespaces have been within the Linux kernel since 2008, I think, which just like more than 10 years ago, hover containers become popular in the last years. So I think it's, it's the technology, but it's about the organization adopting this technology. So I think why it got more popular now is because it became the business differentiator organizations started to think, how can I deliver value to my customers as quickly as possible? So I think that there should be this kind of two lane, um, kind of progress is the technology, but it's at the same time organization and cultural now are actually essential for us to develop, uh, our applications locally. >>Again, I think when it's a single application, if you have just one component, maybe it's easier for you to kind of run it locally, have a very simple testing environment. Sufficient is a container necessary, probably not. However, I think it's more important when you're thinking to the bigger picture. When we have an architecture that has myriads of microservices at the basis, when it's something that you have to expose, for example, an API, or you have to consume an API, these are kind of things where you might need to think about a lightweight set up within the containers, only local environment to make sure that you have at least a similar, um, environment or a configuration to make sure that you test some of the expected behavior. Um, I think the, the real kind of test you start from the, the dev cluster will like the dev environment. >>And then like for, for you to go to staging and production, you will get more clear into what exactly that, um, um, configuration should be in the end. However, at the same time, again, it's, it's more about, um, kind of understanding why you continue to see this, the thing, like, I don't say that you definitely need containers at all times, but there are situations when you have like, again, multiple services and you need to replicate them. It's just the place to, to, to work with these kind of, um, setups. So, um, yeah, really depends on what you're trying to develop here. Nothing very specific, unfortunately, but get your product and your requirements are going to define what you're going to work with. >>Yeah, no, I think that's a great answer, right. I think one of the best answers in, in software engineering and engineering in general as well, it depends. Right. It's things are very specific when we start getting down to the details, but yeah, generally speaking, you know, um, I think containers are good for development, but yeah, it depends, right. It really depends. Is it helping you then? Great. If it's hindering you then, okay. Maybe think what's, what's the hindrance, right. And are containers the right solution. I agree. 110% and, >>And everything. I would like absurd this too as well. When we, again, we're talking about the development team and now we have this culture where we have the platform and infrastructure team, and then you have your engineering team separately, especially when the regulations are going to be segregated. So, um, it's quite important to understand that there might be a, uh, a level of up-skilling required. So pushing for someone to use containers, because this is the right way for you to develop your application might be not, uh, might not be the most efficient way to actually develop a product because you need to spend some time to make sure that the, the engineering team has the skills to do so. So I think it's, it's, again, going back to my answers here is like, truly be aware of how you're trying to develop how you actually collaborate and having that awareness of your platform can be quite helpful in developing your, uh, your publication, the more importantly, having less, um, maybe blockers pushing it to a production system. >>Yeah, yeah. A hundred percent. Yeah. The, uh, the cultural issue is, is, um, within the organization, right. Is a very interesting thing. And it, and I would submit that it's very hard from top down, right. Pushing down tools and processes down to the dev team, man, we'll just, we'll just rebel. It usually comes from the bottom up. Right. What's working for us, we're going to do right. And whether we do it in the shadows and don't let it know, or, or we've conformed, right. Yeah. A hundred percent. Um, interesting. I would like to think a little bit in the future, right? Like, let's say, I don't know, two, three years from now, if, if y'all could wave a and I'm from Texas. So I say y'all, uh, if you all could wave a magic wand, what, what, what would that bring about right. What, what would, what would be the best scenario? And, and we just don't have to say containers. Right. But, you know, what's the best development environment and I'm going to kick it over to you, Jacob. Cause I think you hinted at some of that with some hybrid type of stuff, but, uh, yeah. Implies, they need to keep you awake. You're, you're, you're, uh, almost on the other side of the world for me, but yeah, please. >>Um, I think, you know, it's, it's interesting because you have this technology that you've been, that's been brought from production, so it's not, um, necessarily like the right or the normal basis for development. So I think there's going to be some sort of realignment or renormalization in terms of, uh, you know, what the, what the basis and the abstractions that we're using on a daily basis are right. Like images and containers as they exist now are really designed for, um, for production use cases. And, and in terms of like, even even the ergonomics of opening a shell inside a container, I think is something that's, um, you know, not as polished or not as smooth as it could be because they've come from production. And so I think it's important, like not to, not to have people look at, look at the technology as it exists now and say like, okay, this is slightly rough around the edges, or it wasn't designed for this use case and think, oh, there's, you know, there's never any way I could use this for, for my development of workflows. >>I think it's, you know, it's something Docker's exploring now with, uh, with the, uh, dev containers, you know, it's, it's a new, and it's an experimental paradigm and it may not be what the final picture looks like. As, you know, you were saying, there's going to be kind of a baseline and you'll add features to that or iterate on that. Um, but I think that's, what's interesting about it, right? Cause it's, there's not a lot of things as developers that you get to play with that, um, that are sort of the new technology. Like if you're talking about things you're building to ship, you want to kind of use tried and true components that, you know, are gonna, that are going to be reliable. But I think containers are that interesting point where it's like, this is an established technology, but it's also being used in a way now that's completely different than what it was designed for. And, and, you know, as hackers, I think that's kind of an interesting opportunity to play with it, but I think, I think that's, what's going to happen is you're just going to see kind of those production, um, designed, uh, knobs kind of sanded down or redesigned for, for development. So that's kind of where I see it going. >>Yeah. Yeah. And I think that's what I was trying to hint out earlier is like, um, yeah, just because all these things are there, does it actually mean we need them locally? Right. Do they make sense? I, I agree. A hundred percent, uh, anybody else drawn? What are your thoughts around that? And then, and then, uh, I'll probably just ask all of you. I'd love to hear each of your thoughts of the future. >>I had a thought was maybe unrelated, but I was kind of wondering if we would see something on the side of like energy efficiency in some way. Um, and maybe it's just because I've been thinking a lot about like climate change and things like that recently, and trying to reduce like the, uh, the energy use energy use and things like that. Perhaps it's also because I recently got a new laptop, which on paper is super awesome, but in practice, as soon as you try to have like two slack tabs and a zoom call, you know, it's super fast, both for 30 seconds. And after 30 seconds, it blows its thermal budget and it's like slows down to a crawl. And I started to think, Hmm, maybe, you know, like before we, we, we were thinking about, okay, I don't have that much CPU available. So you have to be kind of mindful about that. >>And now I wonder how are we going to get in something similar to that, but where you try to save CPU cycles, not just because you don't have that many CPU cycles, but more because you know, that you can't go super fast for super long when you are on one of these like small laptops or tablets or phones, like you have this demo budget to take into account. And, um, I wonder if, and how like, is there something where goaltenders can do some things here? I guess it can be really interesting if they can do some the equivalent of like Docker top and Docker stats. And if I could see, like how much what's are these containers using, I can already do that with power top on Linux, for instance, like process by process. So I'm thinking I could see what's the power usage of, of some containers. Um, and I wonder if down the line, is this going to be something useful or is this just silly because we can just masquerade CPU usage for, for Watson and forget about it. >>Yeah. Yeah. It was super, super interesting, uh, perspective for sure. I'm going to shut up because I want to, I want to give, make sure I give Johannes and Katie time. W w what are your thoughts of the future around, let's just say, you know, container development in general, right? You want, you want to start absolutely. Oh, honest, Nate. Johns wants more time. I say, I'll try not to. Beneficiate >>Expensive here, but, um, so one of the things that we've we've touched upon earlier in the panel was multicloud strategy. And I was reading one of the data reports from it was about the concept of Kubernetes from gamer Townsville. But what is working for you to see there is that more and more organizations are thinking about multicloud strategy, which means that you need to develop an application or need an infrastructure or a component, which will allow you to run this application bead on a public cloud bead, like locally in a data center and so forth. And here, when it comes to this kind of, uh, maybe problems we come across open standards, this is where we require something, which will allow us to execute our application or to run our platform in different environments. So when you're thinking about the application or development of the application, one of the things that, um, came out in 2019 at was the Oakland. >>Um, I wish it was Kybella, which is a, um, um, an open application model based application, which allows you to describe the way you would like your service to be executed in different environments. It doesn't need to be well developed specifically for communities. However, the open application model is specialized. So specialized tries to cover multiple platforms. You will be able to execute your application anywhere you want it to. So I think that that's actually quite important because it completely obstructs what is happening underneath it, completely obstructs notions, such as containers, uh, or processes is just, I want this application and I want to have this kind of behavior is so example of, to scale in this conditions or to, um, to be exposed for these, uh, end points and so forth. And everything that I would like to mention here is that maybe this transcends again, the, uh, the logistics of the application development, but it definitely will impact the way we run our applications. >>So one of the biggest, well, one of the new trends that is kind of gaining momentum now has been around Plaza. And this is again, something which is trying to present what we have the on containers. Again, it's focusing on the, it's kind of a cyclical, um, uh, action movement that we have here. When we moved from the VMs to containers, it was smaller footprint. We want like better execution, one, this agnosticism of the platforms. We have the same thing happening here with Watson, but again, it consents a new, um, uh, kind of, well, it teaches in you, uh, in new climax here, where again, we shrink the footprint of the cluster. We have a better isolation of all the services. We have a better trend, like portability of how services and so forth. So there is a great potential out there. And again, like why I'm saying this is some of these technologies are gonna define the way we're gonna do our development of the application on our local environment. >>That's why it's important to kind of maybe have an eye there and maybe see if some of those principles of some of those technologies we can bring internally as well. And just this, like a, a final thought here, um, security has been mentioned as well. Um, I think it's something which has been, uh, at the forefront, especially when it comes to containers, uh, especially when it comes to enterprise organizations and those who are regulated, which I feel come very comfortable to run their application within a VM where you have the full isolation, you can do what we have complete control of what's happening inside that compute. So, um, again, security has been at the forefront at the moment. So I know it has mentioned in the panel before. I'd like to mention that we have the security white paper, which has been published. We have the software supply chain, white paper as well, which twice to figure out or define some of these good practices as well, again, which you can already apply from your development environment and then propagate them to production. So I'm just going to leave, uh, all of these. That's all. >>That's awesome. And yeah, well, while is very, very interesting. I saw the other day that, um, and I forget who it was, maybe, maybe all can remember, um, you know, running, running the node, um, engine inside of, you know, in Walzem inside of a browser. Right. And, uh, at first glance I said, well, we already have a JavaScript execution engine. Right. And it's kind of like Docker and Docker. So you have, uh, you know, you have the browser, then, then you have blossom and then you have a node, you know, a JavaScript runtime. And, and I didn't understand was while I was, um, you know, actually executing is JavaScript and it's not, but yeah, it's super interesting, super powerful. I always felt that the browser was, uh, Java's what write once run anywhere kind of solution, right. That never came about, they were thinking of set top, uh, TV boxes and stuff like that, which is interesting. >>I don't know, you'll some of the history of Java, but yeah. Wasm is, is very, I'm not sure how to correctly pronounce it, but yeah, it's extremely interesting because of the isolation in that boxing. Right. And running powerful languages that were used to inside of a more isolated environment. Right. And it's almost, um, yeah, it's kind of, I think I've mentioned it before that the containers inside of containers, right. Um, yeah. So Johannes, hopefully I gave you enough time. I delayed, I delayed as much as I can. My friend, you better, you better just kidding. I'm just kidding, please, please. >>It was by the way, stack let's and they worked together with Google and with Russell, um, developing the web containers, it's called there's, it's quite interesting. The research they're doing there. Yeah. Yeah. I mean, what we believe and I, I also believe is that, um, yeah, probably somebody is doing to death environments, what Docker did to servers and at least that good part. We hope that somebody will be us. Um, so what we mean by that is that, um, we think today we are still somehow emotionally attached to our dev environments. Right. We give them names, we massage them over time, which can also have its benefits, but it's, they're still pets in some way. Right. And, um, we believe that, um, environments in the future, um, will be treated similar like servers today as automated resources that you can just spin up and close down whenever you need them. >>Right. And, um, this trend essentially that you also see in serverless, if you look at what kind of Netlify is doing a bit with preview environments, what were sellers doing? Um, there, um, we believe will also arrive at, um, at Steph environments. It probably won't be there tomorrow. So it will take some time because if there's also, you know, emotion involved into, in that, in that transition, but ultimately really believe that, um, provisioning dev environments also in the cloud allows you to leverage the power of the cloud and to essentially build all that stuff that you need in order to work in advance. Right? So that's literally either command or a button. So either, I don't know, a command that spins up your local views code and SSH into, into a container, or you do it in a browser, um, will be the way that professional development teams will develop in the future. Probably let's see in our direction of document, we say it's 2000 to 23. Let's see if that holds true. >>Okay. Can we, can, we let's know. Okay. Let's just say let's have a friendly bet. I don't know that's going to be closed now, but, um, yeah, I agree. I, you know, it's my thought around is it, it's hard, right? Th these are hard. And what problems do you tackle first, right? Do you tackle the day, one of, uh, you know, of development, right. I joined a team, Hey, here's your machine? And you have Docker installed and there you go, pull, pull down your environment. Right. Is that necessarily just an image? You know, what, what exactly is that sure. Containers are involved. Right. But that's, I mean, you, you've probably all gone through it. You joined a team, new project, even open-source project, right there. There's a huge hurdle just to get everything configured, to get everything installed, to get it up and running, um, you know, set aside all understanding the code base. >>Cause that's a different issue. Right. But just getting everything running locally and to your point earlier, Jacob of around, uh, recreating, local production cues and environments and, you know, GPS or anything like that, right. Is extremely hard. You can't do a lot of that locally. Right. So I think that's one of the things I'd love to see tackled. And I think that's where we're tackling in dev environments, uh, with Docker, but then now how do you become productive? Right. And where do we go from there? And, uh, and I would love to see this kind of hybrid and you guys have been all been talking about it where I can, yes. I have it configured everything locally on my nice, you know, apple notebook. Right. And then, you know, I go with the family and we go on vacation. I don't want to drag this 16 inch, you know, Mac laptop with me. >>And I want to take my nice iPad with the magic keyboard and all the bang stuff. Right. And I just want to fire up and I pick up where I left off. Right. And I keep coding and environment feels, you know, as much as it can that I'm still working at backup my desktop. I think those, those are very interesting to me. And I think reproducing, uh, the production running runtime environments as close as possible, uh, when I develop my, I think that's extremely powerful, extremely powerful. I think that's one of the hardest things, right. It's it's, uh, you know, we used to say, we, you debug in production. Right. We would launch, right. We would do, uh, as much performance testing as possible. But until you flip that switch on a big, on a big site, that's where you really understand what is going to break. >>Right. Well, awesome. I think we're just about at time. I really, really appreciate everybody joining me. Um, it's been a pleasure talking to all of you. We have to do this again. If I, uh, hopefully, you know, I I'm in here in America and we seem to be doing okay with COVID, but I know around the world, others are not. So my heart goes out to them, but I would love to be able to get out of here and come see all of you and meet you in person, maybe break some bread together. But, um, again, it was a pleasure talking to you all, and I really appreciate you taking the time. Have a good evening. Cool. >>Thanks for having us. Thanks for joining us. Yes.

>> From the KIPP studios in Palo Alto in Boston, connecting with thought leaders all around the world, this is a CUBE conversation. >> IBM's new CEO has an opportunity to reset the direction of the company. Outgoing CEO Ginni Rometty, inherited a strategy that was put in place over two decades. It became fossilized in a lower-margin services-led model that she helped architect. Ginni spent a large portion of her tenure, shrinking the company so it could grow. But unfortunately, she ran out of time. For decades, IBM has missed opportunities to aggressively invest in the key waves that are now powering the tech economy. Instead, IBM really tried to balance investing innovation with placating Wall Street. We believe IBM has an opportunity to return to the Big Blue status that set the standard for the tech industry. But several things have to change, some quite dramatically. So we're going to talk about what it's going to take for IBM to succeed in this endeavor. Welcome to this special Wikibon CUBE Insights powered by ETR. In this breaking analysis, we're going to address our view of the future of IBM and try to accomplish three things. First, I want to review IBM's most recent earnings, the very first one under new CEO Arvind Krishna, and we'll discuss IBM's near-term prospects. Next, we'll look at how IBM got to where we are today. We want to review some of the epic decisions that it has made over the past several years and even decades. Finally, we'll look at some of the opportunities that we see for IBM to essentially remake itself and return to that tech titan that was revered by customers and feared by competitors. First, I want to look at the comments from new CEO Arvind Krishna. And let's try to decode them a bit. Arvind in the first earnings call that he held, and in interviews as well, and also internal memos, he's given some clues as to how he's thinking. This slide addresses a few of the key points. Arvind has clearly stated that he's committed to growing the IBM company, and of course, increasing its value. This is no surprise, as you know, every IBM CEO has been under pressure to do the same. And we'll look at that further a little later on in the segment. Arvind, also stated that he wants the company, he said it this way, "To lead with a technical approach." Now as we reported in January when Krishna was appointed to CEO. We're actually very encouraged that the IBM board chose a technical visionary to lead the company. Arvind's predecessors did not have the technical vision needed to make the bold decisions that we believe are now needed to power the company's future. As a technologist, we believe his decisions will be more focused on bigger tactical bets that can pay bigger returns, potentially with more risk. Now, as a point of just tactical commentary, I want to point out that IBM noted that it was doing well coming into the March month, but software deals especially came to a halt as customers focused on managing the pandemic and other parts of the business were okay. Now, this chart pulls some of the data from IBM's quarter. And let me make a few comments here. Now, what was weird here, IBM cited modest revenue growth on this chart, this was pulled from their slides. But revenue was down 2% for the quarter relative to last year. So I guess that's modest growth. Cloud revenue for the past 12 months, the trailing 12 months, was 22 billion and grew 23%. We're going to unpack that in a minute. Red Hat showed good growth, Stu Miniman and I talked about this last week. And IBM continues to generate a solid free cash flow. Now IBM, like many companies, they prudently suspended forward guidance. Some investors bristled at that, but I really have no problem with it. I mean, just way too much uncertainty right now. So I think that was a smart move by IBM. And basically, everybody's doing it. Now, let's take a look at IBM's business segments and break those down and make a few comments there. As you can see, in this graph, IBM's 17 plus billion dollar quarter comprises their four reporting segments. Cloud and cognitive software, which is, of course, its highest margin and highest growth business at 7%. You can see its gross margin is really, really nice. But it only comprises 30% of the pie. Services, the Global Business Services and GTS global technology services are low-growth or no growth businesses that are relatively low margin operations. But together they comprise more than 60% of IBM's revenue in the quarter and consistently throughout the last several years. Systems, by the way, grew nicely on the strength of the Z15 product cycles, it was up by 60% and dragged storage with it. But unfortunately power had a terrible quarter and hence the 4% growth. But decent margins compared to services of 50%. IBM's balance sheet looks pretty good. It took an advantage of some low rates recently and took out another $4 billion in corporate debt. So it's okay, I'm not too concerned about its debt related to the Red Hat acquisition. Now, welcome back to cloud at 22 billion for the past 12 months and growing at 23%. What, you say? That sounds very large, I don't understand. It's understandable that you don't understand. But let me explain with this next graphic. What this shows is the breakdown of IBM's cloud revenue by segment from fiscal year 19. As you can see, the cloud and cognitive segments, or segment which includes Red Hat comprises only 20% of IBM's cloud business. I know, kind of strange. Professional services accounts for 2/3 of IBM's Cloud revenue with systems at 14%. So look, IBM is defining cloud differently than most people. I mean, actually, that's 1% of the cloud business of AWS, Azure and Google Cloud come from professional services and on-prem hardware. This just doesn't have real meaning. And I think frankly, it hurts IBM's credibility as it hides the ball on cloud. Nobody really believes this number. So, I mean, it's really not much else I can say there. But look, why don't we bring in the customer angle, and let's look at some ETR data. So what this chart shows is the results of an ETR survey. That survey ran, we've been reporting on this, ran from mid March to early April. And more than 1200 respondents and almost 800 IBM customers are in there. If this chart shows the percentage of customers spending more on IBM products by various product segments that we chose with three survey samples April last year, January 2020, and the most recent April 2020 survey. So the good news here is the container platforms, OpenShift, Ansible, the Staples of Red Hat are showing strength, even though they're notably down from previous surveys. But that's the part of IBM's business that really is promising. AI and machine learning and cloud, they're right there in the mix, and even outsourcing and consulting and really across the board, you can see a pretty meaningful and respectable number or percent of customers are actually planning on spending more. So that's good, especially considering that the survey was taken right during the middle of the COVID-19 pandemic. But, if you look at the next chart, the net scores across IBM's portfolio, they're not so rosy. Remember, net score is a measure of spending momentum. It's derived by essentially subtracting the percent of customers that are spending less from those that are spending more. It's a nice simple metric. Kind of like NPS and ETR surveys, every quarter with the exact same methodology for consistency so we can do some comparisons over time series, it's quite nice. And you can see here that Red Hat remains the strongest part of IBM's portfolio. But generally in my experience as net scores starts to dip below 25% and kind of get into the red zone, that so called danger zone. And you can see many parts of IBM's portfolio are showing softness as we measure in net score. And even though you see here, the outsourcing and consulting businesses are up relative to last year, if you slice the data by large companies, as we showed you with Sagar Kadakia last week, that services business is showing deceleration, same thing we saw for Accenture, EY, Deloitte, etc. So here's the takeaway. Red Hat, of course, is where all the action is, and that's where IBM is going to invest in our opinion, and we'll talk a little bit more about that and drill into that kind of investment scenario a bit later. But what I want to do now is I want to come back to Arvind Krishna. Because he has a chance to pull off a Satya Nadella like move. Maybe it's different, but there are definite similarities. I mean, you have an iconic brand, a great company, that's in many technology sectors, and yes, there are differences, IBM doesn't have the recurring software revenue that Microsoft had, it didn't have the monopoly and PCs. But let's move on. Arvind has cited four enduring platforms for IBM, mainframes, services, middleware, and the newest hybrid cloud. He says that IBM must win the architectural battle for hybrid cloud. Now, I'm going to really share later what we think that means. There's a lot in that statement, including the role of AI in the edge. Both of which we'll address later on in this breaking analysis. But before we get there, I want to understand from a historical perspective where we think Arvind is going to take IBM. And to do that, we want to look back over the modern history of IBM, modern meaning of the post mainframe dominance era, which really started in 1993 when Louis Gerstner took over. Look, it's been well documented how Louis Gerstner pivoted into services. He wrote his own narrative with the book, "Who Says Elephants Can't Dance". And you know, look, you can't argue with his results. The graphic here shows IBM's rank in the fortune 500, that's the green line over time. IBM was sixth under Gerstner, today it's number 38. The blue area chart on the Insert, it shows IBM's market cap. Now, look, Gerstner was a hero to Wall Street. And IBM's performance under his tenure was pretty stellar. But his decision to pivot to services set IBM on a path that to this day marks company's greatest strength, and in my view, its greatest vulnerability. Name a product under the mainframes in which IBM leads. Again, middleware, I guess WebSphere, okay. But you know, IBM used to be the leader in the all important database market, semiconductors, storage servers, even PCs back in the day. So, I don't want to beat on this too much, I can say it's been well documented. And I said earlier, Ginni essentially inherited a portfolio that she had to unwind, and hence the steep revenue declines as you see here, and it's 'cause she had to jettison the so called non-strategic businesses. But the real issue is R&D, and how IBM has used it's free cash. And this chart shows IBM's breakdown of cash use between 2007 and 2019. Blue is cash return to shareholders, orange is research and development, and gray is CapEx. Now I chose these years because I think we can all agree that this was the period of tech defined by cloud. And you can see, during those critical early formative years, IBM consistently returned well over 50%, and often 60% plus of its free cash flow to shareholders in the form of dividends and stock buybacks. Now, while the orange appears to grow, it's because of what you see in this chart. The point is the absolute R&D spend really didn't change too much. It pretty much hovered, if you look back around 5 1/2 to $6 billion annually, the percentage grew because IBM's revenue declined. Meanwhile, IBM's competitors were spending on R&D and CapEx, what were they doing? Well, they were building up the cloud. Now, let me give you some perspective on this. In 2007 IBM spent $6.2 billion on R&D, Microsoft spent 7 billion that same year, Intel 5.8 billion, Amazon spent 800 million, that's it. Google spent 2.1 billion that year. And that same year, IBM returned nearly $21 billion to shareholders. In 2012 IBM spent $6.3 billion on R&D, Microsoft that year 9.8 billion, Intel 10 billion, Amazon 4.6 billion, less than IBM, Google 6.1 billion, about the same as IBM. That year IBM returned almost $16 billion to shareholders. Today, IBM spends about the same 6 billion on R&D, about the same as Cisco and Oracle. Meanwhile, Microsoft and Amazon are spending nearly $17 billion each. Sorry, Amazon 23 billion, and IBM could only return $7 billion to shareholders last year. So while IBM was returning cash to its shareholders, its competitors were investing in the future and are now reaping the rewards. Now IBM suspended its stock buybacks after the Red Hat deal, which is good, in my opinion. Buybacks have been a poor use of cash for IBM, in my view. Recently, IBM raised its dividend by a penny. It did this so it could say that it has increased its dividend 25 years in a row. Okay, great, not expensive. So I'm glad that that investors were disappointed with that move. But since 2007, IBM has returned more than $175 billion to shareholders. And somehow Arvind has to figure out how to tell Wall Street to expect less while he invests in the future. So let's talk about that a little bit. Now, as I've reported before, here is the opportunity. This chart shows data from ETR. It plots cloud landscape and is a proxy for multi-cloud and hybrid cloud. It plots net score or spending momentum on the y-axis, and market share, which really isn't market share, as we've talked about, it's a measure of pervasiveness in the data set, that's plotted on the x-axis. So, the point is, IBM has presence, it's pervasive in the marketplace, Red Hat and OpenShift, they have relevance, they have momentum with higher net scores. Arvind's opportunity is to really plug OpenShift into IBM's, large install base, and increase Red Hat's pervasiveness, while at the same time lifting IBM momentum. This, in my view, as Stu Miniman and I reported last week at the Red Hat Summit, puts IBM in a leading position to go after multi and hybrid cloud and the edge. So let's break that down a little bit further. When Arvind talks about winning the architectural battle for hybrid cloud, what does he mean by that? Here's our interpretation. We think IBM can create the de facto standard for cloud and hybrid cloud. And this includes on-prem, public cloud, cross clouds, or multi cloud, and importantly, the edge. Here's the opportunity, is to have OpenShift run natively, natively everywhere, on-premises in the AWS cloud, in the Azure Cloud, GCP, Alibaba, and the IBM Cloud and the Oracle Cloud, everywhere natively, so we can take advantage of the respective services within all those clouds. Same thing for on-prem, same thing for edge opportunities. Now I'll talk a little bit more about that in a moment. But what we're talking about here is the entire IT stack running natively, if I haven't made that point on OpenShift. The control plane, the security plane, the transport, the data management plane, the network plane, the recovery plane, every plane, a Red Hat lead stack with a management of resources is 100% identical, everywhere the same cloud experience. That's how IBM is defining cloud. Okay, I'll give them a mulligan on that one. IBM can be the independent broker of this open source standard covering as many use cases and workloads as possible. Here's the rub, this is going to require an enormous amount of R&D. Just think about all the startups that are building cloud native services and imagine IBM building or buying to fill out that IT stack. Now I don't have enough time to go in too deep to all other areas, but I do want to address the edge, the opportunity there and weave in AI. Beyond what I said above, which I want to stress, the points I made above about hybrid, multi-cloud include edge, the edge is a huge opportunity. But IBM and in many other, if not most other traditional players, we think are kind of missing the boat on that. I'll talk about that in a minute. Here's the opportunity, AI inference is going to run at the edge in real-time. This is going to be incredibly challenging. We think about this, a car running inference AI generates a billion pixels per second today, in five years, it'll be 15 times that. The pressure for real-time analysis at the edge is going to be enormous, and will require a new architecture with new processing models that are likely going to be ARM-based in our opinion. IBM has the opportunity to build end-to-end solutions powered by Red Hat to automate the data pipeline from factory to data center to cloud and everywhere. Anywhere there's instruments, IBM has an opportunity to automate them. Now rather than toss traditional Intel-based IT hardware over the fence to the edge, which is what IBM and most people are doing right now, IBM can develop specialized systems and make new silicon investments that can power the edge with very low cost and efficient systems that process data in real-time. Hey look, I'm out of time, but some other things I want you to consider, IBM transitioning to a recurring revenue model. Interestingly, Back to the Future, right? IBM used to have a massive rental revenue stream before it converted that base to sales. But if Arvind can recreate a culture of innovation and win the day with developers via its Red Hat relationships, as I said recently, he will be CEO of the decade. But he has to transform the portfolio by investing more in R&D. He's got to convince the board to stop pouring money back to investors for a number of years, not just a couple of quarters and do Whatever they have to do to protect the company from corporate raiders. This is not easy, but with the right leader, IBM, a company that has shown resilience through the decades, I think it can be done. All right, well, thanks for watching this episode of the Wikibon CUBE Insights powered by ETR. This is Dave Vellante. And don't forget, these episodes are available as podcasts, wherever you listen, I publish weekly on siliconangle.com, where you'll find all the news, I publish on wikibon.com which is our research site. Please comment on my LinkedIn posts, check out etr.plus, that's where all the data lives. And thanks for watching everybody. This is Dave Vellante for Breaking Analysis, we'll see you next time. (soft music)