Automating Your DevOps Automation

Steven Randolph
Chief Architect

We all love the time and effort savings DevOps automation brings. However, there is still a fair amount of manual lifting required to get a project and toolchain wired up and fully operational. KnowOps is a platform to automate the work required to enjoy the full benefits of DevOps automation.

Video Transcript

Thank you all for joining me today, to do this virtually, but that’s okay. Believe it or not, there was a time, when a lot of you were younger than me, I’m sure.My age will show as we talk through this certain number of the comments I make, but there was a time before there was any DevOps, and DevOps has a lot of goodness to it and if you’ve gotten used to the automation, and maybe you don’t know any better, but there was a time when there wasn’t really much automation at all.

 Before DevOps, you know, dev was dev, and ops was ops. In fact, I’m sure in a lot of companies that struggle still goes on, we can talk about it as an abstract concept. But in practicality, you know, this goes on in different levels, whether it’s a low level of maturity, or high level of maturity.

 Some of this still goes on today, sort of that wall between operations and development. And I can recall a time before DevOps, when it took us much time to just assemble, and build in sort of link, compile, execute, watch, run, fix, etc, that whole thing we’ve gotten used to with CI\CD, that chain, that tool chain that we have today, we had to build it, a lot of us did it individually, you know, sharing batch files, and cron jobs and all those things. And it was a lot of work, often as much work if not more than the actual thing we were trying to build. And I know for myself, personally, if I ever needed something from IT, a new server, new database instance, new something, something changed, they would just pretend they didn’t know what I was talking about. Right?

 They would… So it’s no wonder, you know, for some of us who didn’t know, or didn’t have DevOps, now we have DevOps, you know, it’s exciting. It really is, you know, and I, myself personally can speak to be reluctant to adopt another practice. But once I went ahead, drank a little bit of that Kool Aid, it was worth it, because all that automation that takes place is just saving me so much time and energy that honestly, I don’t find interesting anymore, right? So I know we’ve experienced firsthand the benefits that DevOps can bring, right?

 Less complexity, more simplicity, productivity, you get more things done faster. And again, delivery of features, it takes place, you know, at a speed that certainly 10, 15, 20 years ago was unheard of. But when you think about DevOps, what is it really without automation, right?

 Every component, every piece, where we see this automation that takes place, you know, if we didn’t have it, you know, what would DevOps actually be? And honestly, you know, we’ve got a lot of tools out there in the ecosystem, but it’s not really a tool chain, right? A cohesive linking of these things, until something brings them all together, right? And that’s often the work we have to do. And unfortunately, you know, to get started, it’s still some heavy lifting, you know, you can leverage, you know, an old YAML file from, you know, a private project and certain things and modify an existing Docker file to meet your needs but, you know, a lot of times the context of the project is sitting within a model, right?

 It’s within the specifications, and even though the technical pieces, we can possibly reuse portions of them, and rewrite certain things that fit our new need.

 Certainly, the specifications for this new thing we’re doing often don’t look like anything that we’ve seen before. So from our perspective, it was all about what if we could avoid that heavy lifting, right?

 The stuff that has to take place before we can actually get to the innovative stuff, the stuff that makes what we’re building different than what anybody else is out there building, right? And honestly, you can today, with Harbormaster, that’s the point of the platform, you know, to sort of bridge that gap between starting and innovation. So whether you’re creating a new application, refactor an existing one, to us, it doesn’t make any sense. Again, first time developer, I got it, you want to play around, you want to learn how to etc. but at some point, you know, you’ve done it before, you know that it’s going to work, you know cloning from GitHub is going to work, you know building a YAML file a Docker file and connecting it up to JFrog or whatever you’re doing, you know it’s going to work. It’s okay, how do we move past that? And more importantly, it’s the context in which you’re doing right?

 Your model, your application is different than anybody else’s, you know. What we’ve done is simplified, as we’ve seen in other cases, with the declarative model. Now we have a web app as well, you can drag and drop and point and click your way to generate application. But fundamentally, you know, you want to go somewhere where you can simply declare the components of what you’re trying to accomplish, right?

 Here’s my model sitting in a simple JSON file, or it could be in a YAML file, could be a UML file, could be sequel, right? You could be actually trying to refactor an existing application, it could be existing Java code sitting in a GitHub repository, you want to reverse engineer out of that, and you want to sort of present the model to the system to Harbormaster, you also want to be able to select the tech stack, right? We support, our tech stacks are constantly growing, we have a capability where you can create your own tech stacks. And these tech stacks are well defined, you know, well documented, you know, we’ve got support for Lambda, AWS, Lambda, Angular, different versions, Spring, Struts, To, Go, Django, etc, You know, that list is going to be growing. And you know, if you want to contribute to that, you know, you definitely should reach out to us for that. And, you know, again, simple things like the application name, you know, I want to select the CI\CD platform, JFrog pipelines, I want to select an artifact repository, here’s my Git credentials, and here’s where I want you to put the project, here’s my Docker credentials, and here’s how I want you to, you know, containerize, it, etc. So I’m doing it all just within a YAML file. And as you’d expect all the complexities, certainly hidden, then you allow us to take care of that within the platform. And that’s it, and in seconds, what you’re going to get is what you expect, right?

 A fully functional application, depending upon the tech stack selected, complete with a user interface, back end, storing the data, you want to have a pipeline YAML file that allows you to build and test and store the artifacts that were created during, you know, building the application, you want to be able to have them run through X ray to make sure that they you know, can pass security, have no vulnerabilities, all that’s taken care of for you, right? And once you get past that point, right? So now I have all my code to be able to create, read, update all the things that I said were in my model, I can store them, I can present them on the screen.

 Now I can get to the work that I really want to do, right? And that’s the important part, so for us say, you know, hello world is nice, appreciate it. But it’s not what I need, I need to get started further down the path closer to being able to innovate sooner and with that, you can with Harbormaster, right?

 We’re going to generate all the things to get started so that you can immediately work on the things that you know are going to lead to innovation. And thank you for the time you allowed me to spend doing this with you today.

 By all means, reach out to me, head over to the website also to do a better job of being able to provide you with more details on the platform, usage, the architecture, how you can contribute, etc.

Release Fast Or Die