Unlocking Developers’ Efficiency Using Loft & Komodor

You can also view the full presentation deck here.

 

[Transcript]

Rich Burroughs: Hi, everyone. I’m Rich. Rich Burroughs with Loft Labs and I’m here with Guy from Komodor. How’s it going, Guy?

Guy: Hey, great, Rich. Good to see you.

Rich Burroughs: Yeah, you too. So, we’re going to be talking with you all about Unlocking Developers’ Efficiency, about some ways that both Loft and Komodor can help you build dev environments and help developers manage them and figure out what’s going on inside of them. So, do we need to bring in the slide deck? Oh, here we go. Yeah, do you want to get into presentation mode there, Guy?

Guy: Yeah, oh you can see the presentation mode over there?

Rich Burroughs: Yeah.

Guy: We give it a try.

Rich Burroughs: Yeah, I’m seeing that left bar with all the sides.

Guy: Oh, that’s strange. Now as well?

Rich Burroughs: Yeah. Can you just hit Slideshow?

Guy: Yeah, now its slide showing my screen.

Rich Burroughs: Okay. Weird. Okay. Well, let’s move ahead anyway. Hey, like I said, I’m Rich Burroughs. I’m a staff developer advocate at Loft Labs. Guy is solutions engineer and we are here to talk to you about Unlocking Developer Efficiency. We just lost the slides entirely now.

Guy: I’m just beginning it in.

Rich Burroughs: Okay.

Guy: Now can you see it?

Rich Burroughs: Yes. Thank you.

Guy: Oh great. Great.

Rich Burroughs: Awesome. Yeah, so let’s move on to the agenda. Yeah, so go ahead Guy.

Guy: Cool. So sorry for the delay on the slider. So, as Rich said we are going to talk about dev efficiency and how you can improve your efficiency of development and we are going to start with the challenges and the whys of dev efficiency. Again, we talk about Loft and Komodor and how together this product can bring a self-serve platform into your development environment and make Kubernetes cluster be spawn up very quickly and then the developers within your bank can access troubleshoot and do a lot of things with it. We are going to show it on a live demo, which is going to be great. Just before we starting, I want to mention that if you have any comments questions that you want to share, feel free to drop it on the chat on the comments. We would like you to ask as many questions as you want during the session, so we’ll be able to interact with you. So, feel free to drop any questions at the comment below.

Rich Burroughs: Yeah, please do. And yeah, so some of the big challenges to unlocking developer efficiency for people who working with Kubernetes’s, bootstrapping easy, fast, and streamlined environments. You want something that’s reproducible. Hey, Landon asked if there will be a recording afterwards. Yes, there will be Landon. So yeah, so if you have to cut out early, that’s okay. Thanks for coming. It’s good to see you. But yeah, we’ll be talking about some of the issues here. You want to be able to automate and bootstrap these environments really quickly. You don’t want to depend too much on the platform or DevOps teams, right? Like hopefully this is going to be something that the developers can do themselves without having to open up a ticket and wait for someone else to do work for them.

One of the challenges can be that the developers aren’t necessarily going to be Kubernetes’s experts and that makes a lot of sense, right? If you think about the fact that when you’re an application developer and you get hired at a company, you’re there to build an application or a service to deliver some business value for the company, right? And that’s what you get measured on is what you deliver and maybe even how much you’re delivering, right? And there’s not a Kubernetes quiz as a part of your evaluation, right? You’re not getting judged on that. So, some developers love Kubernetes and they love to learn about it, but not everybody does. And so, you need to kind of be able to meet people at that level.

Another big challenge is the Kubernetes in development as opposed to production. There can be a very different experience and you can run into things where issues that didn’t come up in in development because things are different there and we’ll talk more about that. Then another big challenge is onboarding new team members and this is honestly, I don’t think that I’ve worked in a shop yet when I was doing operations work that really nailed onboarding developers. There’s usually a pretty painful procedure to go through to get environments running and even when people would get a new laptop, suddenly they’re having to go through all that pain again. So, what we can do to make it easy to spin people up in the first place is really important.

