Security Unfiltered

From Physics to Platform Engineering: Revolutionizing DevOps and Tackling Cloud Security

March 04, 2024 Joe South Episode 145
Security Unfiltered
From Physics to Platform Engineering: Revolutionizing DevOps and Tackling Cloud Security
Security Unfiltered
Help us continue making great content for listeners everywhere.
Starting at $3/month
Support
Show Notes Transcript Chapter Markers

Embark on a journey through the labyrinth of cloud security with us as we welcome Corey O’Daniel, whose unexpected path from physics to DevOps offers a fresh perspective on the industry's complexities. The tech world is brimming with new products, leaving security professionals wrestling with integration and management within their existing security stacks. Corey O’Daniel and I discuss the evolution of the cloud, sharing our thoughts on streamlining services to lighten the load on developers. Our conversation spans the importance of simplifying cloud services, making them user-friendly and secure by default, and the need to encourage developers to weave security into their plethora of responsibilities.
 
 The second leg of our adventure with Corey O’Daniel unveils his serendipitous foray into technology, from data entry automation to HIPAA compliance sage. He sheds light on the acute talent gap in operations and security, a challenge that spurred the creation of his brainchild, Asdriver. We dissect the trials of scaling startups, the high turnover in tech roles, and the insatiable need for skilled professionals in this era of cloud migration. This dialogue isn't just about the challenges – it's a treasure trove of valuable insights for anyone navigating the startup landscape or considering a career pivot into the tech scene.
 
 Finally, we tackle the buzzword-infused terrain of the DevOps industry and the elusive quest for authentic DevOps practices. Platform engineering emerges as a beacon of hope, aiming to equip developers with self-service cloud infrastructure tools, and we illuminate how Corey O’Daniel's latest venture, MassDriver, is set to revolutionize the DevOps space. By blending architectural thinking with software design, Corey O’Daniel is on a mission to demystify CI pipelines and empower developers. Tune in for an episode that's not just an exchange of expertise but a wellspring of innovative solutions for the tech industry's rapid evolution.

Support the Show.

Affiliate Links:
NordVPN: https://go.nordvpn.net/aff_c?offer_id=15&aff_id=87753&url_id=902


Follow the Podcast on Social Media!
Instagram: https://www.instagram.com/secunfpodcast/
Twitter: https://twitter.com/SecUnfPodcast
Patreon: https://www.patreon.com/SecurityUnfilteredPodcast
YouTube: https://www.youtube.com/@securityunfilteredpodcast
TikTok: Not today China! Not today

Speaker 1:

I was going. Corey, it's great to get you back on the podcast. You know we we originally planned this thing for several months ago but, you know, with the craziness of all the conferences at the end of the year and whatnot, it didn't work out. But I'm glad that I could finally get you on.

Speaker 2:

Yeah, I'm happy to be here. Yeah, sorry about that. Yeah, I think I think things got a little away from us at reinvented it. It ended up. I mean it's a crazy conference all in, but like we, we just we were overwhelmed the entire time there by attention. So, yeah, kind of, oh, we got away from us.

Speaker 1:

It's definitely a good thing, right? I mean, especially you know when you're when you're coming out with a new product. You know, I feel like the security field sees like 50 new products every year. You know, and it's like for a security professional that's in the field looking for you know up to your products in each category for their company. You know it's it's sometimes hard to weed through all those weeds and find the hidden gem. I guess.

Speaker 2:

Definitely. I mean it definitely is. I mean I feel like walking around reinvent, like the number of tools that like overlapped and overlap partially and overlap with like other tools. It's like how many? Like how many do I need? I feel like. I feel like it's sort of the painful things and like the security and ops space and dev ops space in general, like there's so many tools for things now, like how do I, how do I glue them all together and, like I don't know, get peace of mind.

Speaker 1:

Yeah, it's. You know it's kind of frustrating, to be honest, because it's like you know, these tools are kind of coming out of nowhere and they're you know they're they're focusing on niches, niches that you know might already be handled right by another solution. And, yeah, they may do it a little bit better. But it's like, well, why do I have to? Why do I have to add something to my security stack, right, like that's one more headache, that's one more tool that I have to manage, that's one more, you know, set of findings that I'm going to be reporting to my developers and engineers that you know, like you, with how the cloud is going right now, you know it's almost like you need a development team that is only focused on findings right in your cloud, because you know I'm dealing with it right now, right at my day job.

Speaker 1:

I have probably a hundred developers that I work with spread out across, you know, maybe 10 or 15 teams, and to get them to spend the time on, you know, actively or proactively right, resolving these findings and whatnot is insane, like it's. It's so difficult to do that, you know, like we've we have threatened people, we have provided, you know, food to people and beer to people. It's like what do we need to do at this point, because I'm used to my bribes working, but it seems like they're not.

Speaker 2:

Yeah, I mean, I think it's just honestly. I think developers have, I think all of us developers in particular have just too much stuff to pay attention to, right? I mean, I think it's funny when you look at the cloud and like where it was in like 2005. So I've been in AWS since they first launched EC2, but like when we first moved to the cloud, like there was, like there was two services in AWS. There was like SQS and EC2, I think, right, I think they had their classic VPC, but like the cloud was simple, like there was like, oh, I can run a workload and I can queue things. Like this is great. Maybe I had to put Postgres in an EC2 instance myself, but like right, there wasn't much there. But like where we've ended up is 200 AWS services and then there's all the services in between that you don't care about, that are important KMS, iam, like all this stuff, right.

Speaker 1:

And so as a developer.

Speaker 2:

You know you might be writing a service and go, well, you might be consuming like five AWS services Like SNS. You got SQS, I got SES, I got RDS, you got S3, like I've got all these like cloud things that I'm starting to use. And like now you got bloat Terraform. I got to figure out OPA. Like there's just so much tooling, I think, in the way of trying to build a feature to make company money right. And I think that we never, as an industry, like slowed down and dealt with that Like we just did little tiny patches here and there we're like oh, the problem is like infrastructure is not declarative. Everybody will just write Terraform. It's like okay, like it's still developers spending a lot of time focusing on things besides building your products right. And we never made the cloud easy again. Like it was easy and then it became capable and now it's very capable but very hard.

