You’re not compliant (but passed the audit)

Mike (00:06): But most systems, the change isn't by adding new systems. It's the change within the system that's interesting. And being able to understand and connect all the dots between the existing systems that people want to use is kind of where we want to move the conversation to. Marc (00:26): This season, Andy and Marc are back with a fantastic group of guests. Andy (00:31): I bet the depths remain classified, and Marc keeps his head in the clouds. With our combined experience in the industry, we can go from the bare metal to the boardroom. Marc (00:40): In DevOps Sauna Season 3 we will explore Platform Engineering, and the people and cultures that make it happen. Andy (00:47): Enjoy your time in the DevOps Sauna. Marc (00:58): Okay, we are back in the sauna. Do I have to say finally, Mike? It's like we've been trying to set this up for months, it feels like. Mike Long, CEO of Kosli is in the sauna today. Mike (01:12): Hi, great to meet you. Marc (01:14): All right. And as usual, I have my beloved cohort, Andy Allred. Andy (01:18): Yep. Hello. Great to be here as always. Marc (01:21): Okay. Mike, met you at The DEVOPS Conference in Copenhagen last year. And when I looked at what Kosli was doing, and when I talked with some of my colleagues, and Andy and I, it kind of feels like there's a lot going on, like some people had a FinOps kind of interpretation even. Me with software configuration management background, I thought that there's some really cool things that Kosli is doing, the compliance aspect, security is really obvious. And then I know that you are also a startup and working, I think even making an impact in DevOps culture, and even providing a data layer for DevOps. Wow, there's a lot going on there. What are you doing with Kosli? And how do you see it instead of me telling you what we see? Mike (02:11): Well, it's good you say this because ourselves as a startup, we've been on a bit of a journey figuring much of this out already. In a nutshell, what Kosli does is we record what goes on in your production environments, what systems are running, and as they change, we record those different changes. And then we connect what's happening in your development pipeline, the builds, the tests, the commits, the security scans, and so on, and make it like a big searchable graph. We started on this journey very much from a compliance angle, believing like there was a big problem to be fixed in the world. And that was around, basically, how banks change software, it typically involved a lot of things like change advisory boards, release notes, tickets, and in general, a lot of delays. Andy (02:56): The good old days. Mike (02:59): Yeah. There's so much of the industry still in that space. And going back to the DevOps story, it's like the opposite of DevOps in terms of owning the value stream, generative cultures, instilling trust, and being able to optimize the whole. And so, we had this thesis that we could really help these companies if we could just build the risk and the audit capabilities right into the pipelines. That was where we started, but after a while, we zoomed out a little bit and realized, "Okay, what is this? Is it a DevOps data lake? Is it a version control system of a sort?" In a way, what we do is provide a log of how your systems change, and we figured out, "Well, because it's content addressable storage, kind of like Git, we can diff two environments." And tell you, "Okay, you've got 15 systems in this one, 14 in this, and these are the three that are different." Long story short, we don't really know what it is yet, but it's super interesting, at least. Marc (04:00): In the pregame, we had a little discussion and you said the black boxes for software or DevOps, and I thought that was absolutely brilliant. One of the things when I got into configuration management was the promise of being able to have end-to-end traceability. And when you take end to end traceability with this kind of Git-like diff capability, man, that's cool. Mike (04:27): Yeah. And we've been circling around this problem for a long time in the DevOps world, right? Basically, our mantra since the beginners, everything is code. We start with Automator build, and then make that a script that we all share. And then we'll do NCI. Well, let's actually script our pipelines now. And then, "Okay, well, let's script our deployments. And let's script our infrastructure." So putting everything into Git, which is great. That's what enables the automation to happen. But that only stores the record, like a recipes, our expectations of what we'd like to happen, it doesn't actually record what actually happens, like what artifact that actually gets built, what shard (inaudible), what the security scan report is, when it gets deployed to which environment. And that's the rich information that we also want to capture. And that's what we're playing with now in Kosli. Andy (05:22): In regular DevOps, I can already define that I want this release to go to this environment and have these many replicas. And then the orchestration tool will read that out of Git and make it reality. And what you're adding is a record of what actually happened in reality that we can compare back to what we wanted to happen in dev, and how long it took and what kind of exceptions there were, and etc. Mike (05:47): And not just that, there's a lot of things that happen outside of the world of what you wish to be true. Those scaling events when things go up and go down, when systems crash, when somebody has KubeCTL access and deploy stuff manually. These are all things that happen, we'd really like to also be able to track that. When your system crashes, and gets redeployed, where does that information hide? And this is the big limitation with traditional change management as well. It's like they're still in the mindset of you have a big server that you redeploy to twice a year, and then there's someone actually doing something. And then there's an army of people around this big fancy system trying to keep it alive. The reality is now like you've got so much automation, our runtime systems are so autonomous. Marc (06:35): Cool. And you guys are also a startup. I know a little bit about starting a company from scratch, and the level of responsibility and pressure that we go through doing this, but you guys are really trying to do it differently, aren't you? Mike (06:52): Yeah, again, I guess part of it was really feeling that we wanted to not just talk the talk, but walk the walk. As a technical founder, I wrote the first 1000 odd qubits in the product. We were just James and I for almost two years, were figuring out what this company would be, what the product would look like working with our initial design customers. The reason how I got into DevOps in the first place, goes all the way back to university where I got bit by the Extreme Programming bug, where test-driven development was suddenly the new thing and continuous integration, a lot of these concepts that can get crystallized and I brought it with me through my career. I used them making software for a lot of robots in oil and gas industry and doing a lot of DevOps consulting as well. I thought, "Okay, I know that these things give me results. And by no means that anything I did in the beginning, work very well because as a solo founder, you don't have that pressure. Working on your own is probably the most dangerous thing to do as a technologist. But as we grew the team, got a lot of great technologists involved, we kept that going with a test-driven development, the CI, the pipelines, the automation. I think for a small team, we've got a lot of engineering practice you would hope in a high-performance tech team. That also comes with its own challenges, right? How do you make ensemble programming as you grow the team? How do you make sure that people coming into the company understand that we do test-driven development, we do pair programming, we do automation, and this is the culture you will be entering. In a lot of ways, we set the bar very high. And the other side, engineers, especially software developers, really thrive on autonomy, they want to make decisions, they want to be empowered to make decisions. And some of this can be a threat to that. Balancing these needs is an interesting problem, too. Or at least, it's an interesting navigational problem. Marc (08:56): I have a follow up about the middle of this, which was like when you talked about working with your initial customers. Can you talk a little bit about how you initially identified customer, presented the work that you were doing. How did you collaborate in the early days of the startup in order to stay on the right track? Mike (09:17): Well, I mean, we've been very lucky in the sense that from the very beginning, we've had customer feedback into our product development. Before we even formed the company, before we had any software, we showed what we wanted to build to one of the biggest banks in our region, and they liked it enough to say that, "Yes, we'll fund the initial development of this." And that, "Okay, there's some signal that there's a problem to be solved here." And they trust us to be able to move towards a solution on this which is great. The bigger the organization, the more mature they expect their software deliveries to be, which is like a good thing, but also a curse because as a startup, you want fast decisions, you want quick implementation, a lot less upfront decision making and a lot more agility. Not long into our journey, we realized that working with smaller companies, smaller Fintechs, was a great way to bring them in because they had much simpler organizations, typically smaller tech organizations, so we could easily figure out what they needed, we could get direct access to the whole engineering team, so we could get feedback from them. And bring them into our Slack communities, make sure they're part of our product roadmap decisions, understand what they care about. And then also, it's been fun going through the journey with them because our customers that we've had for a couple of years now are going to audit, the financial regulators coming by, we get the full, rich history of what they care about, which is probably the key aspect of success in any startup. Marc (10:57): There's a big difference between being compliant and passing audits. You said some of your customers are going through audits, it's like, has there been a big difference in how that audit goes for a customer that's a Kosli customer? Mike (11:18): Yeah, massive. One of our best customers, last year, they made 110,000 changes to their production environment. And just in itself being able to do that would never be possible in a traditional change process. They're able to move really fast, but they're also a really young company. They were just a couple of years into the journey when we met them. And their first audit took three months. Of course, it was the first audit going towards getting a license for payments in crypto. It was a lot of questions that needed to be answered for them to get started. But they had their follow up audit in the last quarter and it took three days. And auditors ask funny things like, "Can you give me a list of every single change to production and their associated code reviews. And that would typically take days to go through. You'd have to do a sampling with the auditor over your shoulder. But with Kosli, it's just an export and then you give it to the auditor and say, "And if you want, we can just give you access to Kosli and you can click around and navigate all this yourself." That's obviously a great sales story for us. But genuinely, these customers are great for us because going back to the earlier question about how do we involve our customers. Now this customer is involved in like a two-year innovation contract with us as we build out new features, and they're completely to the side of anything we'd ever thought about because we're very much focused on the development and the operations world tying that all together. But what they're saying is, well, actually, we've got a lot of use cases that are outside of that that we want a provable append only journal outside of our IT infrastructure to satisfy auditors. It could be things like, as an example, any financial institution, you have organization like people in the company whose job is to do compliance checks, is this person actually who they say they are, it’s called Know Your Customer. Are they credit worthy? Are they doing anything like criminal with their bank account, this kind of thing. These compliance officers have got an enormous amount of access to very sensitive personal information. And as they access this, you want a provable log of what they're accessing, so that when the auditors come by and say, "This compliance officer is very interested in this famous person's bank account, is that really for compliance issues? Or is that because they're quite interested in famous people?" Being able to have these provable logs of sensitive business processes is an area where we just wouldn't figure out that could be possible or even a problem to solve unless we were really close to our customers. Andy (14:04): You've mentioned a couple of times FinOps and whatnot. All your customers in FinOps, is that target market that you're targeting specifically? Or does it just happen to be that's who you've been talking to? Mike (14:19): Well, Fintech is interesting for us because they really have a Pants on Fire problem, which is they want to deliver software change fast, but traditionally, they've not been able to because of a compliance officer, someone in their IT risk team, change management board, there's all these organizational scar tissue built up over the years. It's a great place for us to start to figure out, but as I tended to that earlier, we want to broaden our area focus now. We think that, "Okay, we can certainly help those kinds of customers. But what about other DevOps teams that are not financial institutions? How would Kosli be interesting? Is it for an Incident Management?" Typically, like we know from the Google SRE book, 70% of system outages are due to changes in a running system. Being able to understand changes and where they came from could be a useful diagnostic in incident response. Also, from a security point of view, whether we take the lock for J incident or anything like it really, any kind of supply chain attack, typically, a lot of people are doing some scanning on their binaries, and on the Docker images before they go into production, which is great. But when a vulnerability comes through, quite often these registries or artifact management systems can see which artifacts are vulnerable. But going from there to figure out what systems do I need to patch, that's a leap, but with Kosli, if you store the S bomb, then it's a query. You look into the production environments, you get all the S bombs, and you see S log for J versus X in there, and then you've got an idea of what to do. Andy (15:59): Let's just pretend they don't know what an S bomb is. Can you explain it for our listeners who might not be familiar? Mike (16:04): Yes, sorry. That's a software bill of materials. It's a very interesting part of especially the open-source conversation right now, every software system, nearly every software system depends largely on OPEC binaries from the wider world, be the open source or not. The question is, what are the ingredients to my software system? And then, okay, do we have a standard format for that? There are standard formats emerging, like SPDX, Cyclone, but there'll be more to come, I imagine. And the idea is that if you have a software bill of materials, you can check for if you're using licenses you're not happy with, if you're using non vulnerable dependencies, that kind of thing. Andy (16:47): We had Kelsey Hightower also at the DevOps conference where we met you. And he was making the point that you would never put a CD or a USB drive into your computer and just run that in production, but everybody does exactly the same thing with GitHub. This S bomb is really a key thing for understanding what you're deploying. And I guess that ties in very nicely with how Kosli is understanding and knowing what you have in production. It's more than just a list of these are the containers or these are the EC2 instances that I have. But really, this is the software that I have running. Mike (17:26): Yeah, absolutely. And it's more than that as well. There's so many stakeholders in the software development process that getting everyone on the same page with real information is often quite a hard thing to do. I guess it’s why we have the rise of developer platforms and platform teams and platform engineering, it's like, how do we bring all the stakeholders together and give them a self-serve thing that actually works for them? Because developers care about getting their software tested and into production, that's their goal. But then you've got QA engineers who want to know what features went out in the last release. What are the code changes? You've got security teams who want to know, what assets do I have? Have they all been scanned with a security scanner? Do I have any assets that are stale? Is there a system running in our production environment live connected to the Internet that hasn't been changed in more than six months? That's a risk we need to figure out. I think that DevOps is just maturing. We had a very narrow vision of DevOps initially, Dev and Ops together. And then we brought in QA, we brought in security, we're bringing in compliance. We're just trying to bring in more and more people to work on the value stream rather than in silos. And I think that's a healthy thing. Andy (18:43): Yeah, a lot of what you've been saying just really resonates that these are problems that every customer I talked to have that what's running, when was it deployed, who has done what, all this type of stuff that every IT company needs to know. Well, every company needs to know, IT or not. Marc (19:07): Hi, it's Marc again. GitHub is the method to begin your developer experience and have a record of what you put into production. To hear more, I recommend our podcast episode on Crossplane with Victor Farsec. I'll leave a link for you in the show notes. Now back to our show. Andy (19:29): That's why I was asking earlier that you talk about your Fintech customer. I think this is something that is much more widely applicable and just want to get your perspective that are you targeting Fintech because they're the ones who need this the most? Or is there something special about Fintech that you think that's a unique angle to get in? Mike (19:49): No, I think it was very useful for us to start with. In order to be able to prove that we were building the right product and we were solving like a high value need. Every developer tool has a challenge, right? Because what you want to do is to provide it free, but you also want to be able to have a business that works. We have to solve for those two needs. And we were in the weird situation where we figured out how to sell something at a very expensive price tag, but we didn't get it in the hands of the developers whereas it's typically the other way around. Most developer tool companies start with something free or open source that people love, and that it expands. What we're working a lot on in the company is flipping that around again. Just before Christmas, we launched a free tier of our product, which, for small teams who just want to keep track of what's going on, they can use Kosli that doesn't cost them anything. And from the command line, figure out what's in prod, where their commits are, do a test stations, Dev environments, all that stuff. We're very much in exploratory mode to see where outside of finance and where outside of regulated and standards we could be interested in. As we build command line tooling, we realized that that's really a power tool for power users. And we have the web interface, which is great for figuring things out. But what we see as the real gap is around the collaboration aspects because most of the time, you want to have a conversation about what's going on in your systems, either your code or your environments or your pipelines, especially when it comes to incident and security stuff. The next part of our journey is implementing Slack integration. All the commands that you can run at the command line you can do it in a Slack channel and have a conversation around your systems, which we think as we see the trends, definitely chat is a very powerful tool in this more remote distributed working style we have. Marc (21:48): There's an interesting thing that you just triggered with me, which is that moving the conversation away from and moving the conversation to, so Kosli is moving the conversation away from some operational discussions, and it's moving the conversation then towards more value capture discussions. Would you like to use that analogy and tell us you're moving the conversation away from what and towards what for the organizations that are your customers? Mike (22:22): That's an interesting challenge. What we're trying to do is, our central thesis is that DevOps is great, but it's missing a data layer. We have all these individual point tools. We've got Git hosting providers, we've got CI platforms and pipelines, we've got security tools, we've got deployment tools, we've got cloud infrastructure, each of them has their own Data Silo, each of them has their own user interface. And typically, each of them has their own user. A lot of users are comfortable in GitHub will not be very happy in the AWS console. Folks that are really comfortable in the AWS console, probably not so happy understanding what's going on in the pipeline logs. Stitching all these different systems together into a connected graph is our central thesis. Again, a lot of the platform engineering talks about above the surface challenges like how do we connect the team side, we get them to write a Yamo file and get everything they need. That's kind of okay, maybe it's a bit tongue in cheek and simplified. But that seems to be a lot of what platform engineering is about. Can we make it simple for developers to self-serve their thing? The thing is that there's more than the developers that need to be concerned about this. And it's not just about the provisioning, it's not the day zero stuff like how do we get started? And maybe for some organizations that are spinning up a new system every week that most systems, the change isn't by adding new systems. It's the change within the system that's interesting. And being able to understand and connect all the dots between the existing systems that people want to use is where we want to move the conversation to. Marc (24:03): You remind me some discussions that I've heard from some of our customers. They've started building a data lake, but they're not exactly sure what to do with it and many people aren't exactly sure what's in there. You've solved yet another area here by unifying the data layer. I think that's really interesting. Mike (24:21): If I'm fuzzy about what the use cases are, I think that that's because we haven't really discovered them all yet. I was meeting someone who's high up in DevOps at Capital One, a few months back and Washington. And he was also building a data lake trying to build something like Kosli. He said, "This is great. I have scripts that can grep through all of our code base history, like for all of the repos and our bank. I can go through every single commit, say there's a log for J or whatever, and find out which commits have this vulnerability." Then the trick is, well, how do we get from that to the artifact? Well, we have that information. And then how do we get from that to and when, if ever it was running in production, so then we know when we have to do some network traffic analysis on because, of course, they record all of their network traffic. But when you're looking at that volume of data, you need to figure out where you're going to sample to find out if you've been breached or not. And a lot of companies don't, like the time between them actually being breached and finding out they're being breached is often quite large. It can be months and years. Figuring out how far to wind back the clock is like an interesting question. Another example is like, say, in retrospect, you find that you did a calculation around, it doesn't matter. It could be anything, but say it's around how you calculate tax for a certain product, you fix it, or it has been fixed. There was a period in the code base between this commit and that commit that had this bug in it, which database rules do I need to fix or re-evaluate? That's a hard question. But you need to know how the commits turned into artifacts, turned into periods of time that they were actually running. And then you can use that as the search criteria in your database. We still don't know, but it's fun to find it. Marc (26:19): I think you're going to have a wonderful journey finding more and more uses here. I can hardly even contain it all at the moment. But let's try a different topic for a moment. I think everything you described about the culture within Kosli is really interesting and even sounds, I'll use the word state of the art. Do you feel like you're contributing outside of Kosli towards mainstream DevOps culture or local DevOps culture? Mike (26:47): We'd like to. We're definitely open about the way we work. For instance, Evelina, one of our colleagues, she's spoken at several conferences around our ensemble ways of working, and I'm quite involved in the DevOps Days community in Scandinavia and around the world. We're trying to get out and be pretty open about what we're doing. I'm also a little bit reluctant to preach a bit too much because what works for us is what we've decided works for us, but it's not like that this is the only way. And I think what we've done is the hard way. We've done it the hard way because we can't really hire interchangeable cogs. Everybody that joins the company, especially a company our size is very small, every person you add, really changes the culture. You have to think, "Okay, how would this fit in? We've made the problem harder for ourselves." But then again, we think that by doing the hard thing, we get better results. It's a tradeoff in a lot of dimensions. Marc (27:49): I think the great thing about it, and the openness and your ways of working is it's probably quite good for your internal developer experience. And to be honest, I think it's probably very good for your customers developer experience as well. But I think that you've had some high-profile hires of late. Would you like to tell us a little bit? I think it's really exciting stuff. Mike (28:12): Well, the best thing you can be in business is lucky. Last year, we were exceptionally lucky with IT revolution, the publishing company behind GeneChem, the Phoenix Project, and lots of the most important books in our space. They published a book called Investments Unlimited, which was quite shocking for me when it came out because it's a fictional story like the Phoenix Project. And it tells the story of a small bank in America, who has been issued a MRIA, which is a matter requiring immediate attention. It's a very stern warning from the regulators that you will lose your banking license if you don't fix these things. And if you don't have a banking license, you're not really a bank anymore. And it tells the story like a bank, they've gone to a DevOps transformation, but guess what? They didn't bring in security and audit and compliance and risk into the conversation. And then it tells the usual hero's journey about how they solved all this, and a big part of the way they solved this was built in half of Kosli. This is really interesting for us because now we've got a book that we basically want the whole world to read. I can't tell you how many- Marc (29:31): Yes, I was just thinking they should have had coffee. Mike (29:35): Yes, but we've bought hundreds and hundreds of copies of this book and given them to anyone that wants to read it. If you want a copy of the book, feel free to reach out to me. I've got boxes and boxes of them. Marc (29:44): We'll leave a link for you in the show notes. Mike (29:46): Yes, please do. And it turned out that one of the authors, John Wallace was at DevOpsDays in Washington DC. When I was there, we were sponsoring the conference in September and John wouldn't mind me telling this story because he's told it a million times as well. But he proposed an open space session on Investments Unlimited. And it was quite well attended. And for those of you who don't know who John Wallace is, obviously he’s one of the authors of Investments Unlimited. But he also co-authored the DevOps Handbook together with Jean Kim. I think he's written 40 books by now. He also was a founder of Socket Plan, which is a company bought by Docker who sold the company to Dell. He was employee number nine at Chef. He's seen a few things in the DevOps space. And so, in this open space, in this room in Washington, we're talking about this and he's saying, "You need immutable attestations." And I said, "Yeah." And about half an hour into the conversation, I didn't mention Kosli once, I promise. And then he said, "And there's no tool doing any of this stuff right now." And I raised my hand and said, "It's a bit on the shelf for my product in the DevOpsDays open space, but I think we do and a bit more." And he goes, "No, you don't. I'm sick of you, vendors. You're always saying you do compliance. It's nonsense. I spoke to Splunk, I spoke to (unintelligible), none of you do it. Do you do immutable attestations?" "Yeah, we do." "Can you feel that if you don't have proof?" "Yeah." "Can you keep track of (inaudible)?" "Yeah, we do all of that." "Okay, this is maybe not the space. Can I just finish this sentence? Please, John." And he said, "Yeah, okay." I said, "I think we do all the stuff." And he goes, "Well, okay. If you do, I'll come over and I'll check you out after the space." And he came over. "Look, I'm so sorry. I'm just so sick of all these vendors telling us we do this stuff. And it's not true." I said, "Well, look come and have a look at what we've done." "That's quite interesting." So okay. "This is great. We should stay in touch." "Right. Yeah, okay, one of the authors of Investment Unlimited wants to stay in touch." And then long story short, three weeks later, we have an employment contract in front of them. And he's signing it. And it's the best thing that ever happened to us. He's a fantastic person with a fantastic track record. And just such a nice guy as well. We're extremely happy that he joined us. That was the start of then journey. The next thing that happened is that we also happen to meet Bill Bensing, another of the co-authors of Investments Unlimited at the DevOps enterprise summit in Las Vegas. And he joined us last week as our field CTO. We have two fantastic employees spearheading start of our US operation, so couldn't be happier at the moment. Marc (32:32): It's absolutely astonishing, Mike, to listen to this, I think that's a wonderful wrap up. When I looked at this, and after speaking with you a bit more now, it's like there's so much rhetoric that I have used over the years and trying to set visions for people and for companies. Being compliant is more than passing audits, audit information should be a query or an export not toil. We should have a single source of truth and maybe even a common vocabulary across the stakeholders’ silos. One of my favorites here is you're a unicorn to me already because in the investor and startup space, I would say, investors are always saying we invest in the team, not in the idea. And I always say, show me the customer, and then I'll consider to invest and you started with the customer at the very, very beginning. And I think that's absolutely astonishing. And then just the ability that Kosli has to go beyond the traceability that I have been considering my whole career of SCM. I want to know every change that has gone through the system, but being able to even take this from what's actually in production. And to do all this and actually also be in the in the culture space and be contributing it publicly, I really just have to applaud you. I think it's really astonishing work that you're doing here. Mike (34:00): Well, that's very kind. And just on the investor story, I have to say, not every investor saw the potential in us. Explaining change, management, and audit. It doesn't sound like the next Airbnb to the average investor, right? It's very niche. It doesn't sound like it's got any go to market tool. Honestly, it wasn't easy in the beginning, but eventually, we did find the right investor in Silicon Valley, actually, a company called HeavyBid. And what's super interesting about them is that they only invest in developer tools. And their partners in the fund are, one of them was the founder at Chef and an early AWS engineer. One of them was the founder of Heroku. One of them was a founder at Libretto, the observability tool. When I met them, they were the only VC that I spoke and I kissed a lot of frogs on this journey. And they definitely turned into friends. From the very beginning they understood the problem, they'd work with sock to compliance and standardization and audits and they understood the DevOps side of things. And it's been fantastic because once you get that experience behind you, like they understand what you are, where you're at, and what it takes to build a developer tool company. It's been fantastic. Marc (35:22): Thanks again, Mike, I have two more questions that we ask all of the participants on the DevOps Sauna podcast. The first one is, think back when you were a child, what was the first thing that you remember that you wanted to be when you grow up? Mike (35:39): That's easy. I wanted to fly planes. I still actually want to fly planes. Marc (35:46): Well, go fly planes, Mike. Mike (35:47): Yeah. If only I had the time. I think it's a fantastic thing. I don't know if Microsoft Flight Simulator is still around, but I still want to get into flight simulation a little bit, learn some of the basics. Marc (36:02): I think you can do that right in your living room today and get on your way. The second one is, was there a point in your life where you either crystallized that you're on the right path, or you realized that you're on the wrong path and you needed to change? Mike (36:18): That's a good question. I'm not the kind of person that has regrets. I've got no regrets for my life. But I think I've also been quite decisive in my path. I've never been afraid to quit. And every time I've done it, it turned out to be a fantastic step for me. Yeah, I can’t really name something in particular but maybe the most decisive moment in my career at least was after- We didn't really get into my background, but I was basically a technologist. I studied computer science. And for the first 10 years of my career, I worked in one company, I had positions in England, in Norway, in China. It was great. I was making all these fancy robots, doing all these fancy things. It was super high tech, greenfield, it was like engineering dreamland for me. But after 10 years, I realized that I'm either going to have my whole career in this company, or I'm going to have to make a change. Okay, now's the time, and it felt like a big step. If you've only ever known one company in your life, and then making that change can feel like a big thing, but having done it, on the other side, I ended up falling into consulting, which was great because I had 10 years at one company. And my first year of consulting, I worked with 10 companies. You don't get the same depth or leverage often, but you get such a wider view of what's out there. I think that might be my choice. Marc (37:51): Okay. Thank you very much for being with us today. Mike Long, CEO of Kosli. Mike (37:58): Thanks so much for having me. It's been great. Andy (37:59): Yep. Thanks, Mike. It's been a pleasure. Marc (38:02): Right. And once again, thank you, Andy. Andy (38:04): Thanks, Marc. Marc (38:09): Before we go, let's give our guest an opportunity to introduce themselves and tell you a little bit about who we are. Mike (38:16): Hi, I'm Mike. I'm the CEO and co-founder of Kosli. We're a developer tool startup, which builds trust in observability from commit to production. Roughly what we do is we record everything that's happening in your production environments, connect them to the events in your code pipelines, and give you a searchable record when you need it. We help around incident response, security, compliance, and just understanding what's going on. Marc (38:42): My name is Marc Dillon. I'm a lead consultant in the transformation business at Eficode. Andy (38:47): My name is Andy Allred, and I'm doing platform engineering at Eficode.