Guy: Yeah, and I think that I met a friend like the other day and he told me that he’s a R&D manager and he told me like, we do not hire the developers that are not eyelid knowledge, aisle little knowledge in Kubernetes and it’ll a little bit shock me. Because at some point you can aisle like five of them, but when you want to have more developers, it really doesn’t scale and you need to onboard them. Its ongoing pain like for how do you like filter them when you and how do you like onboard them like the day after. I t’s super interesting to see that the knowledge and the expertise and the onboarding are kind of a non-technical issue in this very technical industry.

Rich Burroughs: Yeah, it’s a great point. That stuff is very much about people and shared knowledge and all that, yeah.

Guy: So, let’s explain a little bit about the impact of the velocity and why do you need Kubernetes and now Kubernetes really rise as a development environment. Because we find out that as Rich explained the previous slide that you want to the production and the development to be streamlined at some way. So, some people do use docker composed but actually they want to have this Kubernetes. But why Kubernetes? Why is it so good? So first of all, you want to ask yourself like why should I have a remote environment? Because when you develop on local and Rich explain like when you onboard a new people to the team from the DevOps team from the engineering team and you need to like install some container, runner like Docker or some other tool. And then you need to make sure that they have like Docker composed or some greater under containers and then you need, if they want to develop an and which is a great benefit. Then you need to install another tool and eventually the laptop is pretty overloaded with tools they are not aware of. As a DevOps, you need to support the tool on the laptop environment and we find out the that remote environment makes a lot of sense. Because you take a lot of the complexity that you have in your laptop and you push it away to the cloud. You push it to the somewhere else that other people manage and they know how to do it like pretty efficiently.

The other thing is the unification of the platform. Like you see that people sometimes have one version of Kubernetes on their laptop, the other one on the production and when they test something or they add a new API version spec or they do something different, then there is like a non-uniform promotion step. Because in the local environment it’s one environment but in a production it’s completely different environment. So, and if they don’t have on the laptop, it even more ununified platforms to promote your images and artifacts.

Rich Burroughs: Yeah, I think that’s a great point and you definitely hear about shops where it’s very yolo when it comes to what people are doing on their laptops, right? Like they might be using even a different container run time than other people are using or whatever right? And again, it’s we don’t want developers to have to think about this stuff. We don’t want it to be artisanal Environments, that people are having to like spend a lot of time on the care and feeding of and I think this also ties back into what we were talking about Kubernetes’s expertise too, right? Again, we don’t want the developers to have to be the Kubernetes experts and like maintain these local Kubernetes environments.

Guy: Yeah, you find them like manage kind clusters or some local clusters instead of or mini cube clusters instead of like writing code. In my past role, I was a developer and I remember the day when it was not on Kubernetes. I remember the day it like to upgrade the operating system and it was too date for me to fix the environment with all the configuration and everything in place and even like downgrade some of the packages installed automatically. It was a mess. I want every time I go to my computer that the environment will be the same.

Rich Burroughs: I mean look at what happened when the M1 ships came out. Suddenly, it was like you couldn’t run some of the Kubernetes’s runtimes on your new Mac if you just bought it. So again, like there are people who do local development and that’s fine if you work out a good way to do it, if you can make it really easy and reproducible. but I think remote development makes a lot of sense with Kubernetes especially.

Guy: Yeah, and I think what’s great about Kubernetes that it’s a serve ready platform because you need to always define what you want the cluster or the environment to do for you and then you get it. Like Kubernetes does its magic and you get it. It makes it a lot more easier to bring people show them like some easy way to use it and you just define your resource API basic ones and you get everything up and running. In pre-platform, you have to write a lot of automation on your own you have to configure it yourself and Kubernetes is like I think what it brings is a lot of things but this kind of ability to actually write what you want, make it serve for the users. Just write a UI and some technology for it and then you have like a really good serve platform that actually remove the complexity for you. Because developer as we say, don’t want complexity and it brings a lot of ease of use to it and this is what I like.

Rich Burroughs: Yeah, I think that one of the great things about Kubernetes is that like a lot of these operational things that we used to have to figure out how to do on our own are just baked into the platform. And like one example I bring up a lot about this or like the liveness and readiness probes. That stuff that like people were doing health probes before Kubernetes came along but you had to figure out how to do that and build a way to do that and now all these things are like baked into the platform and that means that There’s no like legislating how they work. There’s you don’t have to agree on what. how it should work. It’s just all there. It’s part of the platform. But yeah, again we want to do whatever we can to make this really easy for developers and make it so they don’t have to think about Kubernetes too much.