Speaker 1:

Yeah, yeah that's a good point. Oh sorry, I didn't mean to cut you off.

Speaker 2:

Oh no. So I was thinking like I think like what the cloud needs to do or teams internally need to be doing is like figuring out how to like lower that service area. Right, like we say cognitive load all the time, but like what does that mean? It's like less tools, but also like takes over the configuration options away. Like why do databases have the option to turn off encryption? Now it is.

Speaker 1:

Yeah right, why is that a thing Like no one?

Speaker 2:

Yeah, why is it a field for a developer to hover their mouse over and go? Should I turn it on? Yes, you should turn it on. Should you turn it off? Should be the question. Why is it? Why is it even there?

Speaker 1:

Right.

Speaker 2:

Yeah, I don't know the surface area of the cloud, though it's gotten. It's gotten too big and I think it's it's hard. It's hard to keep in people's heads.

Speaker 1:

Yeah, it's, you know, several years ago I, I took and passed the AWS security specialist certification, right it's. You know AWS is hardest security cert. You know you really have to know your stuff inside and out and this past year, you know, I had to retake it or re re-upper, you know, re-certify it. And you know I, I did some very light study, very light, I figured. You know I've been in AWS, you know, for 10 years, right, like it shouldn't be that crazy, right, and I get into this exam and they're asking me about all of these. You know, kind of my new one-off services, that you know it's like cloud formation, you know whatever it is right, cloud formation, like build or whatever the new tool is, and I know what cloud formation is. But then these other like subcategories of it, well, I don't know. You know I guess I should have studied more, you know. But that just goes to show you how much is changing. You know, and I think last year what was it like, 25 new services were introduced into AWS and that's just AWS.

Speaker 1:

You know, I used to work for a company that was in AWS, azure and GCP, right, and I had to tell them like, hey, you know, typically like this is managed by three different teams, right, and the reason is that it's three different languages, right, azure doesn't have the vocabulary of EC2 in Azure, you know, you need to know that that's, you know, a VM or whatever, it is right. Same thing in GCP, and I'm on a team of two, including myself, right, and it's a mess. You know, like, how do you, how do you even, like, get started with that? How do you even, you know, wrap your hands around? You know what's going on in the environment where it's going on, what's talking to what? You know? All that sort of stuff, right? And you know, at the end of the day, now I'm interviewing, you know, 100 devs trying to find out how their app works, to be to be like, oh okay, this is the place I need to look, or, oh, this repository is actually important.

Speaker 2:

Yeah, dude, the repository, I feel like it's so funny, like I feel like a lot of a lot of companies, the repository sprawl. The repository sprawl when you start doing things well is funny as well. Like this whole, like ah, should things be monolithic? Repos or like repos for everything is like, once you're at scale like outside of Google, like Google does a lot to build the tooling to make like the Google monolith, feel like a monolith or feel not like a monolith, sorry, but like for the rest of us. It's like, dude, there's so much stuff. It's like where do you put your OPA rules? Is it with the application? Is it with the security teams repo. Is it with the fines teams repo.

Speaker 2:

Like what about Terraform? Like who like, Terraform gets complicated, Like there's some Terraform for the network which we all share and that's maybe owned by the networking team.

Speaker 2:

There's some Terraform for Kubernetes cluster, or maybe your team owns their Kubernetes clusters. Like where do you start putting all this stuff? And like how do you organize and find it Right? So, like I feel like that's so hard and like coming on as a dev to a team that maybe is established and has like really good practices in place. I'm sure I'm curious who you are, because the status CD report, door report this year said that it's none of us Like you come in day one, you're like okay, I want to deploy some new cloud resource.

Speaker 2:

How do I do it here? Right, I feel like we've gotten to the point at least with, like you know things like Kubernetes. Like you can have like a. If you go into a company that has Kubernetes like, it's like oh, I know, I can put my thing in a container and I can use the I did this at the last job. My knowledge is portable and how to operate that thing. But when it gets to managing resources in the cloud, I feel like we're very bespoke still. Like you get to one company, they have a giant Terraform repo. You get to another company, they have a hundred Terraform repos because they're another company. Everybody keeps their cloud resources alongside their applications. We do it so differently, and all of it seems a bit app-hazard.

Speaker 1:

Yeah, that's a good point. You know like now I feel like changing companies previously was a whole lot easier than it is today. You know because you can use, even if the company that you're jumping to is in the same cloud as your previous company. You know you can use these clouds in such you know, significantly different ways that it'll take you two or three years just to figure out. You know what everything is and where everything is, what it all does. It's not as cut and dry as it once was.

Speaker 2:

Yeah, dude, in those in those lucid charts they're all lies. Like you come in, you're like oh, I found the directory of lucid charts Awesome. I understand stuff now. And then, like you get a troubleshoot something. So it's like oh, we haven't dated those in like nine months, yeah, yeah.

Speaker 1:

Right, yeah, I can't even count the amount of times that I've had to, you know, find what team owns what. And you know you go to one place and they direct you to one resource. And you go to another person and they're like, oh, that's, that's a terrible. You know, roster, that's a terrible directory. Like, use this thing over here. And you know you're getting directed all over the place just for simple information, because these, you know, these configurations, the ownerships are changing so often. But, corey, you know we kind of just jumped into things without hearing your background, you know. So why don't we, why don't we dive into your background a little bit? You know, talk to us about how, you know, you went down this path of getting into IT or getting into security. You know what made you want to go down it. Did you, you know, look at it and have an interest in it? Did you look at it from a? You know what's going to future, proof my career, so to speak, and dive into it from there? You know how did that look for you.

Speaker 2:

