DevOps, CloudOps, DevSecOps, etc…what's in a name? All of these operational titles play a critical role in managing and securing your cloud. In this episode, Jim and Jeff Bozic, Principal Architect at Insight, untangle this alphabet soup and help us understand who the key operational roles, what they do, and why operating the cloud is a true team effort.
Jim: Hey, everybody. Welcome to another exciting adventure. Navigating the Cloud Journey podcast. I'm your host, Jim Mandelbaum Field CTO at Gigamon. And today I've got a great guest, Jeff Bozic Principal Architect at Insight. Hey Jeff, welcome.
Jeff: Thanks, Jim, nice to see ya.
Jim: Now, why don't you tell us before we get started, a little bit about your background so we kind of level set who you are and why we should be listening.
Jeff: Sure. Thanks, Jim. So yeah, I've been in the industry going on about 20 years now started as an Admin doing storage and virtualization, data protection. About 10 years ago, I then moved to the dark side of sales and working for Resellers. And I really enjoyed that helping different clients figure out how to leverage technology to achieve what they're trying to accomplish, having some of that background, but lately the last five years or so, really trying to help clients understand what is Cloud mean to them and how do they start to operationalize that. And to me, a lot of that starts to understand what DevOps principles mean, how those can extend throughout all of IT. And really what that means to every client's individual journey of where they're trying to get through this digital transformation that everyone's going through.
Jim: Oh, I hate that term. You open the can of worms. You said DevSecOps.
Jim: So I want to level set something. We hear AppDev, we hear DevOps, and we have DevSecOps. Let's level set. Let's do some terminology baselines for those people that are going, I don't get it. Why don't you go through those three and clarify for all of us? What the heck do these, each of those mean?
Jeff: Yeah, it's a good question. And honestly, it's a lot of how I start my conversations with clients; is let's understand exactly what we're talking about, buzzword bingo, and now there's GitOps and there's InfraOps, and heck I'm starting to coin my own term of ModOps, which is just all of it. What does all of it mean? Because ultimately we're trying to change the way that applications and features and capabilities are delivered to clients. Organizations are figuring out how can they build a competitive advantage reach, react, respond to users quickly. And there was this movement that started with AppDev how people are writing and developing applications.
And those, those things needed to start to fundamentally shift if I want to get features out to a client faster. Now, how can I understand that my banking users want mobile check deposit. How can I get that feature out to them quickly instead of these yearly releases?
And so then that started to create these concepts of agility. A lot of these concepts came from manufacturing and lean manufacturing and some of the Toyota models back in the day. And so that started to create this concept of DevOps, which is how can dev and ops work better together. How can the people writing the code and people that have to then operationalize that code in production and deploy it and manage it? How can they start to work better together? The problem with that, and why I don't like the term as much as you don't like digital transformation, which I don't like either, is there's so much more to that than just the devs and the ops. There's security, there's the people that manage the platforms, there's financial concerns, there's governance concerns. And so then we start to hear this term of DevSecOps which is introducing some of these security concepts into the DevOps movement. So, to me, I think, wait a minute, these aren't separate concepts. Security has to be across all of it. The operating model has to start to shift across every function of IT, from developers, the security and infrastructure, to the data teams and IT architect teams. So, I think it's all just buzzword bingo of how we're changing operations. A lot of it is based on agile and agile frameworks. So how can we operate a little bit more agilely? How can we be secure? And ultimately the goal of all of this is how can we move fast and how can we be safe. Speed and safety.
Jim: Okay. So, we've been talking about applications, we've been talking about developers. We've been talking about security teams. These are all silos, we know that. But infrastructure now is the one responsible when we think about a hybrid Cloud. Nobody operates only in the Cloud. Nobody operates only on prem anymore, it's all hybrid. And now they're asking these infrastructure teams to take that and build out into the Cloud. So how in the world do you get the infrastructure teams involved into the other development and agile groups? How do you mix them? How do you get them to care?
Jeff: That's a great question. And I generally see two avenues there. One is there's plenty of people that like to challenge themselves, want to continue to grow as individuals that very much believe in the value of their companies, want to provide value to their company, and are realizing that the world of infrastructure and even development and security; all these roles are changing fundamentally, and they want to embrace that, they want to be in front of that, they want to continue to challenge themselves. So, I do see some self-motivation of where that's going. I also see self-preservation as a motivator there as well. A lot of clients that are in the Cloud today, or that are moving to Cloud today, are doing it around IT, and sadly, even more so around security which is very dangerous and risky. We start to see that they're going to go to the Cloud. They're given the opportunity to swipe their credit card. And so, infrastructure teams and security teams and other IT functions are starting to realize if I'm going to maintain relevance, I need to get in front of this and ultimately the best for the business.
I think at some point too, you can't scale. The concept of a full stack engineer; you can't have someone who's who writes incredibly good code fast and quick also understand what reliability and resiliency measures there are on public Cloud, how to get performance measures and how to do that cost effectively and how to do that securely.
So I think that the organizations are also starting to realize, wait a minute, infrastructure teams that think about reliability, that think about data protection, that think about performance, that think about budgets. Security people, they need to be a part of this.
Jim: Okay. So, let me turn this on you a little. I heard really three different versions. I got one that is self-preservation; I want to make sure I'm not obsolete. You have another one that they're doing it just, there are the motivated folks out there that want to do it. And then there's the, I don't have a choice. So, if I'm an executive sitting here looking at this, having this podcast and saying, okay, I get those, but what measures can I take to start making these teams understand that security is everybody's problem? What are my choices? How do you go there?
Jeff: That's a great question. And it's what I actually get asked quite a bit. My personal belief is it does take a little bit of, I think it takes both promoting the internal folks that, find the folks that want to change and promote them. Not necessarily promote them organizationally, but give them the resources they can to thrive, learn, and grow. Support those folks. I do believe some outside influence and bringing in some skillsets from the outside is very helpful. It does two things. We're in this age of, you don't know what you don't know, that's more wide and broad than ever. So, bringing in some additional expertise and experience that can start to fill in some of those gaps, you don't know what you don't know. But a lot of times the bigger barriers we see aren't generally technology. Skill sets can be a barrier, but internal friction and politics can be a big barrier.
So, bringing in some outside influence. The most dangerous words in business, "it's the way we've always done it". So, bringing in someone that, that doesn't have those biases, doesn't have those concepts, can maybe challenge the norm a little bit, is another great mechanism. So those are some of the ways we see from the skill set perspective.
And then, honestly man, from the how teams work better together, I personally believe a lot of that comes down to the personal relationships. We're all still human. We like building personal relationships we like helping out people we know, we like being asked about our opinions of things. So pick your infrastructure teams and security teams out for a beer, let them rub shoulders together. Let them maybe even understand the day in the life of each other so they can understand the challenges or how what you're doing is affecting somebody else. I want them to reach out for help. Hey, Mr. Security person, I'd love to understand what does security mean? How do you think about securing access roles and, APIs, and things of that nature? And hopefully the security teams, hey, I'd love to understand resiliency and how does IAM affect you and things of these nature. Building personal relationships to me is still a lot of how people enjoy their work.
Jim: All right. So, let me ask you another question that I find really interesting. Is infrastructure folks have traditionally built out infrastructure. Developers have built code. But that isn't the case anymore because when we look at the Cloud, the advantage to the Cloud is automation. The advantage of the Cloud is leveraging the tools to make it more resilient. You've used all the words. I want it to be more resilient, I want it to be more effective, I want it to meet my needs of the company. Now, all of a sudden, these infrastructure folks are having to learn code.
So, infrastructure as code is important. And so, you brought up the concept of, I want to get my infrastructure folks having beers with, or sodas in my case, cause I don't drink beer, getting them together to cross pollinate is the way I would look at it. Because now what's happening and I'm going to let you elaborate on this, but, and see if you agree with me, is that our infrastructure folks are being given here's code, go use it.
Jeff: Yeah. Even just the concept of where should infrastructure as code lives is a question I get asked. Who should be responsible for it? And I see it both ways. I see a lot of organizations where the developers and a lot of them are using it to provision out to, to say public Cloud around infrastructure.
I see teams where its starting with infrastructure which is pretty amazing. How can I, start to automate my deployments? And then I'm seeing a lot of it started in AppDev, but infrastructure teams are realizing again, they need to start to participate in the continuous delivery part or deployment part of the CICD pipeline.
I do think that which group owns it becomes somewhat internally cultural, but I do believe there's always been this friction. Infrastructure, people don't want to code, and they think, that coders are Prima Donnas and coders are the vice versa; they think that infrastructure people are the staunch, no man, no you can't do this, this is what you can get.
So I think there's a couple of things about it. One is disarming infrastructure people in the context that it is code. There are software principles that you need to apply to do this safely. Things like having a source code repository and versioning, testing your code, unit testing your code, potentially things like paired programming and concepts like that. But. It's still is much more akin to you writing a PowerShell script or Bash scripts. You're not writing any programs. There's pretty good documentation on how to understand these languages, and they're not that much more complex than again your Bash scripts, your PowerShell scripts. But if understanding from the developer side, what does it mean to make my code reusable? The one thing I see as a concern, or a risk is infrastructure teams believing that infrastructure as code is simply taking their PowerShell scripts or the Bash shell scripts and just putting them into an enterprise tool like Terraform. Oh, I have infrastructure as code. No, you just put your scripts into an enterprise tool. Again, things like, how are you checking that code in? I wrote a lot of scripts in my day. No other person would take those scripts and use them. I didn't comment them. I knew what I did. Heck, I look at my own scripts from two years ago, I'm like, what was that doing? That can't work in the world of infrastructure as code. That becomes production level code that needs to be treated as such how you're deploying applications safely.
So, I think paired programming, and not in the true sense of what a developer would do with paired programming. But taking an infrastructure person, taking a programmer or a developer and putting them together in a room. And this is a little bit more than just going out for a soda or a beer, but actually saying, hey, teach this person some of these conceptual skills. How they can take their scripts and make them a little bit more enterprise grade, make them a little bit more production grade ready, make them a little bit more usable for our pipeline that we're building. And I think the two-way street applies there is now the developers can understand getting resiliency isn't as easy as building, two EC2 instances in different availability zones. Thinking about performance, thinking about costs, thinking about data protection is not as easy. Like my job is not as easy. It's not just magic, hit an API and that happens. And so now you can start to get again, I understand what you do, and I can help you. You understand what I do, you can give me better requirements to write infrastructure as code to meet your needs. So I really do think it has to come with bridging these gaps making virtual cross-functional teams, getting people together towards that common goal.
Jim: Yeah. And I think if we highlight a couple things in there. I think one of the things that's important that I got out of that was a change management, change control, documentation. Making sure that when you deploy that you're deploying the right version, the proper version, and oh by the way, you have a version you can roll back to if it doesn't operate as expected.
These are all things that as developers, especially when we talk about modular development, the ability to deploy an incremental update, looking at it and going nope, and roll it back instantly and not impacting the entire environment. That really is what we're talking about here. And getting infrastructure folks to understand that is a big hurdle. And I think you're right. I think getting them to work together, education on both.
But I think it's important as people are moving to the Cloud. This whole podcast is about people that are moving the Cloud just made the move, whatever of what should they be looking at? What should they be doing?
Jim: And so, another question I have for you is I'm going to use the DevSecOps buzzword here. What can those teams do to learn how to work with those infrastructure code as a secure environment? Because just deploying it doesn't mean it's secure. And so now we've got another team. So, we had infrastructure, we had AppDev and now we got the security team involved. How does that get involved?
What tools are we using and what methodologies can we use to ensure that we're not just putting stuff out there and just throwing it to the wolves?
Jeff: Yeah. I mean you're touching on to me, what is right now, one of the biggest things I'm focused on, and a lot of our clients are asking these questions because the great irony or catch 22 of infrastructure as code or just automation in general, is that the benefit of automation when you're doing things right, and in my opinion, doing things right starts with doing things securely and safely. That's where you start to gain these amazing benefits of being able to move fast. And there's an interesting beauty of if you're doing that, you're making sure you're confident in your deployments because you're testing them. You have a lot of policy, security policy that's being driven through automation. So you're highly confident in the security of that and the safety of that deployment. You become safer as you start to automate because a lot of those checks and balances are already done, they can be automated. Now, instead of only running maybe ten unit tests to verify port scans and CVE exploits and things of that nature, now, maybe I can build test harnesses of a thousand and maybe I can start to get even more granular things I'm checking for the faster I go. So, I become more and more secure and can find bugs faster and things of that nature. But the risk and the challenge is if you're not doing things safely and securely, and you start automating, you are now increasing your risk posture, and you are now proliferating risk and potentially, your attack surface or being breached for ransomware or whatever the case may be.
Jeff: So, the security has to be foundational to automation and infrastructure as code. What becomes interesting. I think really where we're getting at here is to me DevSecOps boils down to two fundamental foundational things. And many people have many opinions of this. This is just the way I see it is, observability.
So how can I actually monitor, observe what's happening and have a baseline to know what's good, what's not. That also then leads into, am I actually doing things of value or not? But the other is, building test harnesses and a lot of that is how do I codify security? How do I start to take security principles and those that the strategy and the context around that, and the controls and codify those? Because if I can't, then I can't automate them. I can't automate my tests, I can't, automate my checks. And, we're really mostly alluding to as deploying something, but then how do I do it while it’s in runtime? How do I make sure things aren't changing or maybe a new CVE was just released? And how do I test for that while things are in runtime? So, a lot of it becomes, how do I codify. How do I use policy and codify security into policy that's driven down the pipeline? And there are a lot of toolsets that are starting to come out to help with that. Obviously from the observability perspective, Gigamon is a great player in that. There’re a couple others that can provide the visibility into what's happening real time, both in runtime as you're building things. Pipe up into greater observability platforms. So that's a big step is just getting those alerts and monitors both on premises, and Cloud, and things in transit.
So, having tool sets that can be ubiquitous across those platforms, but then also from how do I start to codify and build policy? Things like Palo Alto Prisma Cloud has ways that you can start to codify those policies. Perhaps you're using continuous deployment tool, like Harness has a lot of functionality of how can I start to codify policy of this deployment can't move forward and this infrastructure as code template can't be used until it meets these requirements. And that could be port scanning. That could be scanning the container images or VM images it's about to deploy. It could be just scanning the code itself. Is the code itself sound code or is it going to do things I don't expect? And how am I checking against CVEs and things of that nature? So, there are tool sets to build, those guard rails. The third piece of that is how do I enforce it? And some of that becomes using tags and metadata. So, you, again it's your policy, you're codifying policy in a way that if you say nothing can deploy until this policy has met this test harness to test for these open ports, I won't deploy something until that's done.
Then part of your policy and part of these tool sets is to put a tag on it says, yes, it passed this check. And then I have another check that says, before I go deploy it, does it have this tag saying, yes, it passed this check? Yes, it pass this check, go ahead and execute.
Jim: And all of these are part of the automation and that's the key. The one thing that's important is this is not a human check. This is an automation check and that's important for people to understand. They look at this and they hear this. That's going to slow me down. That's going to hinder, but the reality is this is all automation. So that's the beauty of the Cloud is that automation and the ability to do this.
Jim: Now I want to switch tracks on you because when I started this out, I went into terminology and there's another terminology that's in this space. We're going to shift left or we're going to shift right. So, let's talk about what in the world does that even mean?
Jeff: It's funny because I use the terminology, but I realized that I use it in the concept of what it means to me. And I don't flesh that out with clients and I'm glad you're bringing it up because I think it does cause confusion. I think for the most part, when the industry thinks about shifting left and that was the primary term. Shifting right is a newer term based on older concepts, that's interesting. But shifting left is more, how are we moving things more towards the developer? And that starts to think about that DevOps movement. A lot of it was how are we shifting more towards this containerized, automated, agile operating model.
Jim: A lot of modular development as well.
Jeff: Exactly. And again, a lot of it becoming foundational in agile. And again, what was fascinating to me when I started learning about this was, I knew that DevOps was foundationally built upon agile. But I didn't realize that a lot of that came from manufacturing in the 70's.
And so that's where my brain started to turn of, wait a minute, if application developers and software engineering started to recognize I can adopt these principles of how I develop software, do that faster and safer, why can't those principles be adopted elsewhere and specifically throughout all of IT? And I think they can. So, as we start to think about this agile movement and a lot of it started on the DevOps side, that shift left to me means how are we starting to adopt some of those principles. For instance, security used to be this, build an application, we'd give it to the data team, they build their data layers. We then give it to the server team and then they build the VMs. We load on VMs. And then the last step before you turn it on for production was to have this huge security scan. That goes against these DevOps principles. You can move as fast as you want over here, but if you still have this, three, four day wait of a scan, that's not helping you. So how can we make that scanning and that security function more agile and break that down into components that can be automated, that can be testable? So, to me, those are primary, fundamental concepts of shifting left. Is can it be automated? Can it be tested? How do we create along this pipeline? What's interesting though, is it's easy to get wrapped up in this concept then that everything becomes software, everything becomes code, everything becomes simply automated. Then what is the role of everybody besides dev and ops? And that's a trap of thinking to get into.
Things like data protection still become very critical and how you think about data protection? And so that's where this shift right concept starts to come about of, reliability. You think of the concept of an SRE. SRE to me is a very under stated or I guess misinterpreted role. The SRE was founded at Google. It was developers and software engineers that realized, wait a minute, if we're not understanding some of those core infrastructure principles, how reliable is it? What does five nines app mean when you push into AWS and use six different AWS services? Cause they all have different fail overs and how they fail over and their reliability are all different. How do I start to understand those things? How do I understand the minimal performance level I'd need to meet my app, but be cost effective?
And so that's a great example of them shifting right. Of moving away from the development and saying things about the infrastructure and platforms still do mean something, they're very meaningful and we need to focus on how we can optimize that. Again, think about observability and visibility. It can't just be about bugs in the app. Sometimes it is hardware failures and things of that nature.
Jim: Yeah. And I'm gonna elaborate on that comment because you're talking about site reliability, you're talking about uptime and then so modularizing your apps. Obviously, the automation of the tools to make sure that you've got Apps and availability, but you also have to consider you're running on someone else's infrastructure. And somebody else's infrastructure has their reliability. So you have to look at what you're developing and combining with what they have, and understand overall, what does that mean when they have an outage? Because how are you going to respond to their outage?
So, it really is that right left in who's responsible, who's doing what, who's looking at what. So it is a really interesting topic.
Jeff: Yeah. Jim, if you don't mind real quick, an interesting anecdote about it. I remember when I went to one of my first DevOpsDays, this was probably five or six years ago. And the guy on stage was talking about this interesting problem of how to get your real-time data source nearer to development. It's interesting, but as he's talking through his presentation, he literally is talking about deployment and then he says, you hit an API and then the magic happens.
And I remember sitting there as a, as an infrastructure kind of legacy infrastructure guy. In fact, one of my colleagues is amazing. He looked over, he he's like Jeff, I need a new business card because now I'm a magician apparently. And but what that told me is holy cow, these people are deploying to infrastructure. They're deploying up to AWS and it's literally magic to them. Wow. This is where again, that shift right mentality. You need to understand that these are still critical components, that the mindset and skillset of infrastructure and security people are still necessary. It's just changing how that gets applied.
Jim: Yeah. Continual education is key in this space, we have no doubt. Now I'm going to ask you one final question that I think is could have been the whole time. But as developers, when you look at developing an app and I'm developing that for the public Cloud versus development for the private Cloud. There's differences in how you go about it. Maybe you can talk a little bit about the differences in developing and we already touched about it, but, with reliability and controls. But maybe you can touch about if I'm deploying and building an app that's going to run in VMware versus it's going to run in AWS.
Jeff: Yeah, that's a really great question. And again, it's one that I get asked a lot from leaders. Gartner, I didn't agree with that, I still don't today, they came out the whole Mode 1, Mode 2 operating models where mode 1, actually, I don't remember which one was, which, but one was the new “DevOpsy”, microservice, containerized, application, deployment model, and one was the monolith the traditional VM application model. One of the things I believe in, and I like to talk to clients about is, to me, Cloud native isn't necessarily about where it's more about how. And if you think about why did AWS exist, it was not something that a bunch of engineers sat there and created something that they thought people would want to consume and said, hey, if we build this, people will come.
They built it because developers were changing application patterns to these new microservice containerized apps. And they didn't have an infrastructure team that could support them as quickly as they needed to or support these new containerized things. AWS kind of built this thing and maybe people want to rent compute, and they do, holy crap, this is awesome.
So you had this model that started to get built out from that perspective. But a lot of the discipline of DevOps, of how you think about requirements flowing. How do you think about what's the value of the features we're deploying? Even thinking about, infrastructure as code potentially deploying on premises, as well as public Cloud.
I don't necessarily think that model should change all that much. What's difficult is how you transition legacy workflows and legacy models into that. And again, that's where I get a lot of do I have two different teams then? Do I hire the totally separate Cloud DevOps team and I still have my existing infrastructure team and app dev team security team? Again, I think people can do both. If you're a legacy infrastructure guy and all of a sudden you start to learn infrastructure as code and Cloud deployments and Cloud architectures, you don't just forget how to administer VMware. It doesn't just go away from your brain. So, I do think you can start to mix some of these modes together with the same team and skillsets. But ultimately in my mind, you have developers developing microservice applications. You have developers that are still taking monolith apps and deploying them through VMware. The platform that they live on, I still think a lot of that flow of how again, how does that get provisioned to a database team? How does that then flow to what potentially infrastructure as code is deploying, should start to unify down into the same pattern.
So it gets, little bit tricky in terms of where should an app go? I see a lot of people moving VM based workloads into public Cloud. I see people building on premises Cloud support ed containers. So, I think there's a lot that goes into what platform should you use. A lot is even financially driven. Do you want to CapEx or OPEX your infrastructure?
We're seeing a lot of people's Cloud bills are getting very large and they're now trying to figure out, okay, I built this cool DevOps model of how I'm deploying to Cloud. I built a lot of skillsets there. How can actually readopt that back to on premises infrastructure? So, you're right, it could have taken the whole time. It's not an easy question to ask. I think it’s very client-specific, but I'll say my ultimate belief, there is two completely separate operating models with two completely separate teams to support on premises and Cloud deployments is not what I think is the most optimal way.
Jim: I agree. I think that, and I'm glad you went there, because I think that as you move forward it really shouldn't matter. It shouldn't matter as I build applications and services whether I decide to deploy it on the private Cloud, or if I deploy in the public Cloud, it should not matter. It's yes, the infrastructure as code portion of it will be slightly different, but my apps should not matter where they live.
And to your point, it should be, what gives me, number one, the best services for my clients? Number two, what's my best return on investment? And I love this. This was a CISO that I was talking to that said this. He said, when we first started the Cloud, we moved everything to Cloud. Then we got the bills and we said, whoa, get it out of the Cloud. So, he calls it the bipolar effect of the Cloud. And so I think that's because of that lift and shift mentality of let's just lift and shift it, versus, let's reassess, let's redevelop and rearchitect our applications, that it really shouldn't matter where I put it. It only matters do I need it to be about what's the availability on it? What's the best costs and how do I maintain this?
Jeff: I couldn't agree more. And I actually think that the Cloud operating models and, getting more to agile DevOps, DevSecOps would, pick your word of choice. I think that can help on premises teams and security postures understand that it applies there as well. The age-old concept of, the four walls of my data center are secure. And so, everything inside of it. Even on premises today, those concepts don't apply anymore.
Jim: There is no, there is no castle wall anymore.
Jeff: There's no castle wall anymore. And even if you're deploying a monolith VM, the concept of, okay I can get that developed and deployed in maybe an hour of your day, but then I still need a three-day security scan that I have to wait two days for to free up some people; that still doesn't really make sense or apply anymore either. So, starting to break that down into test harnesses and policy to be driven automatically, or even if it is manual, is still, moving those responsibilities down so by the time you're ready to deploy, there's not this huge security scan. Those make a lot of sense on premises as well. Adopting some of those principles back.
You're talking about moving things to the Cloud. A lot of the conversations we used to have, and they're becoming less. Lessons learned best practices are getting out there, but how do I met my on premises security controls to the Cloud? What technologies do I use to do that? Maybe it's not even the same of how I think about applying those or how I build that into policy. Once you do that though, then I think that vice versa can work. The rebound can start to work as well. Okay. Now I've figured out how to reshape security. Oh, cool. How can I start to adopt that back on prem? And maybe I have to bring those workloads back.
Jim: Jeff, before we go, are there any links references that you think people should go to, even if it's high level, just to get some understanding of what we've been talking about?
Jeff: Yeah. I can always relate it to my journey. Again, I was an old school infrastructure guy and started to make my journey of transformation if you will, five years ago or so. I started simply with a DevOps (devopsdays).
I like learning in person. What was fascinating was the first devopsdays I went to was really valuable because I understood 10 words that were said. And what that did to me was helped me realize that this is a whole new world that I don't understand at all. And then when I went to my second one, I could understand the words. I could have intelligent conversations and I can start to understand the concepts. And that was actually the one that the guy said I had API and I had magic. And so now I can start applying my own critical thinking of, holy cow, infrastructure and security is a world that they don't have any insight into as well. And so for me, that started to really help understand, why, first of all, why is this happening? Like why the DevOps even start to happen? But how has it starting to affect operations? How's it starting to affect what we're trying to do. And as a leader, I think, what are the mindsets of these people going through this change?
There's all other "devopsy"' conferences that you'll probably find in your local area. So, I'd encourage those.
The Bible of DevOps, if you will, the DevOps Handbook, that was the first book that I read after going to my first devopsdays. It amazes me how many people haven't read that book to this day, because it touches upon almost all of these concepts we talked about, and people have been struggling with it. This movement started in like the mid two thousands, 2006 'ish. We're going on 15, 16, 17 years. And a lot of people are just getting started on their journey and that's fine. It's actually more common than not. So don't feel like you're behind, but also realize there are quite a bit of lessons learned. The DevOps Handbook was a way that a lot of the initial kind of founders codified into words a lot of their lessons learned. So, a great book just to stimulate a lot of ideas, hear how people started to make this initial journey. And again, I think that'll help start to understand why and how, and where you might want to go to.
DevOps.com is a great resource.
And then honestly, webcasts like this. I consume these quite a bit as well myself, I deliver quite a few but I consume them as well. So, I think hearing from my peers, hearing from people's real-world examples. I'd like to consume that a little bit more than just reading blogs and white papers, which I do as well. To me these types of engagements are really useful. So those are some of the resources I would at least get started with.
Jim: Absolutely. I want to thank you, Jeff. This has been a lot of fun. There's been a lot of learning involved in this, so hopefully everybody got a good amount of information. We solicit feedback, so if anybody out there listening to this, has any comments, critiques, other topics that they'd want to ask question of, please reach out to us. Our contact information is in the podcast. And Jeff, once again, thank you, this has been a lot of fun.
Jeff: Likewise, Jim, thank you very much I appreciate it. I'd love to hear from people as well. If you have differing opinions, please reach out. I'd love to learn and hear what other people think as well. Thank you very much, Jim. And I appreciate it.
Jim: Thanks everybody.