So yeah, some of the things that we’re looking to do with self-service especially is we want the Devs to be independent and self-reliant. We want them to be able to do their work without having to run to the platform team all the time with problems. Having a self-served platform empowers Devs to own their own apps and to end. And developer happiness, I think this is so important and there’s more and more people talking about it which makes me happy. Because I think that people who enjoy what they’re doing, like nobody wants to be sitting around waiting for someone to do the thing in a ticket to get them access to an environment or something like that. Software engineers they want to be building stuff. That’s why they’re there, that’s why they were hired.

So, I think that it makes them happier to be able to work on what they’re supposed to work on when they need to and that happiness feeds into the quality of the of the things they build. And again, the flip side of this is the platform teams or the DevOps teams whoever is setting up this Kubernetes platform, that they have a lot to focus on and they have a lot of work to do themselves to like build these clusters and keep them running and make it a good experience. So, if they aren’t having to help people fix their local Kubernetes environments on their laptop or things like that, they’re more able to focus on the platform.

Guy: Totally. I remember Rich when you raised the Dev Happiness and it was like it’s crazy because it’s true. You want people to be happy and we don’t always think on this point like how we make our internal customers more happy. How we make our team more happy and we think a lot of the technical ways to solve things like okay we can use this tool or that tool but what will bring happiness to everyone, it’s important.

Rich Burroughs: Yeah, people use the word delight a lot which I really like that you want your tools to delight the users and I think that in the case of a platform team. Those are your users those are your customers or the developers.

Guy: Totally agreed. Totally agreed.

Rich Burroughs: So, yeah. So, we’re going to talk about both Loft and Komodor today and what they do. I work at Loft Labs. We make Loft. We really are trying to help platform teams manage their Kubernetes clusters and provide self-service access for developers. That’s really our big focus and some of the things about Loft. You can get up and running really quickly. You just type a couple commands to connect your Kubernetes cluster that already exist to Loft. It’s very self-service ready and so you can set it up so that engineers can just request their own name spaces or virtual Kubernetes clusters which we’re going to talk about and show you in the demo too. So, virtual Kubernetes cluster is basically like a name space on a shared Kubernetes cluster that has another Kubernetes cluster inside of it. It’s not the whole cluster but there’s a control plane. There’s an API server that the users connect to and it looks to them like it’s a full-blown cluster.

What these virtual clusters give you is really fast, lightweight, ephemeral clusters that the developers can use and they’re very quick to provision. They’re very quick to, you can throw them away and make a new one right away and so it gives developers access to these, to the Kubernetes clusters they need without having to wait around, so we’ve been talking about using remote environment. One of the downsides of that can be that, if you’re using your cloud providers manage Kubernetes, maybe it takes 10 or 20 minutes to provision a cluster, right? And you don’t want your developers to be waiting around that long when they’ve got something they need to do. So, these virtual clusters help with that. It just takes a few seconds to spin one up.

We also offer these reusable templates. So, we’re going to demonstrate that in the demo but you basically can kind of preconfigure these virtual clusters so they already come with things installed in them that your developers need.  We have a thing called Sleep Mode where it spins down unused workloads automatically. So, you can schedule that to work based on the clock, right? So, you can say we don’t have anyone working between midnight and 7 AM and so we’re going to put stuff to sleep then. Or you can do it based on activity too. So, it can say, hey, I haven’t gotten a request from anyone for half an hour so I’m going to spin stuff down. The nice way about it is that it’s actually done in a way that it doesn’t destroy the stuff. It’s all still there. It’s just that the containers that are running, the workloads themselves go away and so it only takes a very brief amount of time to spin it all back up. Then we do have built-in SSO integrations that are pretty standard too.

Guy: Yeah, and I think that this suite like the first time I give it a try it was amazing. Because you can use it for so many use cases for ephemeral developer environment. Also, if you want us like staging or CI environment when you want like to see a full-blown cluster in the environment it was amazing to see it for the first time for me. It was month ago and I see the improvement all the time and it’s great to see how value this kind of tools together, the virtual clusters, the reasonable environment, the sleep mode can bring together and can make users much more efficient.