Yeah, honestly, like a lot of things in my life I've stumbled backwards into, so just stumbled straight back into it. So my original major was physics and architecture, and so I happened to be working at a hospital at the time and I wrote software for fun who doesn't write software for fun? And I did data entry and so my job was very, very, very, very, very, very boring. And what I noticed was they're printing up these sheets every day. Everything was consistent. And then I would kind of type some data into this app. And so I wrote a tool that would take data. If somebody just brought it down to me on a disc get instead of printing it, and it would take it and it would put it into this like terminal system that we had. So I pretty much automated away my first job and I'd just been writing software, you know, for fun as a kid, and that's that's. That's the extent of my software knowledge at this point in time. And so the company had. I never signed a PIA form, nobody owned the rights to my software. I wrote it at home. It was mine, like I'd automated my job, and they wanted to buy it from me. So they offered me a thing was $1,000 for the rights to my software and a promotion to the help desk team and I was going to be making nine bucks an hour. I was in college. I was like, dude, a thousand bucks and $9 an hour, like yeah, you can have my software. So, like that's how I got into eventually, operations. So I was working at this, working at this hospital, working on the help desk team, ended up on the networking team, so working in the data center, and at that point in time there was still a major in physics and architecture and I switched my majors to healthcare information systems and start.

Speaker 2:

It was right around the time like HIPAA was taking off, and so it's like you know what? Like I'm already in hospitals I've worked in two hospitals back and back really kind of enjoy working with computers, so I'm going to become a HIPAA security and compliance expert, and so that's kind of what I focused on. Now what I didn't realize was those sweet budgets that I had my first few years. You don't get those sweet budgets every year. You don't just get. You don't just get piles of cash to buy new servers and buy Wi-Fi. Like Wi-Fi was rolling out at the time. I was like, well, this is cool, I don't have to run cat five anymore or four or whatever you want at the time. And so after a few years of, like you know, building out a pretty awesome data center, a couple new hospitals and surgery centers, got to the point where I was just in like maintenance mode and risk slapping mode You've violated HIPAA, thing, you're in trouble.

Speaker 2:

And so I just kind of stumbled backwards into a job offer in Los Angeles, california, working for a startup. And so I came out here in early 2004, 2005. I've been working in centers. I get a job as a software engineer at this like digital signage company. This is before iPhone. So like people are standing around in Starbucks with nothing to do besides wait. And so we put these big TVs in and we just blast you with ads and like sports course and stuff.

Speaker 2:

And so about a month or two into my job there, my boss walks in and he goes used to work in a data center, right, and I'm like yeah, he's like cool. He's like AWS launched this cloud service thing. We're gonna our data center leases expire, we're gonna move all of our stuff to the AWS or to Amazon. He called it Amazon cloud and I was just like the bookstore. Like what are you talking about? And the reason he picked me of all people is of the entire company and there's like 40, 50 engineers. I was the only person that had experienced writing software and working in a data center. Like we had ops people, we had developers and so like I was the like I was just I was our first DevOps engineer like 2004,. I just kind of got pigeonholed into this and I've just kind of done it since, so founded a couple of startups back to back from there, had worked kind of in e-commerce and affiliate world for quite a while the real, real, honest company, a couple of other products in there.

Speaker 2:

And then about 2018 or so, I got into like large scale professional services, so like migrating multi-billion dollar companies to the cloud. And what was really interesting was I started to see this like continuing trend, and that was when I was at startups. It felt like it was really hard to get operations and security full. Find people that you had the experience and were developers were just finding people that I could attract to my startup. Right, like I have a startup, I can pay you 90 grand a year. It's amazing. I can go to Google and make quarter million a year. It's like okay, well, good luck, right. Like nobody wanted to work for like one of these small companies. And then when I got to these big companies or moving, moving to the cloud, they had the same problem. I just assume you know multi-billion dollar company people are just throwing the resumes at you but you're seeing these companies like post an ops role or a DevOps role and the seats sit open for two, three months before they place the role, and turnovers on average every 18 months. So, like you know, it's just like a rotating door and you end up in this place where nobody really knows the state of the system, and so that's kind of where you know.

Speaker 2:

I kind of got an idea that there was, might be, a product in this space, and that's where I kind of originally got the idea from Asdriver.

Speaker 2:

And then went out and did a ton of research, ton of user interviews and just found that like companies are struggling with this, like we don't have enough operations and security talent on the planet to support the workloads that we're slowly moving to. All right, we have 27 million software developers on this planet. By 20, it's like by 2036, one in 100 US citizens will be a software developer. That's nuts. Like there's gonna be more software. Yeah, we'll be the eighth highest growing, but this is the Department of Bureau and Labor's dissent with the eighth highest growing industry of everything, where we'll be outpacing waitresses, doctors, nurses, lawyers, but like there's got a ton of software developers but nobody's teaching people, put stuff in the cloud, like we don't teach it in universities, we don't teach it in boot camps, it's on the job training or on the weekend training, right. And so like what do we do? Right, we've ended up in a place where it's like less than five to 6% of developers have security and operations experience. Guess what.

Speaker 2:

All of our stuff requires to be operated somewhere in a data center on the cloud. God, I hope it's all secure, but it's probably not. That's where we started working on Master. The goal was really to make it where developers could really feel like they have the ability to manage what they need in the cloud. Just get what they need.

Speaker 2:

At the end of the day, where this abstraction layer sits in front of AWS, gcp, azure, etc. What you're getting is you're getting this nice gooey interface that feels like you're diagramming, but as you diagram it's actually pulling your Terraform modules, opa. It's pulling all of your operations and security team stuff that they put in place. You don't have to think about ops tools as a dev. You think about what you want, you think about the layout of it. Save it.

Speaker 2:

Now your ops team they just write Terraform, they write Ansible, they write the tools that they know and they've given you self-service. They've given you enough to move forward quickly. But you've got audit trails, metrics, costs all in one place where you, as an ops person, can understand what they're running. You can actually see their alerts and the change histories and all this stuff. It gives you one place to go to troubleshoot, one place to go to manage your infrastructure and neither team has to learn new tools. We're trying to help bridge that gap, like get more out of your operations team scale those folks up. Yeah, that's where we are today. I'm the CEO and co-founder of that about nine folks today. Yeah, that's my history in a nutshell.

