Transcript
Hi, Mike Matchett with Small World Big Data. I'm here today talking about software development and software development life cycle. Why is that important? Because it's really getting hard and complex. If you've ever tried to deploy software, even just in your own data center, you know that there's lots of knobs and levers and things you have to tune. If you've ever tried to deploy in the cloud, you know you have to wrestle with thousands of different services and get it right. And if you've ever had to try to deploy it in a hybrid environment, you've probably given up. We're going to talk to Codiac today, who's got an answer to this problem and is going to help folks with software development deployments with their SDLC tool. Hang on just a minute. Yum yum. Hey Michael, welcome to our show today. Hey, Mike, thank you so much for having me. Appreciate it. Uh, let's just start off setting the stage a little bit with, uh, software development, software development life cycle and how you, you know, how you got involved in that? You've been you've been a prominent figure in the field. What is it about software development that excites you and the release life cycle? The idea to be able to build what you want to build and how you want things to look. I think that's just cool. Programing in general is having the ability to literally make something out of nothing, which is very, very awesome. Yeah. And so what what drew you to this end of it where you're saying the, the issue that I really want to spend a lot of my life on here is getting it from development into production. What what is it about that. Yeah. So I would say the biggest issue right now is it just takes too much time for the plumbing. Right. So whether we're talking about CI, CD pipelines or we're talking about cluster management, it takes forever. You know, in my I've done everything from systems administration to software development and everything in between. And one of the biggest pain points for a lot of engineers and a lot of businesses is they have to manage a whole bunch of clusters, they have to do a whole bunch of pipelines. They have to use a ton of infrastructure as code and configuration stuff and all this YAML and all these different things, just to get an environment up and running, uh, versus just thinking about from a business perspective, really what we care about is value driven projects. And very rarely are those things value driven. Yeah. So when you talk about business and value driven about software, we're usually saying things like, oh, it's got to, you know, return for the company. So we got to get it out there. It's got to be performant or users won't use it. It's got to use less or the right number of resources. If the thing's a hog out there in cloud or cloud, costs are going to go way up. So those are the business things. Even security could be considered a business thing here. But I just want to pull you back down into technology, since we're both kind of more on the technology side. You mentioned something about infrastructure as code. I thought that The infrastructure's code was the new cool thing that the whole idea was that we didn't have to, you know, configuration files were a good thing, that we could describe our environment in YAML files, and then they become fluid. And this what what's gone wrong? Yeah. So you're absolutely right. When I c first came out when configuration and YAML and all these, all these things that developers and engineers need to use to actually get the servers and environments and stuff up and running, all this stuff was great in the beginning, but what ended up happening was everybody had to learn ten new different tools and ten new different languages to be able to do all this stuff. Plus they had to learn, you know, the infrastructure side of deploying stuff programmatically. And it just got so cumbersome because there were so many tools, there were so many vendors, there were so many different ways to do things right now that everybody had to become an expert in everything. So we we've kind of found ourselves over the past couple of years or so or several years not thinking about value driven work anymore. We just need to. We're thinking about the plumbing, putting out the fires and making sure that everything is up and running and operational. Versus thinking about what is the business need. The business needs this product out, these features out. It needs to be performant. It needs to be working as expected for the end users and for the customers. But we're now thinking about engineering from a perspective of, oh, we need to get this cluster up and we need to write this YAML. And it's kind of silly. We shouldn't be spending our time doing that. Yeah, it seems like one of the great advances of it as it marched forward over the years was this idea of removing silos between things, removing specialists, becoming everybody could become more of a generalist and, and start to take a higher level view of the things they were doing, like a business like business value that you're talking about. But then when we get into this space now, suddenly we need SREs. We need people who are specialists. Again, we need people who understand the particular syntax of that cloud provider. And we're diving back down into that almost silo building again. And that's really what went from my perspective, one of the things that could go very wrong. 100%. So exactly like you just said, we went from having to have experts in things, right? Like you had the Active Directory person or you had the exchange person or whoever. Uh, and then we got this, you know, generalization role. Well, what's happening now, believe it or not. And you can. Everybody can see this on countless tech forums, on on LinkedIn posts. The generalist role now needs to be an expert in everything. So it's not about knowing a little bit of everything anymore. It's about knowing a lot about everything. And again, if you look at everybody from recent college graduates to people that have been in their tech careers for 20 years, people are leaving engineering right now because it's just too it's too cumbersome. There's too much stuff that they have to know, there's too much stuff that they have to learn, and they're looking for different careers because between family and friends and hobbies. They don't. They simply don't have the time to learn everything anymore and be experts in everything. From a psychological perspective. None of us really can do that anyways. Um, so that piece of it is broken and that's what we're trying to fix. And yeah. And I think there's also this, this idea just to say that people getting disillusioned with engineering and development is that you put all that, all that energy into developing something new and cool, uh, as, as you said, kind of drew you into software development, but then you go to deploy it and there's another 50 things that you have to learn one time to get it deployed once, uh, and help, you know, who can help you if you got to deploy it two times or three times or redeploy it and so on, that that becomes the job and you quickly aren't doing cool things anymore. You're quickly just worried about trying to get this thing running in somebody else's cloud. Uh, which which is a, um, so before we let's let's shift gears a little bit. I think we sort of got that point across here. Uh, let's talk about Kodak. What is Kodak doing for people? What what is what is the opportunity you guys saw? And what did you start to say? Hey, we can do better. Yeah. So Kodak pretty much marries the SDLC process with the DevOps process with the platform engineering process. So what do we want to do is we want to make the entire life cycle of what you do day to day easier. We want to be able to reinvent the way you're thinking about pipelines and IAC and YAML and configuration language, all that stuff. And what I mean by Reinvent is completely remove it from the table and simply focus on, here's my piece of software. I need to be able to get it out and deployed and get users using it. That's all I should care about that value driven work that we were talking about before. We're 100% ensuring that what you do every day, day in and day out, 100% of your time is value driven work. No more managing clusters and this node and this resource thing and scaling this up and worrying about these languages and all that, nothing. None of it. We're going to give you the ability to take your software, deploy it to wherever you want it to go. You don't have to worry about the underlying platform like the infrastructure and stuff that's that's managed by Codiac in your environment. But everything's done via Codiac, so you don't have to worry about the underlying infrastructure. It's really just a matter of getting your applications deployed effectively. So, so literally, instead of going and making configuration files and versioning those and modifying those and having 50 different files to deploy something, I'm going to drag and drop an app over onto a, onto a cluster. Is it. Yeah. Yeah. Well I'm glad we got that. We got that cleared up. Yeah I mean as simple as that. It. Yeah. So tell me so so what does that enable really I mean obviously we eliminate a lot of time with all those intermediate little underlying tasks. But does that mean people can take advantage of multiple clouds? Does that mean people can do blue green deployments easier and faster? What does that what does that really give them? 1,000%. All that. I'll even take it a step further and say your clusters can now be thought about as blue, green or canary. So I can have multiple clusters running in different. What we call cabinets are kind of like namespaces. And you can just move your applications from one to another. The configurations move with it and that's it. And you don't want to spend the money on the cluster that's not running well. You use zombie mode, which is a feature in Codiac, and you just shut it down. Full zero nodes, full zero pods. You're not spending money on the cluster, but when you need it, you just take off that feature. Then the cluster comes up and then you just move your configurations around and that's it. It's it's very simple. So the overall goal is again like these clusters are ephemeral, right? They're they're disposable. The infrastructure, it's there. I'm not going to I'm not going to sit here and tell you you don't need infrastructure because you obviously do. You need somewhere to run it. Uh, but you as the engineer, do not have to manage it anymore. Now, this also opens up doors for everybody in your organization, the engineer. It makes them easier to deploy it. The product owner, they can log into the Codiac UI, see what's deployed, see the versioning. Maybe make sure that matches up with their JIRA ticket or whatever ticketing system they're using. And they know what's done and what's not done. Even take it a step further and say if you wanted to give the product owner their own environment to drag and drop, to test stuff out, to see if it works, they can do that as well. And then the managers can also log into Codiac, see what's deployed, see what's not, see if environments are down, whatever they need to do. So we can literally give everybody from the engineer to the product person to the management person or the leader person full rein to understanding their entire environment from the value driven perspective. They don't have to go in and look at their cluster and see this is deployed and in this cloud and that's deployed. None of that actually really matters. The thing that matters is getting the software out there and making sure that it's performing as good as possible. Right, right. So I can just see, you know, having been a former product marketing manager, semi product owner, going in there and dragging and dropping my app to a new a new deployment and going, oh, I didn't test. I'm going to promote that to test two or promote that, to develop to development one and just and it's done. I don't have to go edit any configuration files. I don't have to work with the SRE to do that. I don't even have to know whether I'm working cluster one. It's in Amazon and Cluster two somewhere in some other cloud that that happened. It's just it's just going to go I mean I like that I think you've really virtualizing that and abstracting that layer of complexity away and encapsulating it. And that's that's awesome. So I'm sure we're going to we're going to hear more good things about Codiac coming up. I wish we could actually do a demo and get deeper dive into this, Michael, because I think proof is in the pudding sometimes. But if someone wants to see it themselves and touch it and say, like, what are you guys talking about? What would you have them do? Yeah. So if you go to Codiac.io, there's a free button you'll see there. You can literally use it for free. No credit card, no nothing. Just yeah, you can just sign up and use it for free. Uh, you don't need a business email. Nothing like that. There's no gatekeepers, no salespeople. Just literally go in and give it a shot. And if you have any questions about it or if you need any help from anybody, uh, just feel free to reach out to me on LinkedIn. All right? That's Codiak.io with the see Codiac.io. Thank you, Michael, for being here today. That was great. This is a great advancement in what's going on in software development. Thanks. Thank you so much. All right. Take care folks.