Rich Burroughs: Yeah, that’s a really great point Guy. We are focused very much on development environments today that’s like the story that we’re talking about. But you can use Loft for any situation where you’re using Kubernetes the same with Komodor. Why don’t you tell us about Komodor?

Guy: Yeah, I will explain a little bit. Maybe we can talk installation first.

Rich Burroughs: Yeah, so the Loft installation, oops we lost the slides for a second. Yeah, like I said this is really quick and easy. There’re literally just a couple commands that you type to connect your cluster to Loft your already existing cluster and then once you do that you can bring in those users through SSO or set them up inside the UI and they automatically have that ability to like spin up their own name species or their own virtual clusters.

Guy: Amazing, and it’s so easy like Loft start and you got everything up and running.

Rich Burroughs: Yeah.

Guy: So, we’ll explain a little bit about Komodor. Komodor is a platform that want to eh remove eh from developer the complexity of Kubernetes operations. It means that when you have a cluster, we want to make sure that developer got everything they need in order to access the cluster troubleshoot when things go wrong and actually take actions but without the need to be experts in Kubernetes. So, we put in a lot of things to make sure developers got like tool with developer mindset, with applications, with services, with all the terms and the things that developers actually need in the day-to-day work. And make sure that they don’t need to like go to the develops, go to the SRE, ask questions that can be solved in a matter of seconds if the information was already available for them.

It’s cool because you can connect a lot of clusters together and make sure the developer can see only what they care about. Also, with the capabilities of troubleshooting and the need to switch context, you can actually go into the cluster. And when something goes wrong you do not need to initiate the QBCTL commands or go to other like dashboard with a lot of metrics and you kind of not find yourself what should you look for or which dashboard is relevant for the problem that you got in the alert. So, anytime there is a problem with trigger automated playbook that actually goes and find out what is the root cause and helps you to troubleshoot and actually find out what’s wrong with your services. What is nice is that it’s a self-serve. We are going to talk together how Loft and Komodor are great together and both of them are great self-serve options and together they are very powerful.

What we want to make sure is that developers will know how to use Kubernetes efficiently without DevOps to teach them to onboard them for a long time. And then when something goes wrong and an engineer got the alert and I think most of the cases that we see, when something goes wrong with the cluster, even if it’s was an application problem, they call to the on call DevOps. The DevOps is come to fix the problem. Which is very not efficient and this is what we want to bring in like one tool once a solution that you can just connect the classes and get everything out of the box.

Rich Burroughs: Yeah, I mean I think that point about on call people is really a good one too because I think that there’s a lot more companies nowadays that are very distributed in terms of their engineering staff, right? They might have engineers in different time zones all over the place. We’re like that for sure at Loft Labs. We’ve got people in the US, in Europe, all over. But you might not have enough SREs or DevOps people or platform teams to do a kind of follow-the-sun rotation. So, you might have engineers who are working at times where there aren’t platform team members working could potentially happen. So, anything we can do to make it easy for them to figure out their own problems is great. I didn’t know a lot about Komodor before we started working on this webinar. I think I understood it on a very high level but as we dug in, I’ve been really impressed with how easy it makes it for someone to kind of figure out what’s going on in their cluster.

Guy: Yeah, that’s great and I think that the combination between Lofton Komodor to create this everything together it really comes into place. So, let’s maybe dig a little deeper on that.

Rich Burroughs: Yeah. So yeah, so think of Loft as the thing that is going to manage the creation and life cycle of your clusters and so or of the Dev environment specifically. So again, like these on-demand name spaces or virtual clusters. We’ve got the templates that you can use to preconfigure them. You create them. You manage them. You destroy them and all of the stuff is in the hands of the engineers. You can as a platform team set some guardrail of course and you can control what’s in those templates, but you want the developers to be able to like interact with the actual environments on demand when they can.

Guy: And this is what’s great like they can create these cells of in Loft in the UI. They can create whatever they like, template the V cluster that the DevOps or SRE made for them actually get them up and running, manage, create their own application which we are going to demo. And from that Point they can access to Komodor and manage this virtual cluster that they just created and make sure that they have the alerts, the monitoring, the travel shooting capabilities and even like the UI operation that can be taken from the platform. And to make sure that they have like this full life cycle ephemeral cluster management. From the creation to how they manage the virtual cluster, how they access it in the day to day and then all the operation within the clusters. And lots will help them to manage it and put it on sleep, save resources, cut reduction, everything in one place and what is pretty nice is how those two tools are glued together. Now you can like easily click on one button and actually see it up and running.