Speaker 1:

You mentioned you were getting your degree in physics and architecture.

Speaker 2:

Yeah.

Speaker 1:

Right, that's no small feat right there. When I was in college I had the great idea of trying to go pre-med right from the beginning, right? Some like astrophysics class and it was just talking about planets and calculating different things with planets. Why not? I got that. I understood that I ace that class. That class was actually really easy for me. I think it was like physics 112 or something like that. I was required to go down to physics 105. That was the lowest physics class that my university offered. I was like, well, surely if I did find in physics 112, how hard can this class be? Somehow I forgot that I'm not that great at word problems and physics is nothing but word problems. Well, after trying the class twice, I failed at both times. I'm like, okay, maybe this whole pre-med thing isn't for me.

Speaker 1:

At the same time, while I was failing that, I had a friend that was also in architecture. He also went down the same path of. He would be good at times, but then the cost of materials to actually stay in the program and actually do the work and whatnot was like starting to outweigh the cost of the actual program. He switched and he went pre-med and it worked out for him, of course. But can you look back and identify different skills or things that you learned during that period that maybe helps you and benefits you now, because those are very analytical degrees. You have to be able to tear apart a problem piece by piece, put it back together in reverse and figure out what's going on there. Do you think that those skills help you today?

Speaker 2:

I think they do and I would say that probably have a little bit of this yourself. I think a lot of software. This might be weird to hear, but we call it computer science. It is for some people I'm sure your people writing some C and building the database and thinking about algorithms. It's very computer science to you, but for most of us it is a word problem. We're tools. Software developers are tools. There's business people who have an idea of how to make money and they need to automate all this stuff, but they don't know how to do it. We're their interface to computers. They talk to us about what they need and we have to take all that and interpret it, figure out how to make that software. That is the real job of a software engineer, in my opinion. I think physics helped a bit with that. I think the skill that I think going to something like Jesus I'm drawing a blank here on what it's called like philosophy and study of logic Might even be really applicable there.

Speaker 2:

But I think the most I got from my physics program was good advice from the dean, and that was to leave the physics program. I pretty much told him what I wanted to do with my life. I was like, look, I want to build something great. I want to build something that I'm proud of. I definitely want to be rich from it at some point in time. And he's like you're realistically going to be a professor and make no money. I was like, well, shit, I got to get out of here Because I had these hopes and dreams. I'm like I'm going to build space habitats. That's what I really wanted to do. Like wait, we didn't have SpaceX then, like we weren't going anywhere near the moon, but that's what I wanted to do.

Speaker 2:

Then from my architecture, I think the thing that's really beneficial from architecture is just that extremely important A physics and understanding the load of buildings and how much different resources can hold. Being able to think through that. Doing the math on it is one thing, but being able to think through the nitty gritty details is another right. So it's like you can put you know, you can put like a big I bar up or maybe even some like LVL beams up to hold up a wall, right, but there's multiple things you have to think about, right, you have to think about holding up the wall, holding up the floor, and then you also have to think about, like, what is the person's experience in this building? Right, because holding up the wall isn't just the only goal of these wall, like of the wall, they're sorry, holding up the roof isn't the only goal of these walls. It's also to, like, provide shelter, hang entertainment, give you a view outside the window. So, like, you have to think through things in multiple degrees pretty heavily, and every time you make a change to one of those, it changes the rest of it, right? Like, oh, we make the wall taller or lower to be able to accommodate this other thing on this other floor? Well, that affects the people downstairs, right?

Speaker 2:

So I think, like, just that, like full circle of like, always building, designing and then assessing how it impacts everything else, I think is one of the things that made me Probably a better engineer, but I can see where that surface is. In me particular, I'm a full-on test-driven development engineer. I cannot, to this day, work on anything unless I have a set of rigorous tests in front of me that I can actually get that tight little feedback loop. That's what I'm looking for always, and all my development is I have this theory. This is how the walls are going to stand up. This is what the experience is going to be like inside of this room Build it doesn't hold the load oh, can't look out the window. Iterate, iterate, iterate. I think that's probably the most I got out of architecture. Physics was really just I don't know. It's a bunch of hard math and like one percent of the people actually getting to a place where it's actually rewarding and everybody else is just professors. Sorry, there's new physics listeners, but you're probably a professor and not listening to this.

Speaker 1:

Yeah, that's a really good point. It's just interesting where our paths take us. Again, in high school, I took AP physics in high school, aced it, and this other person sat right across the room for me. He really struggled with it. He got like a D on a good day. We get to college and he's majoring in physics and he's getting his PhD. Like actually doing real things, going and doing research and some pretty awesome labs across the country. We met up years after high school and I'm like man, the difference that occurred between us like now I can't do physics to save my life, and now you're getting your PhD, you're doing research, you're changing the whole field in this area. It's just interesting to see how that played out.

Speaker 2:

Was it the failure, though, that ignited? Is he a person that just chases success, because I can see that you get you do it. You're like fuck, I suck at this. How do I become better at it? I just got to double down on it.

Speaker 1:

I think so. Yeah, I think that that was a part of it. It's interesting because I'm like that too with some areas, but when it came to like physics and chemistry, it was different for me because it was just like man, I don't think that this is for me, right? Because even when I retook, like chemistry, you know and I was actually doing really good in it the second time around I was not excited to open the chemistry book and study. I was not excited to go to class and take this test. You know, I mean, I guess you're never going to be excited to do that stuff, but it was like a real struggle for me, right? And so, like I knew, like okay, this probably isn't for me, I'm going to stop, like you know, trying to go against the grain here and figure something else out, you know.

Speaker 2:

Yeah, it's funny, like architecture was like I saw them. You know how I got into it was I was just very good at math as a kid. It's funny because I think my last math class that I took may have been in sophomore year, college. So I finished most of my math and physics for a four year degree while I was in high school, while I was doing Calc 3 and like in seventh grade or something like that. So I was really good at math. I'm still pretty good at it.