Rich Burroughs: Yeah, in order to see that in the demo. I think the point about ephemeral environments is a really good one too, because there’s a lot of Advantages to using ephemeral dev environments as opposed to long lived environments again even on their laptop or remote whatever. You don’t want somebody to have a dev environment that they have to again give care and feeding to like patch upgrade things like that. You just want people to be able to grab an environment and use it and then throw it away if they want.

Guy: Yeah, this is what all cloud about. It’s amazing because cloud is all about ephemeral resources. I want this instance.

Rich Burroughs: Yeah.

Guy: Something is broken with it, I don’t know what, I don’t even bother to troubleshoot it, I just want to trade away and bring a new one. And when it comes to developer environment, it’s not like that. You manage the cluster; you manage everything and it’s amazing that the within the cloud is broken, but within the Dev environment there is a lot of effort and things that people need to understand and develop and make sure it’s more dynamic as the cloud itself.

Rich Burroughs: Yeah absolutely. And so, we are going to show you a demo now that Guy has put together. It’s very exciting. It’s going to show you both the Loft and the Komodor sides of this. So yeah, we’ll get up and running with that.

Guy: Let me just share my screen.

Rich Burroughs: Yeah, and again folks who are watching if you have any questions let us know. We’ll be glad to like take questions as we run through this or we have some time for a Q&A at the end as well.

Guy: Yeah, so I will explain like what we want to show you today is a demo of like two use cases. One is how DevOps or SRE can create and configure the environment using Loft how it can create the application. We are going to explain how it’s going to happen, but how it can create and make everything pre-baked for the developer and how easy it is. Then we are going to show like more developer use case when a developer actually logging into Loft and wants to bring up a new ephemeral environment with its own application in it. So, we will start with the configuration one, see how it easy is to configure those and then we will jump into the creation of those.

Rich Burroughs: Awesome.

Guy: So, let’s start with the applications. The application is like the way for us to build in our application into Loft, right Rich?

Rich Burroughs: Yeah, so you can share some standard applications and there are some that come preconfigured in Loft that you can just use. Or you can set up your own as Guy has done in this case for the demo. So, he’s added this Komodor one. Yeah.

Guy: So, yeah so what I did in here is actually I created the Komodor one using the Komodor Hound chart to make sure that each cluster that we want to make sure it’s up and running. It will have Komodor in it because we want to make sure that when the cluster started, we have the Komodor age agent runs within the cluster. But also, we added some applications in it. So, we want the clusters not only to have a Komodor in it, we want to make sure that it’s already started with some applications, some mocks. It depends on what we want in their environment. So, we some resources we call it the application deployment. It’s easy because you can configure it using Yamel’s, Hand, GitHub whatever configuration source control artifacts management tool that you’re using. Then you just put the values and it can bring in even values from the V cluster itself, which I’m going to show you later.

So, when we started, we created two apps. The Komodor one it takes three minutes to configure both Komodor and the application deployments. And what we want to do next is make sure that each one of the virtual clusters that the developers are going to spawn up in the environment is going to have the both applications. So, we are going to the virtual clusters and we will create a virtual cluster template. I’m showing like in the demo everything in the UI but obviously everything in here is infrastructure’s code. So, there are CRDs and you can configure everything using CRDs. You don’t need to go into the UI and click on the links.

Rich Burroughs: Yeah, there’s a Loft CLI as well that’s really good. One of the things that I really like about Loft is that it really is very Kubernetes native. The people who designed and built the product are Kubernetes people, right? And they did things in in Kubernetes ways. So, it’s really friendly to platform engineers who already get used to working with clusters.

Guy: Yeah, and all the terms and everything like very straightforward and like when I wanted to configure it, it took me like I think 20 minutes to see everything that we show you at the demo. So, it’s pretty easy and straight forward and you can see like how the ability to Kubernetes with everything as the Yamal’s, everything configured very easily. So, if you are speaking the Kubernetes language, it will be native for you to go in here and if you not, it will be very easy for you to create what you need. So, this is like the virtual cluster template. What it allows us is to create some virtual cluster template, then when a user creates it all the application will be baked in. We can configure what we want to call it obviously. If you want a specific version and how many you can use those. But what we want is to add our application into it. And what it’s allow us all this virtual cluster is to bootstrap a new environment with our application so we can see that we added the Komodor application and the deployment of our application in it.

Rich Burroughs: Yeah, and I really like this because anytime that you’re building these kinds of environments. There’s always going to be some bootstrapping that you need to do, right. So it’s like one thing to provision the actual cluster or the dame space or whatever and it’s another thing to get it to the point where the engineers can really use it to do what they need to get their dependency there, all of that stuff. And in the past, it’s been like shell scripts or there’s lots of different ways that you can do that, and there are some very good tools out there for doing this sort of thing too. But it’s like, we want to make this really easy. We want to make it so you don’t have to reach for an infrastructures tool as code tool to do that last little bit of configuration and bring that in the loop. So, it’s like I said, it’s really easy to just install these helm charts or these manifests and get what you need there.

Guy: What really amazed me is not only the creation which as you said like some cases about, I would call it day two but it can be like one hour later. But for example, when a new version of the application is available, so you can use Loft in order to auto sync your applications with the newer version. Maybe a newer image, a newer configuration. So, what you would have to do with shell treats, but also with terraform some other tools you have to run it all the time against your virtual cluster. But in here, you can like auto sync and the application will be with the latest version or the latest version that you want to be in.

Rich Burroughs: Yeah, because this is Kubernetes right, and we don’t need to invent a way to make sure that the state is what we want, right. Like Kubernetes knows how to do that already, so we can just leverage that.

Guy: That’s amazing. So, maybe let’s create a virtual cluster. So, I would go as, so now we like finish to configure the environment like we just configure apps, a virtual cluster template. So, now the work is done to configure the environment. What we want to do next is to create a virtual cluster itself. So, as a developer I can go in in here, go into the virtual cluster, pick the template that I want and then actually create like Guy. My cluster I know, Guy Dev cluster is a pretty like decent name, I think. We can add a description, labels if we want, but basically, we can click on create and that will start the environment. And so, now we are picking the Komodor cluster name and we start to create a V cluster and now we’d love to actually spawn on the V cluster infrastructure to make sure as Rich explained before. You would have like your own API and everything you will do initiate like Kube CDL command or any API that you’re using. It will be only on the virtual cluster. So, now it’s starting the virtual cluster and it’s going to install the Komodor agent in it but also our application. So, you can see now it’s already done to create the virtual cluster itself.

Rich Burroughs: Yeah.

Guy: It was seconds like and when you started on an environment you need to wait like for, I know how many minutes, but it’s in the fastest way 10 minutes.

Rich Burroughs: Yeah. No, it’s such a different thing because again you know you’re just leveraging a cluster that’s already provisioned right? And so, when you start these virtual clusters up. It’s literally just a pod that it’s launching inside that name space that the virtual cluster lives in and it’s super-fast.

Guy: And it’s really impressing like to have this kind of rapid base of development, rapid base of creation and it’s not only created, it’s already created with everything I need in it. Uh that’s amazing.

Rich Burroughs: Yeah, I think some people who are watching might have heard of this thing called V cluster. Which is an open-source project that that we invented at Loft Labs. It’s become very popular. It was featured in One of the Kubecon keynotes at the last Kubecon which was really exciting and that’s this is the same virtual cluster technology that’s built into Loft is what’s in that open-source project and you can kind of think of if you’re familiar with V cluster and you already think it’s cool. You can think of Loft as like your V cluster manager, right? Like the tool that lets you give developers access to these virtual clusters in a really fast and easy way.

Guy: Yeah. It’s great, I want to go through maybe show you how it looks from a Loft itself and then go deeper into Komodor.

Rich Burroughs: Yeah.

Guy: And so, we gather a cluster up and running we can see the virtual cluster up and running we can see all the name spaces that we have, the pod, the application that we installed. And if something is out of sync it will be available for us in here. With all the resources that we have, but what is cool is this new like the small icons in here when you can connect and actually connect using Kube CTL if you want. So, you can paste it into your command line and actually access directly to the cluster and also put your environment in sleep. So, it can be scheduled but also if you done for today you don’t want to spend more resources, you can click in here and make your environment go to sleep and resume it the day after and everything will be in place as the day before.