Speaker 2:

I don't like it. I don't find it to be interesting and maybe it's because I'm good at it Just like, oh, this is boring to me. Like I would much rather like talk through problems and work through like the wordiness of it. But to me, like why I got into physics originally was this just seemed, oh, this is I'm good at this thing. Like I'll just go and do it. It's the easy, it's the easy path.

Speaker 2:

And what I discovered, like when I was in school, is actually like architecture. I love architecture. I'm actually covered in architecture tattoos to date, like, but I never, never majored in it, and so I've actually like seeked that in my life. So I've spent a lot of time doing volunteer archaeological digs. So it's like I want to go spend time in this temple here, like helping them work on it, just so I can be in like these old buildings that are built. And so I finally got to surface that like desire.

Speaker 2:

About three or four years ago my wife and I bought a dump and so we were stripped it to the studs and did like a full, like mid century, mid century modern, like rebuild of the house, and that was super fun. So it's like I think in retrospect, like leaving that industry, like I don't know if I would have loved it day in, day out, but I did really enjoy doing my house. But I'm also kind of glad that it's done. And my, my dean of the architecture program also said that I would realistically be building strip malls and and not space habitats, which he's probably correct.

Speaker 1:

Yeah, so I guess you probably found you know like a passion for you to do something with it on the side and not have the pressure of a career you know, of having to do it every single day. You can kind of dabble and get your fix and then go from there.

Speaker 2:

Yeah, yeah, and I can go and go inside whenever I want to do a little. Do a little architecture and interior design. Yeah, the nice thing is I'm actually not a aesthetically skilled person whatsoever, so like I was never good at that part, like I can do the math on, like the load for this beam, but like every time I designed something it kind of looked like crap. The house looks good, though that's because my wife did that part.

Speaker 1:

Yeah, well, that's what matters. Yeah, my, we, we built our house and my wife chose, you know, 99 percent of the house and everyone, like always, loves our house and whatnot. And they're like, oh, who chose this? And like she chose everything. Like I gave her the budget, I was like this is a hard budget, you stay within it no matter what. And she figured out the rest, you know, but you know it's it's. It's just interesting, you know to me where, where, like, our paths take us. You know.

Speaker 1:

So, when you're, when you were finishing up school, did you ever have that inkling that you would start a company? And you know, figure it out from there? I asked that because you know starting a company is not a small feat, you know, especially to be successful, right, like you know, I feel like personally, right, I'm not successful in starting a company. Like I have a company, I've LSE, right, that I do all this side work through and everything like that, but I'm not, I'm not like insanely successful with it. Right, I don't even know that side of it. Like, I feel like I need someone to be like, no, this is where you click, joe. Like you know, this is what you do. Like, how did you build that desire to do that and how did you reinforce it? Was there something that you learned or a place that you went to learn that skill set?

Speaker 2:

I think that you know, the first time I, the first time I did a startup, was again like I've stumbled backwards and do a lot of stuff. And so the first time I did a startup, I was not looking to start a business, I was. I was working at a company. They had layoffs. I wasn't laid off, but if you're looking for a company, you know I wasn't laid off, but it pissed me off that they laid off all my friends. And so I was like I'm going to go to find a new job and I just I stumbled across a guy that had an idea for a business and he's like I'm looking for a co-founder. I'm like I don't really know what that entails, but I can write software, so let's do it. And so that's how I got into my first startup and I was just like, oh my, oh, this is crazy.

Speaker 1:

Like there's literally nothing here.

Speaker 2:

I have to do everything Like I always joined a job where like stuff was already in play. I was joining a team or project and so that was rough, like went through fundraising, like went through all that stuff. And I think that what's interesting about it is, you know, I don't know, I guess you got to say, like I've had some success, like we've raised money, we have customers, like we built a product, we've done a lot of things, but like I'm three years into this journey, it doesn't feel like success yet, right, and that I think that's one of the things it's like. When you look at like the startup hustle and like just the LinkedIn shit and people post like it seems like everybody's just like riding a rocket into success constantly. I think a lot of it is like a it's just building your brand or whatever Could be. I think you have to like have that outward positivity. Like a look at this thing I did because nobody else is there to celebrate your successes. It says literally you just sit in your 10 by 10 square like, oh my God, we got a customer today, thank God, right. So you have to like project it like onto LinkedIn, like look how good we're doing.

Speaker 2:

So I think that everybody is like a lot more excited about like their successes than like they might actually feel. Like because day in, day out, as a founder, like it's a fucking roller coaster man, like I had a real bummer call right before this, like I'm pulling a style and like stoked because like I know I've got something really exciting like going on right now and I've got a really cool call coming up next. But like every single day it's like you sit down, You're like this is the day and like 20 minutes into you're like oh fuck. So I feel I feel like really what it is. This is like just as far as like starting a company, it's just like being able to like roll with the punches, like being able to just like blaze through something. Like just just blaze through things, like I'm going to do this, like steadfast, like I'm gonna approach this so bullheaded, but know when you have like gone too far right and like setting your experiments, like testing things moving quickly, like kind of coming back to that architecture and that TDD loop, like that's the same way. Like we run the business like let's try this idea, see if people like it. If so, like we'll invest more time into it, if not like shelve it, and you have a lot more failures than you have successes. But when you have those successes, like how do you, how do you, how do you latch on to me get as much out of it as possible? So I mean, you know it's it is.

Speaker 2:

It is very hard to start a company and I feel like we lucked out, like we started ours, like right on this, like last wave of crazy Silicon Valley money. Like raising last year was hard, like we did raise a good round, maybe for building an AI product. Today maybe it's easy to raise, but everybody else is not building an AI product. It's hard to raise right now it's harder. It's hard probably been since the bubble first burst in the early 2000s. So, yeah, it might appear like success, but like yeah, I'm going through the ups and downs every day. Like like everybody else is, whether whether it looks like that or not from the outside, looking at the LinkedIn yeah, it's, um, you know it's, it's, it's difficult for sure at times.

Speaker 1:

You know, like I fairly recently opened up my, my podcast for sponsors right, because the goal is to build a sponsor base, that you know it essentially cuts out, you know, a security stack. So if someone says, hey, you know I want to go, I need a sim or I need X, right, well, what I listen to, security on filter was security on filter recommend, right, and I mean, like you said, I'll get on these calls and it'll just be, you know, back to back to back of just badgering. You know just me and everything else about it. It's just like man, this is, this is not gonna work out, but something in me, you know, just still believes it's gonna work out, right, it's, and it does right. Like I have good days, I have bad days, whatnot, and I've encountered, you know, people that I consider to be friends. You know, I actually doubted me when I was starting this thing. They kind of laughed at me.

Speaker 1:

We're starting a podcast like who would listen to this? You know who? Who do you know that would actually listen to you? Talk for an hour, joe? Well, that's a good point, because I don't want to listen to myself talk for an hour. So why would they? Yeah, yeah, it's a, it's a. It's a interesting predicament, you know, because you have to be able to say you know, well, screw your opinion, like I'm still gonna make this thing work, I'm still gonna do it. I'm still gonna try. And I think, you know, if I would have let them stop me right early on and I never would have met all the people that I've met, you know, I would have regretted it. You know, looking back, you know, in my 60s or whatever, like I totally would have regretted it. But if I at least tried and failed, you know, at least I could say like, hey, I gave it my all, you know, and it still didn't work out.

Speaker 2:

I went and did this other thing, but at least I tried, you know yeah, it's funny, my one of my co-founders they got two co-founders our, our COO, chief Operations Officer joke is he's a operations engineer COO, thank you. He thought the idea for Master Driver was so stupid when we pitched him on it originally. We're I've known him for years. He was my boss like seven or eight years ago and then he I poached him at a company we worked at and then like that's really like the real, like idea of Master Driver, like kind of solidified, like seeing like how much this big organization struggled with operations is. When I showed it to him originally he was like this is stupid, like nobody's gonna buy this thing here. I mean I we actually have an interview that's going up on our podcast where I grill him on like like poopooing us, but like it does suck.

Speaker 2:

It's like but now he owns a third of the business, like he works on day in, day out and he's like, oh, I see the value in it. Now it's just like you know, people's especially to start like people give you a lot of opinions. I got I got a lot of investors that give me a lot of different opinions. I got advisors that give me all like conflicting opinions, like people have opinions, like am I gonna be good at a podcast or not, like you'll know till you try. Right. The real question like do you have, do you have like the gumption to go try? Like do you have the desire to go try? And if you do, you should fucking go do it, and if you don't like it, stop.

Speaker 2:

And if people don't like it then then probably also stop, but maybe not yeah.

Speaker 1:

I would. I would much rather try and fail than than not try at all. Yeah, you know, like that's, I don't know, when someone tells me that they think you know, my idea is stupid, or that you know I shouldn't go down that route, or I shouldn't, couldn't want it. You know, whatever it is, it's like I don't know what. It is something in my head, just it's like a switch that flips. It's like, okay, now I'm gonna do this thing. You know, like, you just told me I can't run a marathon. Okay, I'm gonna go run a marathon. Yeah, like you know, you told me I can't do you know this 50 mile race. All right, I'm gonna go do it.

Speaker 1:

You know which? I don't know what it is, it's just, it's just a. I don't know. It's interesting, but not everyone has that. You know, like, even my brother, you know, grew up in the same household, raised by the same two parents. You know he is not the same, he is like the opposite, he's go with the flow. You know, type thing, not gonna go against the grain or anything like that.

Speaker 2:

So it's just, it's just interesting to me, you know, to see how people build that up, you know, for themselves yeah, I mean, I think it's you gotta just do it and like, if you're enjoying it, keep doing it like you're seeing success, like focusing on those successes and try to reproduce it.

Speaker 2:

Like not to be use VC speak, but like pattern match, like okay, this works, like this type of guest works on the podcast, like keep doing it. Like I mean, if people like it, that's great, like that that's building user base. Funny, we, um, we've been trying to like build our social presence and it's funny cuz. Like trying to figure out like how to build social presence as a tech company is I think it's also hard. There's some people are very good at it and like the super base teams great, right, right, but they post a lot of funny shit, right, like it's not a lot like deep, like like technical shit and I I try to be humorous but like I, rather I rather tweet about technical stuff. Right, it's like we've been struggling just got like a few thousand followers on like a Twitter and LinkedIn and stuff.

Speaker 2:

And one of my VCs was like like, because I have a celebrity dog, like how did you build the following for dog? Like, how did you like build up that? I said, oh, we just posted every day, post every day. Eventually there was like 30,000 followers of the dog, like people. People asked to take pictures with her, like in public.

Speaker 2:

It's super weird. People like Ziggy and I'm like how are you leave my dog alone and like why don't you just post every day? Like I just do it every day, just do it every day and like build your following. It's just like it's. It's interesting. It's like it does feel so much harder sometimes to like get that like that habit, like that you really, because there's just so much shit to do, right, like yeah, there's interviewing this podcast and I'm sure you've got to edit, you've got to advertise, you got a source leads to be on it. Like there's a ton of stuff outside of, like the part that people see, and I think like that's what really comes down to is like when you're, when you're doing the part that people see and there's like 90% of stuff people don't see, like are you getting enough joy from that like moment where, like, people are using a thing where it's like it's worth doing the rest of that stuff?

Speaker 2:

and if so, then, like, keep investing in what you're doing and keep going for whether it's a startup or a podcast or whatever the case maybe, but I think that's that's the hard part. I think that's what a lot of people give up is, like I was hard or it sucked, or somebody told me it was dumb, like everybody has fucking opinions and most of them are bullshit. You just got to go with, like, what works for you right, so talk to me about what Mass Driver is.

Speaker 1:

What's the? We kind of touched on it before, but what's the problem in the industry that you guys are solving, and how are you solving it?