Rich Burroughs: Yeah.

Guy: So, now the virtual cluster is up and running and we want to understand what is the status of the application. So, let’s say we develop a new branch, a new feature and we really and we want to test that. So, I will show you in Komodor a little bit Rich. There anything else that we want to cover in here?

Rich Burroughs: No, I think that you’ve explained things really well. The one thing I guess that I’d mentioned is that I really liked what you did with setting up the application to install automatically. And the fact that when you launched this this new virtual cluster and you said I want to install this app, you have place where you could specify parameters so that you could pass on the name of the cluster or things like that. So, that way you could kind of match this up with what you end up seeing in Komodor, I think that’s really cool.

Guy: Yeah. So, now like we finish with the creation of the Virgil Plaster and we want to see what’s going on. So, we will go to Komodor, and, and basically, as a developer, I want to see what I owns.

Rich Burroughs: This doesn’t, this doesn’t look good Guy, you’ve got some red stuff here.

Guy: Oh, yeah.

Rich Burroughs: I think you may have broken things.

Guy: Yeah. So, what is nice is that we can see the cluster that it came from. We can see that my production cluster when I filter it in here, we got the accounts API and the user’s API which are green and healthy. But in the cluster that I just eh started eh they are unhealthy. So, let’s dig a little bit deeper and find out why is that.

Rich Burroughs: I’m glad you didn’t break production.

Guy: Yeah, not today and obviously it’s a demo, so able to create healthy production. But I would say that I like that people sometimes push things to production and they are able to get like very fast feedback on that. Because things will go into production it will happen from time to time, but obviously we want to make sure that it’s pretty fast and stable.

Rich Burroughs: Yeah, I think that there’s been a lot of talk the last few years about deployment safety and how we can use like canaries and things like that to be able to get an early look at how our new code is behaving without necessarily like with limiting the blast radius right, so that we’re not exposing a new problem to our whole fleet. And again, that ability to just kind of hop in here and get some immediate feedback I think is super cool.

Guy: It’s great and you can get it also on your slack or teams’ channel because we can configure automatically alert for these things. So, we can get immediate feedback and we have a few customers that don’t have feedback for the failed deploy. And what we meant to make sure that they get an alert and they can see immediately what fail. They don’t need to do Kube CTL get, Kube CTL described, find the right name space, find right clusters. They don’t know how to use the Komodor. So, Komodor actually when it finds out that there is a fail deploy it a playbook and this playbook actually it’s like the playbook that they on call duty sometimes I have that they need to go and do a lot of commands and find out what is the root cause. So, we put in here like the reason why it failed it can be exit call it can be out of memory and we will show you specifically that there was an application issue.

So, I’m as a developer understand what I have. The next question is what with the logs? I want to see the log, because of failure, they have a answering the log. So, it snapshots the log for me. So, I have like the exception in the stack race of it, and if we have like more logs it will be the four logs of the container. Komodor really helps you to do that, helps you to go in find out easily what problems do you have and guide you in order to solve the problem within your application. And it makes the travel union process much easier, because beforehand if they want to create their own environment, let’s say they add to bootstrap cluster or some docker composed and then they would have to deploy their application. It will take time. In Loft, they can do it in a matter of seconds. In less than a minute, we had a virtual cluster with Komodor agent and the application runs out it like in amazing in time efficiency. but then they go and find out when something failed. And obviously the reasons are changing from time to time.

So, if we deployed something wrong with the application, it will be application or an out of memory which is more femoral problem and we will also guide you on how to fix it. So, when there is a problem, when you don’t know what to do and you have an out of memory and you ask yourself okay what should I do? So, we recommend you like to change the memory and request. So, if we will increase those maybe not cheap on memory. Then Komodor will actually go into the cluster trigger the command and you will be able to see it in here and follow the deploy until it’s going to be successful. So, it creates like the full life cycle of, I deploy my environment, something is wrong, I get the answer, so why is it wrong and then follow it until it’s healthy back again.

Rich Burroughs: That’s super cool. We had a question I think Raja asked, the Komodor to the virtual clusters how the connection works. We showed that a little bit earlier in the demo, but basically with the virtual clusters in Loft you can set up these virtual cluster templates that pre-install apps that are basically there when the virtual cluster spins up. What Guy did in this demo is he created a virtual cluster template to install the Komodor agent automatically. So basically, anytime he would spin up a new virtual cluster Using that template, it would have the Komodor agent just baked right in.