Speaker 2:

yeah. So in our industry, like I'll say, I'll come out first and say like there's a lot of buzzwords right now in the platform engineering space and there's a lot of bullshit and non-bullshit materials out there and I think that right now what's happening is like we've had this like decade or 15 years of like DevOps right and people rode the, the marketing backs of DevOps into billion-dollar businesses and I think people are starting to do that platform engineering and we're one of those people. But I think that what we're doing and like and the reason that we're doing what we're doing is much different than a lot of people in this space. So if you take a step back and like look at where we are can mention this earlier like listen, five to six percent of engineers have operations and security DevOps experience. It's like how are we doing DevOps? As we see this all the time in our industry? It's like people say, hey, oh, you know what it's a culture. Like you just got the culture wrong. It's like okay, maybe it's that I've got one ops person and 300 software developers, maybe that's the bucking problem, maybe it's not culture, maybe it's staffing, maybe it's budget. That doesn't really fit in the culture. The culture is great, but we don't have the resources. Even if we did, if I don't work at Fang, what's the chance that I get that ops engineer that I really want? The person that came through the interview pipeline where I'm like that's the one that one can also probably go get a job at Google making three times what I can pay, right.

Speaker 2:

So the reality is is like, some of the things that we depend on the most, not the shit that we want. I want TikTok, I want Twitter. Like, you don't need that. Those are the people. They have our attention, they have our money, they have the ability to hire the teammates that most companies need. But when you're at, like, the waste management company or at a healthcare company, like, how do you attract great talent? You actually need good operations and compliance and security engineers, but they're all going to these cool DevTools instead. How do you get that talent? Make bigger budgets or you accept the candidates maybe not the best and that's fine.

Speaker 2:

Like, and now you gotta train that person. Have you trained on the spare time? Are you giving them 20% of the week to do it? Like, where are we getting all this operations experience and security experience that we need to run all the companies that move to the cloud. We're not like a lot of people just go with it.

Speaker 2:

Product manager doesn't give a shit if it's secure or not. Product manager doesn't care if it costs a bunch or not. Take care that you click the button. That thing clicks fast and it sells more shirts, right, cfo? Cfo cares about the costs and you're gonna hear about the cloud cost in about three months when, like, the quarterly reporting gets to them, right and so, like seeing, like this is the state of the world and people on this call, or people are listening to us, are saying, not at my company, you're lucky. I congratulate you. If you have one ops to seven software developers, great, but the reality is on the planet there's one ops to maybe 22 software developers. So if you have that ratio, you've taken some of it away from.

Speaker 2:

Another word who's suffering harder? And there's proof of this. You go look at the door report. We all love to read that. We're like huh, I saw the new door report. Everybody's doing better. Yeah, through page three, you get down to page 37, everything's fucked. 50% of people that respond to the door report, the people that are in tune with the DevOps report, say that an outage takes them multiple days to resolve, and they deploy software once a month. It's 50% of the people that respond to the DevOps report.

Speaker 2:

So are we doing DevOps? Well, like so, this is what we're trying to solve. Like we've been saying, devops is a cultural problem for 15 years, and it is. It is cultural at the end of the day, but there's so much other shit that we're missing. It doesn't even give you the chance to solve this as a cultural problem within your org, and so what we wanna do is help people move towards platform engineering, which is a subset of DevOps.

Speaker 2:

Get developers to the point that they can self serve. That's what developers need to do. They need the cloud to be easy. I need a Postgres database and I need a queue. What I don't need is service now and waiting on the Ops guide two weeks to build me a Terraform module. I also don't have the time to learn Terraform. I don't have the time to learn OPE and check off, and I don't have the time to learn all the compliance docs that just came from our auditor. I don't have the time for this shit because I gotta build a product that makes the company money. Shift all that back to the Ops person. We're not doing DevOps anymore. It's the Ops person's problem, right? So we're just shifting this stuff around, but we're not building more operations engineers and so the way that our product works is there's two sides to it.

Speaker 2:

If you're a developer, it's a no code tool. Pretty cool. Come in there, you draw some infrastructure, you draw your applications, hit, deploy and it magically works. Now that sounds terrifying to every operations person in here that there's a no code tool. What it actually is behind the scenes is it's your Terraform Ansible Pulumi Helm. Whatever IAC tool that you're using. You just use that tool, you publish it into our registry and your developers now have a central place where all of the IAC is, all their Terraform Pulumi. Whatever you're using is all in one place.

Speaker 2:

And as I'm dragging and drawing stuff, it's actually pulling modules in, and as I'm connecting stuff together, it's doing things like oh, I see the applications connected to this Kubernetes cluster. It builds your CI CD pipeline for deploying behind the scenes. So your developers aren't over to get doing a bunch of stuff in CI. They just literally say this application runs on this Kubernetes cluster. I can have GitOps if I want. It's just one single entry in my CI CD file MassDriverDeploy, and MassDriver builds essentially a virtual CI CD pipeline behind the scenes. It goes okay. I see you're deploying this app. Let me look at the entire dependency graph that you've drawn out here to figure out what to do with this. Ah, you wanna go to this Kubernetes cluster? That's great, but I can also see you have a dependency on this Postgres. Let me go ahead and pull the secrets for that. Inject it into your environment variables, bind your IAM policies in your role, schedule your workload.

Speaker 2:

Your developer literally diagrammed their infrastructure not a lucid chart, not a whiteboard. They got everything that your ops team wishes that they would go do, and your ops team only had to continue building IAC tools. I'm gonna take OPA. I like it. I like Terraform. I'm gonna build a really good Postgres that we're gonna offer to our team and you essentially get this like almost like an e-commerce platform for your developers.

Speaker 2:

It's this thing. It's like I just grab stuff off the shelf. It's like ooh, ooh, it sucked to compliant. I'll take one of those Postgres' and then it gives them just enough surface area to configure what they need. To get you things like letting your operations team like give them recommendations of how to run a Terraform app. This, you don't have this in Terraform or rich validation, right. So I can say things like hey, we do support Postgres, and if you're in AWS it'll be RDS, and if you're in Azure it'll be flexible server, whatever.