Guy: Yeah. That’s a great explanation of the idea, it’s not only Komodor you can put in everything that you want and that’s what’s great about it.

Rich Burroughs: Yeah.

Guy: And so, I think we are done with the demo, I will explain a little bit that we have more capabilities around each resource that you have and we trigger like a lot of red books. So, we were specifically about developer efficiency and we find that developers like this kind of idea to see what they have in place, what they did recently, and how we can help them to fix it as fast as they can.

Rich Burroughs: Yeah, I think again that it’s, especially if you’re a or companies, you’re going to have potentially a wide range of developers, right? And some of them maybe people who love Kubernetes and know a ton of people, know a ton about it and are super comfortable going in and running Kube CTL commands and like, describing resources and looking at them and things like that. That might be stuff that they’re super comfortable doing and you may have other developers who really dislike Kubernetes and don’t want to have to run a Kube CTL command if they can avoid it. So, what I love about this kind of solution is that you’ve got a system where you know somebody who loves the CLI can use that. They can like create a new cluster and do all of that through the CLI or if they prefer to use the webinar face, they can do that. Then they’ve got a really easy way with Komodor to go in and get that information that they need about what’s going on.

Guy: Yes, and we explain specifically how they can get that and make sure everything is in fast pace and you don’t need to bother the DevOps. Anytime you have a problem with the laptop, a problem with your own environment or problem with the deployment, you can just create your own cluster and run it. We can.

Rich Burroughs: Yeah, so we got a question here from Landon. So, we have another project that we created at Loft Labs called DevSpace which is a tool for basically encoding developer workflows. So, setting up a developer workflow that’s reusable. It actually just got accepted into the CNCF as a Sandbox project. So, that just happened the other day. So, we’re really excited about that. I think that it’s going to become a lot more, bring a lot more exposure to DepSpace and a lot more people are going to use it. So, the question here is what’s the connection between Loft and DepthSpace? Use Loft to spin up a virtual cluster or whatever and then use Depth Space locally to connect to the decluster for development.

Yeah, that’s basically it. I mean, so DevSpace has, there is a Loft plugin for DevSpace that basically gives you some extra functionality. But basically, you would use DevSpace to like manage again that workflow part. So, like I want to spin up a new environment and things like that and it can kind of connect so often do that. So, they do play pretty well together, but you don’t have to use DevSpace. You could use the Loft CLI or use other ways to do that stuff. But yeah, they do play pretty well together. DevSpace was actually built first. It was built before Loft and so we definitely had that in mind when Loft was designed to like how to make them easy to use together.

Then we have a question here from Raja, is it possible to configure instant preview environments on PRs from Loft DevSpace Komodor? Yes, absolutely. You could definitely do that and so You would want to integrate probably with some sort of get ops tool. We actually just recently released an Argo integration for Loft, so that’s one way you could potentially do that.

Guy: Yeah, and I have to say that we have a few customers that are using Komodor for PR or CI environment. I think with Loft it can be even more powerful, because it will not be this namespace when you packed in everything that you have. You are able to run let’s say a virtual cluster like a full cluster of your application and make the CI much more real-life example than you have today.

Rich Burroughs: Yeah, and again we we’ve really been focusing on development environments today but I think CI is another really good use case for both of these tools. These virtual clusters especially if you’re running a pipeline that’s got a bunch of tests in it. A really big test suite, you might potentially want to create clusters, run some stuff and then throw them away right, and start from scratch again. That’s a pretty common pattern in in tests to be able to just kind of throw all your state away and start over. And again, with these virtual clusters it just takes seconds to like request a new one and get it up and running.

Well, I think that like that’s everything we wanted to cover. I really appreciate you all coming and asking questions. The video will be available if anyone like happened to pop in halfway through and you want to see the rest. But it’s been super fun to be able to share this stuff with you. I’ve really enjoyed working with you Guy and the rest of your team. And thanks so much for putting together that great demo.

Guy: Thank you very much for great honor and great joy for all of us.

Rich Burroughs: Yeah, alright, well, thanks a lot again for watching everyone.

Guy: Thank you.