Speaker 2:

But we also ship it with three configs. There's a development config, like you got a preview environment. This is how we think you should run it. We have a config for the US and we have a config for the EU, right. And so now your developers they drag the thing over and goes hey, here's the three recommendations of how to run it. And you're like I'm in the US, it's like, great, we just picked our production workload configuration for the US. And you're like sweet, it's Postgres and yes, that's all I give a shit about. Like don't wake me up at 2 AM, we go back to writing. So that's a very boiled down version of way the platform works, ton of functionality in there.

Speaker 2:

But like, what we really wanna do is like most of the platform engineering space right now is focusing on DevX and that's important. But like Devs have it pretty good. Like, when you look around the teams the security team, the ops team, the dev team you're like you guys got nap pods. Like I'm waking up at 2 AM to fix your code, and so I think a lot of our industry is focusing on how we make the developer experience better. It's like we should be focusing on how do we scale this constrained ops team. How do we lower the surface area of the cloud so that people can reason about what it is Like. We're not focusing on that enough in the platform engineering or DevOps space, and that's what we're trying to do is say platform engineering should not be about making the things amazing for developers. Platform engineering should be about scaling operational efficiency and security inside your orgs without blowing your cloud bill up to a million dollars a month.

Speaker 1:

Yeah, it sounds like it really simplifies everything. It takes learning all these different architectures and workflows and everything out of the mix. I remember a year or two ago, right, I had to start learning Cates because we were gonna deploy some app in the cloud on a Cates cluster. And here I am getting a book on Kubernetes, trying to figure out what the hell is what, just trying to go through it as quickly as I can and there has to be a better way to do this Like, how difficult is this really to achieve? But that's a fascinating way of going about it. I never would have thought about developing a solution that operates the way that you described, and I feel like your architecture background kind of has a play into even how you kind of design the solutioner. At least from what you described, it sounds like it.

Speaker 2:

Yeah, I mean, I think again, like it's that I'm trying to think in three dimensions plus load at any point in time, right, and I think that was one of the things that was key is, you see, a lot of tools in this space and I think and just to be clear, I don't wanna shit on anybody else's tool Like I'm friends with most of the CEOs and CTOs of my competitors. I think that the reality is any of us that are out here saying the tool that we're building works for everybody, everybody should buy it's nuts. It's fucking bonkers. Like that was the case of everybody who'd be running on her own right. Like there's no one tool that's gonna work for every order. The best you're gonna do is the best one that works for your team, right, and but, like you know, kind of thinking about like what we're trying to solve, like thinking about like all three dimensions and load at the same time. Like we have a problem and, company after company, you talk to engineers like what is the problem? People complain about DevOps, they complain about ops, they complain about wait times, bottlenecks. Even in the most perfect scenario, an operations team that's doing amazing, there's still a bottleneck. I can't predict the future. I don't know what project you're working on and what you're going to come to me with. So when you come to me with it, you have to wait 10 minutes, 20 minutes, two days, three weeks, whatever. I think one of the things that was really key was we're approaching this not saying we're going to focus on DevX and operations is going to go away. We're coming to this saying how do we get you what you need without making anybody have to deal with learning a new tool set Because we don't have time? We don't have time to learn another tool. We've spent a lot of effort bending over backwards. Originally, the platform was very much like hey, developers, there's some dumb-down thing that you can do and you don't have to write Terraform. But it was still too much.

Speaker 2:

The original version of MassDriver did not have a UI. It was just this concept that we call the bundle, that we're actually open sourcing. But it wasn't a UI yet and we kind of realized one day we're drawing some stuff on the whiteboard, we've got these bundles. We're like, okay, so this is how they all connect together. And we're just like these are all just types and structs of data. We can program this.

Speaker 2:

Why are we making people cobble together like a little pseudo Terraform CI pipeline to get this power, instead of just saying, just draw it If you want to draw it. You drew it on a whiteboard, you typed it and then you went to fucking Lucidcharts and you drew it again. Then nobody updated it in six months, like let's just let people beat the drawing and be the source of truth. So that's kind of how we came to that. Definitely wasn't. It's iterations Like MassDriver's been through like a ton of development over the years, like there's a lot of stuff to the platform but like V1 didn't have a user interface Like at all, it was just it was very much like a CI oriented tool and just trying to get that like CI pain away from developers was kind of it.

Speaker 2:

People are afraid of changing their CI pipelines. Don't have great ways to test them right. You merge it.

Speaker 2:

You know, if it worked right. Like what's in that CI pipeline? Maybe it's tests, maybe it's provisioning, maybe it's secrets management, like who knows what is in a Jenkins pipeline. It is a wild, wild place, right, and so making sure that developers didn't have to think about changing that, because that was what they were afraid of, it was kind of what, like gave us this idea of like, going towards this visual, like generate a DAC under the hood.

Speaker 1:

Yeah, it makes a lot of sense. Well, Corey, you know, unfortunately we're at the end of our time here. Yeah, Before I let you go, you know why don't you tell my audience, you know where they could find you, where they could find your company, if they wanted to learn more. I definitely really enjoyed our conversation, so I definitely want to have you back on.

Speaker 2:

Yeah, so I'm Corey O'Daniel. Everywhere I'm the CEO of O'Daniel. There's two of me. So if you find the one that's really jacked in place, football, that's not me. I'm the software developer one yeah, I'm Corey Daniel. Linkedin on GitHub, twitter, massdriver's company and massdrivercloud yeah, and check it out. Give me your feedback. We'd love to hear from your community.

Speaker 1:

Awesome. Well, thanks everyone. I hope you enjoyed this episode.

Navigating Complexity in Cloud Security
Path From Physics to DevOps Startup
Building Skills and Passion for Engineering
Navigating the Challenges of Starting Up
Platform Engineering in DevOps Industry
Revolutionizing DevOps With MassDriver