Speaker 1: And we're live with another episode of Adventures and Devlops. Warren,
Speaker 1: what's going on?
Speaker 2: I wish I had something good to say. Uh, movie
Speaker 2: on the spot there. I guess I can lead with
Speaker 2: my facts, right.
Speaker 1: My fault for asking you how you're doing? My God,
Speaker 1: I should have known better.
Speaker 2: Yeah, I know, it's it's been quite a number of
Speaker 2: episodes already. I feel like, you know, you really got
Speaker 2: to spread that away before the I will I will
Speaker 2: say I was a little disappointed by this, but I found
Speaker 2: out recently that there are companies that leak their data
Speaker 2: on purpose. They use it as an advertisement strategy so
Speaker 2: people learn about the company, so vcs can learn about
Speaker 2: them and potentially buy them later, because it's such a
Speaker 2: great turnaround to say, hey, we had security problems in
Speaker 2: the past, but then we fixed them. So if you
Speaker 2: see on your LinkedIn stream or social media accounts some
Speaker 2: companies saying oh no, this hotel, hell chain, or a
Speaker 2: healthcare provider or leaked all their patient records, it may
Speaker 2: have been an intentional strategy, just so that you will
Speaker 2: learn about them and then maybe start paying the money
Speaker 2: in the future.
Speaker 1: I can only say that I'm disappointed, but not surprised
Speaker 1: but also joining us today. I'm super excited about this
Speaker 1: episode because I've been following Today's guests for quite a while,
Speaker 1: through on ninety days of DevOps and through all of
Speaker 1: your posts on x so Michael Caide, welcome.
Speaker 3: Hey, thanks for having me guys.
Speaker 1: Yeah, our pleasure and I'm excited. So for those who
Speaker 1: maybe have never logged onto Twitter, because I think that's
Speaker 1: the requirement to start seeing your post is just actually
Speaker 1: log on. So for someone who's never been on there,
Speaker 1: give us like the short version of your background.
Speaker 3: So yeah, so I'm a The posh title is a
Speaker 3: field CTO at VM Software. If you know VM software,
Speaker 3: we focus on protecting workloads here, there, and everywhere. And
Speaker 3: what I mean by that is we started off with
Speaker 3: virtualization back up and then got into cloud based and
Speaker 3: SaaS based and even communities based backups. So running state
Speaker 3: for workloads, running databases, you name it, will protect it
Speaker 3: type of thing. And the important part is is back
Speaker 3: up is the boring part. The recovery is the the
Speaker 3: easy part. But I guess more to the point where
Speaker 3: where you came in Will was around the project that
Speaker 3: I started kind of as we came out of the
Speaker 3: or even the last year of the pandemic was ninety
Speaker 3: days of DevOps And if you go to ninety days
Speaker 3: at DevOps dot com, it was really about learning in public,
Speaker 3: like being vulnerable and putting some structured learning out there.
Speaker 3: It never was intended to be as big as this
Speaker 3: to help as many people. It was there to help me.
Speaker 3: It's just it started out as my notes, right, which
Speaker 3: my Twitter is a graveyard of notes really that I'm
Speaker 3: just shouting in my own little bubble. But yeah, been
Speaker 3: in the infrastructure world for twenty years. I would say
Speaker 3: the last three to five years has been focused around
Speaker 3: DevOps and then more recently around cloud and cloud Native.
Speaker 3: So yeah, definitely listening to the podcast and taking a
Speaker 3: lot in so yeah.
Speaker 1: Right, and so ninety days of DevOps was your like
Speaker 1: learning and public thing, but that's been more than ninety
Speaker 1: days ago. So what's the current state of that.
Speaker 3: Yeah, So we started in twenty twenty two, I think
Speaker 3: it was, and that was me going through the weird
Speaker 3: roads of DevOps, if you will, And I didn't want,
Speaker 3: like I've seen loads of people do one hundred days
Speaker 3: of code or one hundred days of communeties and one
Speaker 3: hundred days of this and one hundred days of cloud
Speaker 3: and I was like, I can't concentrate for one hundred days.
Speaker 3: I can't do that. And DevOps isn't you can't do it. Look,
Speaker 3: DevOps isn't just one area right as you as you
Speaker 3: all know. So I took that concept of ninety days
Speaker 3: of DevOps and this was This was on New Year's
Speaker 3: Eve as we were going into twenty twenty two. We're
Speaker 3: just in a pandemic and as most of my my
Speaker 3: friends would be out drinking, I'm sat at home going right,
Speaker 3: how do we kickstart this year? And normally it's a
Speaker 3: fitness challenge for ninety days or something like that. This
Speaker 3: year was no. What we're going to do is we're
Speaker 3: going to we're going to start a get repository and
Speaker 3: we're going to start loads of markdown files and we're
Speaker 3: going to go through twelve or thirteen different topics of
Speaker 3: DevOps and we're going to not deep dive into them,
Speaker 3: but we're going to get a little bit. We're going
Speaker 3: to get we're going to get the big picture, we're
Speaker 3: going to get some theory around that, and we're going
Speaker 3: to get some hands on over all of these weird
Speaker 3: and wonderful words that we see in the in the industry.
Speaker 3: So there's a top pick around go, but go lang
Speaker 3: not as a developer. I'm not a developer by any stretch,
Speaker 3: But what does the programming language look like? From a
Speaker 3: DevOps point of view? We need to know Maybe we
Speaker 3: need to know how to read the code, just understand it.
Speaker 3: Maybe we do need to understand how to create a
Speaker 3: little a little bit better than a bast script on
Speaker 3: how to achieve some automation. There's cumunetties in their containerization,
Speaker 3: Linux networking, all of that and how it pertains to
Speaker 3: the DevOps topic. So that was the first year. It
Speaker 3: was one hundred and ten thousand words. It was basically
Speaker 3: a blogger day for ninety days. We fast forward to
Speaker 3: twenty twenty three and instead of me doing that, and
Speaker 3: I missed out so much around security, and I think
Speaker 3: the world missed out on. If you think about twenty
Speaker 3: twenty two, DevOps was the thing. Dev scops was the
Speaker 3: new thing as we went through twenty twenty three or
Speaker 3: twenty twenty two into twenty twenty three. So I went
Speaker 3: out to some friends and they as SMEs, they subject
Speaker 3: matter experts. They came out and they provided the blog
Speaker 3: posts for each day of their section for the twenty
Speaker 3: twenty three edition and then just recently of March the
Speaker 3: thirty first, we finished ninety days again. But I wanted
Speaker 3: to we couldn't just do let's write a load more things,
Speaker 3: and I wanted to change up what that was. So
Speaker 3: we put out a call for papers and we actually
Speaker 3: had ninety one sessions from ninety one different people. It
Speaker 3: was ninety one for a reason. It was a leap
Speaker 3: year this year, and so yeah, we had all of those,
Speaker 3: all of those sessions on YouTube as well. So it
Speaker 3: was about changing the format of what.
Speaker 1: It was, greight Ie. So just taking the different topics
Speaker 1: and then dedicating a day to each of those topics
Speaker 1: so that you can do, you know, a little bit
Speaker 1: deeper than just Hello World on those and kind of
Speaker 1: walk away with not like an expert level knowledge, but
Speaker 1: like a conversational knowledge of that topic.
Speaker 3: Yeah, exactly that. It was probably seven days for each
Speaker 3: of the topics. So we kicked off the first the
Speaker 3: first ninety days in twenty twenty two was what is
Speaker 3: DevOps Like I've seen your videos, will that that kind
Speaker 3: of touches on on this and it was about like, so,
Speaker 3: what is DevOps and why DevOps and where did it
Speaker 3: even come from? And why are we talking about it
Speaker 3: in twenty twenty two when it's been around since two
Speaker 3: thousand and nine, like that sort of thing, and some
Speaker 3: of the use cases. And it's always the use cases
Speaker 3: that we hear about. Oh it's Netflix did this, Aws
Speaker 3: did that? It's so I wanted to actually, well, what
Speaker 3: about the company down the road, how are they using DevOps?
Speaker 3: So we went into a little bit more of a
Speaker 3: DevOps for the normal the normal company, not the fan company,
Speaker 3: and then we kick off for seven days of like, so,
Speaker 3: the first topic is go Lang learning a programming language,
Speaker 3: and there was a mixed uh. I got mixed feedback
Speaker 3: on that because really, I'd be interested in what your
Speaker 3: programming language or choice would be to learn first. From
Speaker 3: a DevOps point of view, I expect I know what
Speaker 3: the answer would be, but I'd be interested in your takes.
Speaker 1: Yeah, for me, my answer is very nuanced, Like my
Speaker 1: first answer is what's the team you're working with using?
Speaker 1: You know, because if like you're working with a full
Speaker 1: four stack JavaScript shop, just go with that so that
Speaker 1: you have some more connective tissue with the rest of
Speaker 1: your team. I think that's going to serve you much
Speaker 1: much more long term in helping that team then learning
Speaker 1: Go and being like the outsider who's always trying to
Speaker 1: sell this, you know. So I approach it from a
Speaker 1: conversational point of view, where am I going to have
Speaker 1: the most conversation touch points with the people that I'm supporting,
Speaker 1: and so whatever their primary stack is would be my
Speaker 1: first choice. Assuming that you know they're not using Java.
Speaker 1: I wouldn't recommend Java the first language, but if you
Speaker 1: if the fields wide open, you know, I would. I
Speaker 1: think I would just stick with I would I would
Speaker 1: recommend Go. It's just to me, it feels it feels
Speaker 1: very manageable to pick up as a first language.
Speaker 4: Yeah, yeah, yeah, for sure.
Speaker 2: I mean I think, well, well, now the most important
Speaker 2: part here, which is really the context. I mean, if
Speaker 2: we think about what DevOps is, it's really about merging
Speaker 2: of the mind sets and applying it no matter where
Speaker 2: you are, so meeting the team where they're at, and
Speaker 2: I don't think i've sort I often will advise companies
Speaker 2: and their engineering departments are using all sorts of strange
Speaker 2: things that I would never personally use. Will mention Java
Speaker 2: but I've seen Ruby and everything else, and there are
Speaker 2: some languages that I prefer to use personally more than
Speaker 2: more than others.
Speaker 4: And I see sort of.
Speaker 2: Concrete problems that show up because of the language of choice,
Speaker 2: and you can maybe overcome those by picking something different.
Speaker 2: Right the sorts of problems, you'll end up with a
Speaker 2: non strong type language versus ones such as Go or
Speaker 2: rusts or whatever. You know, there are concrete benefits of
Speaker 2: using those. But when you think about here's where the
Speaker 2: team is at, what is the problem that we need
Speaker 2: to solve, trying to pull in the tools to help
Speaker 2: you do it and not necessarily going out and changing
Speaker 2: the language. Although you know, I've seen often there is
Speaker 2: this problem where a team may not be able to
Speaker 2: embody the mindset that comes with because potentially the language
Speaker 2: or frameworks that they're using, they're just not conducive to
Speaker 2: thinking about those things. There's still a very much built
Speaker 2: in you use this language language thinks about throwing stuff
Speaker 2: over the wall to another team to go and run it.
Speaker 2: You're going to run into a problem there, and sometimes
Speaker 2: you got to change the tools to match we want.
Speaker 2: But you know, if we're looking on the other side.
Speaker 4: You know what would I pick.
Speaker 2: Personally, I've been super successful with Joba's script type script
Speaker 2: and RUSS, but I don't think the domain is super
Speaker 2: critical there No.
Speaker 3: And you both you both hit on it right. And
Speaker 3: the reason I chose Go because being cast in an
Speaker 3: acquisition that we'd made in twenty twenty, they were using
Speaker 3: Go lang to write their cloud native products. I didn't
Speaker 3: know Go and in fact I didn't know any programming language.
Speaker 3: So that seemed like a good start. But the amount
Speaker 3: of people that were like, you should this should be Python,
Speaker 3: this should be Python, or this should be something else.
Speaker 3: And I get that, but to both of your point,
Speaker 3: but I chose it for that reason, and I documented
Speaker 3: and bearing in mind we're on day I think we
Speaker 3: start this on day seven, the first time I've ever
Speaker 3: done this, And this is me writing notes like me
Speaker 3: and my mum know about this. That's it. So it's
Speaker 3: it's it didn't turn out to be the twenty five
Speaker 3: thousand plus stars that are on gethub for it now.
Speaker 3: I can understand that then. But but and we covered
Speaker 3: Python in the second year as well, and there's obviously
Speaker 3: so many more, but it's about it was for me.
Speaker 3: It was so I could actually and it wasn't for
Speaker 3: me to have become a Go developer, because I don't.
Speaker 3: I think the point is is a programming language for
Speaker 3: devots is very different to being an app developer in
Speaker 3: that I just want to be able to read this language.
Speaker 3: I want to be able to potentially make a CLI
Speaker 3: or some sort of tool that helps with my day
Speaker 3: to day job. And the fact is is that Go
Speaker 3: is a great language for that sore so are others,
Speaker 3: but I chose it for them read So I did
Speaker 3: point that out in there as well. But basically just
Speaker 3: to go back to why, like how how these modules
Speaker 3: if you will, like set up, is that the first
Speaker 3: day we talk about programming languages in DevOps. So I
Speaker 3: went away and I researched that for generally, I would
Speaker 3: have spent about an hour two hours watching YouTube videos.
Speaker 3: A lot of yours will as well, and and others
Speaker 3: the smart people, and they're all referenced at the bottom
Speaker 3: of that the days as well. Right, I'm not again,
Speaker 3: this isn't This wasn't anything for me. This is about
Speaker 3: providing structured learning that we didn't have, and I still
Speaker 3: don't think. I'm not the answer to this is that
Speaker 3: oh learn DevOps, but Will's DevOps journey and yours, Warren
Speaker 3: and mine are all different. And if we work at
Speaker 3: three different companies and your DevOps responsibilities are very different
Speaker 3: as well, Like we might touch the same similar things,
Speaker 3: but everything is everything is a little bit different, and
Speaker 3: it's more of a mindset on how can I learn
Speaker 3: quickly to understand the benefit of this, and if it's
Speaker 3: not right, throw it in the bin, let's go again,
Speaker 3: Like that's the that's the premise. But I didn't. I
Speaker 3: couldn't find that one YouTuber that was like, well, fixing
Speaker 3: my addiction to YouTube following the pandemic that so many
Speaker 3: people had. So I thought, well, I'm going to create
Speaker 3: something that at least will help me because I forget everything,
Speaker 3: so I want to be able to go back and
Speaker 3: reference this. So we go through the big picture, We
Speaker 3: go through a bit of theory about what go is,
Speaker 3: how it works, how it compiles, blah blah blah. Then
Speaker 3: we get hands on and we start interacting with the
Speaker 3: Twitter API that's now been changed so that I need
Speaker 3: to update that. But it was basically a little Twitter
Speaker 3: butt that would that you could write a bit bit
Speaker 3: more of that, like two oh one of the Hello world,
Speaker 3: how can I interact with an API to make it
Speaker 3: do something as and when something happens. So that long winded,
Speaker 3: that was what we started with. But each one of
Speaker 3: those sections, those modules takes that big picture, a bit
Speaker 3: of theory, and then some hands onto that.
Speaker 2: I mean, I think really shouldn't undersell this here. I mean,
Speaker 2: you've got a repository on GitHub that has over twenty
Speaker 2: six thousand stars and which really is which I know
Speaker 2: for sure, and in such a short period of time
Speaker 2: it seems, and it's really just you going and learning
Speaker 2: these individual topics one after another one to a sufficient
Speaker 2: degree that other people can go in and see it
Speaker 2: and get that same sort of learning. And really it's
Speaker 2: not about the maybe physical tool, but the real mindset
Speaker 2: that's behind DevOps and having a whole new approach that
Speaker 2: they can take to even their own projects or back
Speaker 2: to their workplace and share it with others.
Speaker 3: Yeah, it's it's been a it's been wild a while
Speaker 3: three years, that's for sure. And bringing on all of
Speaker 3: the community members to do the talks. Like if you
Speaker 3: look at some of those sessions, some of those are
Speaker 3: like gold, They're the sessions that you'd go to if
Speaker 3: you went, if you went to conferences, they're the ones
Speaker 3: that you'd actively like, are what I need to see
Speaker 3: this and perspective is so important in our in our
Speaker 3: DevOps world. Is that again, just because I do something
Speaker 3: my way and that's my responsibility, it won't be the
Speaker 3: same as what will does or you weren't. So seeing
Speaker 3: these all these different sessions on a w S as
Speaker 3: your terrorform pollu me like all of the I guess
Speaker 3: competing products, but with a bit of an overlap as well,
Speaker 3: like it's pick it's about picking your picking, picking your horse, right,
Speaker 3: and but you can swap horses halfway through, like the
Speaker 3: amount of pollue me and Hashi Corp as well. So yeah,
Speaker 3: I just I'm in a position as well at being
Speaker 3: where they give me the opportunity to do this, which
Speaker 3: is incredible. You think three years ago, pre pandemic, I
Speaker 3: was purely focused on storage and virtualization. I've done a
Speaker 3: bit of terror form, I've done a bit of answerable,
Speaker 3: I've done a bit of cloud, but that was it.
Speaker 3: Thrown me into this, gave me the opportunity to then
Speaker 3: go and learn a whole new community, a whole new ecosystem,
Speaker 3: whilst still getting paid for it. I started a new
Speaker 3: job without having to start a new job, so it is,
Speaker 3: it's incredible, Like all of the community. There's a discord
Speaker 3: channel as well, with over a thousand people in there.
Speaker 3: It's brilliant and like always already being asked what we're
Speaker 3: doing next year, Well, we have to take a year
Speaker 3: to figure that out.
Speaker 2: You touched on something I think really important, and that's
Speaker 2: especially in the DevOps mindset sort of corner of the
Speaker 2: world that we end up finding ourselves in. We don't
Speaker 2: usually have experienced mentors that are within the same company
Speaker 2: or same organizational areas as us, and it can be
Speaker 2: quite the challenge of actually figuring out how to level
Speaker 2: up effectively within that scope. And you know, my usual
Speaker 2: recommendation is, you know, where are you getting information from
Speaker 2: the outside world that that's happening outside your company, and
Speaker 2: there's usually silence there. Like obviously there's some amount of
Speaker 2: challenge to engage yourself with content or other companies because
Speaker 2: not everything is public, So going out and actually finding
Speaker 2: good streams of information is for sure actually a challenge,
Speaker 2: but it's something that everyone who has a devlop, you know,
Speaker 2: is embodying the devofs mindset really needs to do in
Speaker 2: some regard.
Speaker 3: Interesting, you say that as well, that so the dead
Speaker 3: stats that you can get on the repo't I'll let
Speaker 3: the audience go and look up the big big companies
Speaker 3: that are behind it, and that they're not contacted anything.
Speaker 3: But there's some pretty big, big, big big vendors out
Speaker 3: there that are using this for what I can only
Speaker 3: see as a bit of an onboarding, like an onboarding
Speaker 3: kind of course, for their for their people.
Speaker 4: Interesting.
Speaker 3: To be fair, I don't do any sponsorship or anything
Speaker 3: like that on there, so there's no real way for
Speaker 3: them to reach out for that.
Speaker 2: I could imagine companies reaching out to you though, and
Speaker 2: asking you to come and actually speak or you know,
Speaker 2: pick some of your favorite modules that are fit for
Speaker 2: their company and getting to actually talk through or workshop them.
Speaker 3: So if it all goes wrong at them, maybe that's
Speaker 3: maybe that's the way to go. But I made it,
Speaker 3: I made it quite clear earlier on but none of
Speaker 3: this is sponsored content. So if I chose rg CD
Speaker 3: is because I wanted to, there was no there was
Speaker 3: no influence at all, And I had another how can
Speaker 3: I put this without name in names? But everyone will
Speaker 3: know if I say it, a typical database company that
Speaker 3: have a very strong licensing opinion, they reached out about
Speaker 3: their cloud infrastructure and they wanted me to cover them
Speaker 3: and they pay and that's what And I said, but
Speaker 3: that's going to lose the spirit of the of the
Speaker 3: whole whole process, like I could do. And I can
Speaker 3: say this because I'm a Hashi Corp ambassador and it
Speaker 3: wasn't then. But I've suggested I could do seven days
Speaker 3: of Hashi Corp. We could go through seven products. We
Speaker 3: could do ten days of Hashi Corp. I think probably,
Speaker 3: And that would be a great idea. But it'd have
Speaker 3: to be organic content. It wouldn't be you tell me
Speaker 3: what to write, you pay me to do that, because
Speaker 3: you lose the trust with the community a lot of
Speaker 3: the time with that element of of why we do
Speaker 3: this stuff, and really the whole again, it goes back
Speaker 3: to the reason why I did this? Why did I
Speaker 3: start this? Because obviously when you start a project, you
Speaker 3: start with a logo and you start with a domain.
Speaker 3: That's before you even get into any of the hard work.
Speaker 3: It was it was all about it was all about learning.
Speaker 3: It was all about me just learning in public I've
Speaker 3: been around several different communities virtualization, VMware, NETAP from a
Speaker 3: storage perspective, Hashi Korp was then there on the edge
Speaker 3: before I jumped into the more of the cloud and
Speaker 3: cloud native world, and there's never been that. I had
Speaker 3: a conversation about this the other the other week about
Speaker 3: it's all about putting down the ladder. Use the ladder
Speaker 3: to get up. You might have used some videos, some
Speaker 3: content somewhere, and you can there's some people in this
Speaker 3: world that will absolutely take that ladder with them and
Speaker 3: they're never going to drop it down. If you can
Speaker 3: drop that down and help one person, then it's going
Speaker 3: to be massively impactful for that person wherever they are
Speaker 3: in the world. Right, And I've had that same ethos
Speaker 3: from doing blogs about open Stack fifteen years ago, is
Speaker 3: that even if you document something, blogs something and it
Speaker 3: only helps one person, then it's worth doing again. Same
Speaker 3: for this, right. That's why I did it on an
Speaker 3: open get hub RePOP was if it helps one person,
Speaker 3: then it's worth worth doing. And it helped me as well,
Speaker 3: so that was why.
Speaker 1: Yeah, And I think it's admirable just to avoid the
Speaker 1: sponsorship route because you know, like you're putting in a
Speaker 1: ton of time and effort on nursuit, like not only
Speaker 1: just to learn your own thing, but because you're you're
Speaker 1: trying to do it in public and you're trying to
Speaker 1: share it so that it is helpful for someone else.
Speaker 1: So that puts a lot of additional steps in achieving
Speaker 1: a task, you know, because you could have done this
Speaker 1: yourself in a notepad doc on your desktop and gotten
Speaker 1: all the benefits there. But choosing to share it, you know,
Speaker 1: as an extra level of work to it. That's a
Speaker 1: huge time commitment. And I think that's part of the
Speaker 1: allure of doing sponsored videos or taking on sponsorships, because
Speaker 1: it helps you feel like you're justifying some of that time.
Speaker 1: But at the same time, I agree with you whenever
Speaker 1: you choose to take on the sponsorship, in my mind,
Speaker 1: that changes the scope of work because now instead of
Speaker 1: creating something for me to share, I have to create
Speaker 1: something for the sponsor that represents their brand. And those
Speaker 1: are in some and sometimes two entirely different pieces of content.
Speaker 3: Absolutely, and I know, I know that there's a day
Speaker 3: and I'll let I'll let people go and find the day.
Speaker 3: But where I'm trying to get not Antimle. I'm trying
Speaker 3: to get Jenkins up and running a doctor container, which
Speaker 3: it clearly wasn't built for this situation right now. But
Speaker 3: we're like even in the comments, I know there's a
Speaker 3: paragraph there going I couldn't get this to work. Then
Speaker 3: there's an update. I got this to work, but I
Speaker 3: had to do this, this, this, and this and that.
Speaker 3: I left it all in because people will have that
Speaker 3: same problem. They'll have that same issue. And but if
Speaker 3: that was if that was Jenkins paying for said said
Speaker 3: blog or said YouTube video, they wouldn't want me to fail.
Speaker 3: They'd want it to be clean, crisp cut, like this
Speaker 3: is how it works. Now. I know that's not that's
Speaker 3: not fair to all vendors or projects out there. Some
Speaker 3: will like to see the like warts and all, but
Speaker 3: the majority would one hundred percent want it to be
Speaker 3: clean cut and look how good our software is.
Speaker 2: Yeah, for sure, I think there's a huge brand component
Speaker 2: to this. Like when you're going out and you're creating
Speaker 2: content for the world, what does that say about the
Speaker 2: person who is creating that content realistically? And you take
Speaker 2: that with you when you go somewhere else. If you
Speaker 2: want to be someone who sells your content. You know
Speaker 2: that's your job or that's who you want to be,
Speaker 2: then you know there's something wrong with that. If you
Speaker 2: want to be someone who creates publicly available content, you
Speaker 2: know that becomes part of your brand. And I feel
Speaker 2: like at the upper echelon levels of software engineering, there
Speaker 2: is this expectation that you are positively contributing to the community,
Speaker 2: and I feel like going out and selling your content
Speaker 2: isn't necessarily aligned with that. Being able to provide it
Speaker 2: for free or at conferences or through trainings.
Speaker 4: Workshops, et cetera.
Speaker 2: There's a very different perspective there, and I don't think
Speaker 2: we can get as far with just only sponsored content,
Speaker 2: as you said, for the obvious reasons of companies paying
Speaker 2: for I mean, if you're doing that, then you're likely
Speaker 2: going to end up competing with llms in the future
Speaker 2: who are going to optimize for just getting the work
Speaker 2: done rather than the actual you know, learning experience.
Speaker 3: Not an issue.
Speaker 1: No, No LLM can butcher the English language as badly
Speaker 1: as I can. I've got that market coy.
Speaker 3: Yeah, you wouldn't believe the amount of contributions on the
Speaker 3: repo as well for a native English guy making mistakes
Speaker 3: it's a green it's a green tip, it's a green box, right,
Speaker 3: you can people have Well, the mind blowing thing is
Speaker 3: not only that, but there is a of a lot
Speaker 3: of spelling and grammar mistakes that have been corrected. But equally,
Speaker 3: it's been translated into different languages. If you go if
Speaker 3: you go to the to the repo and you go
Speaker 3: to twenty twenty two at the top there you'll see
Speaker 3: it's been translated into Vietnamese, Chinese, Polish. It's not ridiculous,
Speaker 3: it's amazing, but it's ridiculous. That's so cool. I just hope,
Speaker 3: I hope they're not writing anything bad about me.
Speaker 1: So what kind of feedback? I mean, obviously with twenty
Speaker 1: six thousand stars, you know, there's been You've hit a
Speaker 1: chord in the community. It's definitely appreciated content. Have you gotten,
Speaker 1: like any any success stories or like really cool feedback moments,
Speaker 1: because I know, just in the YouTube videos I've done,
Speaker 1: there's been a few people who have reached out to
Speaker 1: me over the years and said, hey, I watched your
Speaker 1: videos and did the things that you suggested in this
Speaker 1: particular video, and it helped me land my first job,
Speaker 1: you know, and to me like that was just mind blowing.
Speaker 1: I don't know what the rest of my life holds,
Speaker 1: but to hear something like that, like you had that
Speaker 1: kind of impact on someone's life, Like that's crowning achievement
Speaker 1: to me. So what what have you gotten back for
Speaker 1: feedback from this?
Speaker 3: So so similar will similar things like people that are
Speaker 3: just starting out of college and they'll use the REPO
Speaker 3: and oh, I landed my first job. And also I
Speaker 3: think personal like so personally that's brilliant, like the same
Speaker 3: as you will. Like to think that I would ever
Speaker 3: have an impact on anyone's life is incredible, Like I
Speaker 3: never thought it. Probably the same as you is that
Speaker 3: I never thought that that would be a thing. I
Speaker 3: didn't think i'd build something that would impact someone, but
Speaker 3: equally on a on a personal level as well. It's
Speaker 3: enabled me to go and speak at events. I've always
Speaker 3: done public speaking from a again virtualization storage like vm
Speaker 3: World before it was VMware Explore all of that. I've
Speaker 3: done the yearly conference trips, but I hadn't done the
Speaker 3: DevOps conference trips. I hadn't been to HASHIKM, I hadn't
Speaker 3: been to other like uh we are developers for example,
Speaker 3: and I strongly believe that doing this gave me a
Speaker 3: little bit more credibility to be able to go and
Speaker 3: do that. And I think to your point, Warren, I
Speaker 3: think also the amount of people that I've had reached
Speaker 3: out to me saying like, if it doesn't if it
Speaker 3: doesn't work out, a beam, but just give us a
Speaker 3: give us a ring. But because that's it's a it's
Speaker 3: a community angle that they see that they could they
Speaker 3: could use within their within their efforts in the community
Speaker 3: as well. But yeah, I think I think overall is
Speaker 3: it's about helping helping people. That's the that's the biggest thing.
Speaker 3: And then yeah, the thought leadership or the ability to
Speaker 3: be validated to go and speak at these events is
Speaker 3: nice and quite frankly strange as well, but people speak
Speaker 3: about it. I think the one, the one that really
Speaker 3: hits home for me is the Hashi Hashi comp when
Speaker 3: it was in Amsterdam two years ago. I was speaking
Speaker 3: there and it was they asked me to speak about
Speaker 3: ninety days of DeVos. It was like a fifteen to
Speaker 3: twenty minute type community session and it was equally quite
Speaker 3: strange to talk about it then, and bearing in mind
Speaker 3: that's two years ago, we'd only just finished that first one.
Speaker 3: We were probably on ten thousand stars, and then having
Speaker 3: people come up to you and say, this is amazing,
Speaker 3: I can't believe I haven't seen it. And to your
Speaker 3: initial point, will like, you only hear about it on
Speaker 3: Twitter or on x but I need to be better
Speaker 3: at sharing this stuff as well elsewhere.
Speaker 1: That's the hard part, you know, I think, because that
Speaker 1: requires a completely different set of skills to promote your work,
Speaker 1: and you have to learn those, and it feels very
Speaker 1: awkward to learn those, you know, especially whenever you take
Speaker 1: this from the approach of like, I'm just doing this
Speaker 1: to to maintain my own skill set in my chosen
Speaker 1: career path, you know, and then you have you turn
Speaker 1: that around, you're like, oh, how do I promote myself
Speaker 1: and market my content that was never really meant to
Speaker 1: be content anyway? And I remember, like, the one of
Speaker 1: the key moments for me was the first time I
Speaker 1: had to write a bio for a talk I was giving,
Speaker 1: you know, and you're you write, you write your own
Speaker 1: bio in the third person, and you know, to me,
Speaker 1: that was just like blue screen of death in the brain,
Speaker 1: you know, I just couldn't wrap my hair around that.
Speaker 3: Yeah, yeah, I get exactly the same anything about myself.
Speaker 3: Is that to your point worry like whatever this is,
Speaker 3: it doesn't It just feels strange of like how how
Speaker 3: big it's become or even And I'm a I'm a
Speaker 3: ultimately I'm a pessimist at heart anyway in that you
Speaker 3: look at those those twenty five thousand stars and I
Speaker 3: just said, like are they important? Are they just vanity metrics?
Speaker 3: If that was software, you'd be up there with one
Speaker 3: of the biggest And I'm like, that's that's crazy. So
Speaker 3: so yeah, it's it's it's a it's an interesting and
Speaker 3: I've seen others as well do like follow that into
Speaker 3: like creating content, sharing in public and all of that
Speaker 3: good stuff, and and yeah, it's been a yeah, it's
Speaker 3: been good, like people cloning the repository and then going
Speaker 3: off and doing their own journey, which was kind of
Speaker 3: the idea as well, in that if I could, if
Speaker 3: you could build a template repo for people to go
Speaker 3: and walk and talk the same thing. You go and learn,
Speaker 3: and then you get a perspective and then we start
Speaker 3: sharing lots lots of different perspectives. That's we're all going
Speaker 3: to learn a lot more and Warren, actually, you brought
Speaker 3: up a good point and someone else said about this.
Speaker 3: Are you worried about LM's having all of this information?
Speaker 3: I'm like, well, I didn't make it up. This information
Speaker 3: is fully available if you go to the bottom of
Speaker 3: each day. There's smarter people than me talking about this
Speaker 3: stuff all over the internet, and there's heaps of documentation
Speaker 3: that touches on all of this. If an LM can
Speaker 3: take ninety days of devop to make things easier, let's
Speaker 3: go like that's only a good thing as well. So yeah,
Speaker 3: for sure.
Speaker 1: So one thing I want to talk about with you
Speaker 1: because you've got you know, you're you're all at them
Speaker 1: and then you're creating the US on the side. And
Speaker 1: then I know that you're also active physically, So how
Speaker 1: do you structure your day or what's your thought process
Speaker 1: for balancing those different areas of your life.
Speaker 3: No, that's a good one. I don't know if I
Speaker 3: balance anything, but and for anyone that follows me on
Speaker 3: any social media, you know that I spend more time
Speaker 3: on a plane than I do in my own bed,
Speaker 3: or at least in a different country. And the one
Speaker 3: thing I absolutely love about working for VEMA and I'm
Speaker 3: sure other companies are like it. That my opportunity is,
Speaker 3: or my goal or my responsibility at being is to
Speaker 3: raise awareness and drive some sort of adoption to our software.
Speaker 3: Now we have community addition and open source projects that
Speaker 3: to me is still driving adoption, and then we obviously
Speaker 3: have paid for products as well. And raising awareness is
Speaker 3: what I can do best by talking at events, talking
Speaker 3: about what we do, some cool use cases that we
Speaker 3: see out there in the field, and that means jumping
Speaker 3: on a plane generally and being and giving those those
Speaker 3: sessions at things like red Hat Summit, Cube Con, Hashi,
Speaker 3: KOMPF and others. But the other great thing about them
Speaker 3: is that well, every day's every day is different. And
Speaker 3: you could wake up at eight o'clock on Monday morning
Speaker 3: and you think this is what we're going into and
Speaker 3: then by nine o'clock is completely different and your day change.
Speaker 3: That every day can be different at them, and that's
Speaker 3: the exciting bit. And because over the last ten years,
Speaker 3: I've been at Beam for nine and a half years now.
Speaker 3: So I started and we only had virtual machine backup
Speaker 3: VMware backups, and now we have we can back up everything,
Speaker 3: so I can I can flip and change, and there's
Speaker 3: all the different communities for each of those different different services,
Speaker 3: and diving into that learning something new, being able to
Speaker 3: like just the variety is the wind for me to
Speaker 3: keep that now. The one thing I've started this year,
Speaker 3: or actually just before Christmas because I've stopped playing rugby,
Speaker 3: is at least moving five k a day. So walking
Speaker 3: five k day or running five k a day has
Speaker 3: been like, I have to do that because sometimes you
Speaker 3: can have. I've just spun off ten of those different
Speaker 3: things that we've got that becomes overwhelming when you and
Speaker 3: I don't know what number it is, whether it's twelve
Speaker 3: or fifteen things on my plate, but one of those
Speaker 3: numbers sends me over the edge. And I'm sure you're
Speaker 3: the same, right. So being able to go for a
Speaker 3: walk somewhere and just out and about somewhere else or
Speaker 3: run it just gives you that level set, that reset.
Speaker 3: But equally, I don't work nine to five. I don't
Speaker 3: think many of us do any more. I think it's
Speaker 3: a nice like when it's light we work and when
Speaker 3: it's dark we sleep. But I don't think that. I
Speaker 3: don't think that masses anymore. I think we just get
Speaker 3: stuff done.
Speaker 2: I thought, for sure you're gonna say when it's dark
Speaker 2: you also work because.
Speaker 3: It depends on the week right all time zone, for sure?
Speaker 1: For sure.
Speaker 4: I mean my numbers too.
Speaker 2: I feel like if I got something critical going on,
Speaker 2: something else trying to buy from my attention, I have
Speaker 2: to be very careful about pulling that in. I think
Speaker 2: I'm in a very unique position though compared to lots
Speaker 2: of people, where I get to push things on other people,
Speaker 2: So I have to be careful about that. But yeah,
Speaker 2: for sure, like things to buy for your attention, it's
Speaker 2: very difficult to even keep track of them all. I
Speaker 2: was actually talking to Will about this before we started
Speaker 2: the stream about multitasking is death now, Really, we as
Speaker 2: humans can't really do it that effectively. Your priority list,
Speaker 2: you do one at a time until you're done, but
Speaker 2: you're never done. There's the next thing on the list.
Speaker 2: So rigorously prioritizing and pulling out what those things are important.
Speaker 2: And I think there's a lot to be said for
Speaker 2: your subconscious because I'm totally with you. I go on
Speaker 2: short little walks to clear my mind, my conscious mind
Speaker 2: while subconsciously I'm working on some difficult problem that doesn't
Speaker 2: require me to write it down or look at visuals
Speaker 2: can be really really helpful, especially when the nature of
Speaker 2: the work we're doing. It's not just write some code
Speaker 2: in some ID somewhere, but it's think deeply about a
Speaker 2: problem and how it should look like and what that
Speaker 2: actually means.
Speaker 4: And how to take the next step.
Speaker 2: And so while you say that you don't have anything
Speaker 2: like super original there that you know, you pull the
Speaker 2: content from somewhere. I think what is important is how
Speaker 2: you think about the problem, which I do think may
Speaker 2: be unique to you know, everyone involved.
Speaker 4: And I think that's important and worth remembering.
Speaker 1: So back to doing a five k every day, I'm
Speaker 1: going to dig on this. Do you listen to music when.
Speaker 2: You do that?
Speaker 1: Or podcast or.
Speaker 3: Running? I'm running, I will listen to music if I'm
Speaker 3: if i'm walking, it depends depends on where I'm walking.
Speaker 3: If I'm walking on a treadmill, in the in the
Speaker 3: in the gym, or in the in the living room,
Speaker 3: I will. That's that's YouTube time. But it's it's not.
Speaker 3: It's not DevOps or tech YouTube time. That's although Jeff
Speaker 3: Jeff Gilling seems to the sneak in there because he
Speaker 3: does some some good good home lab stuff that I
Speaker 3: tend to watch, and yeah, maybe a podcast or two.
Speaker 3: But I spend a lot of time in a car
Speaker 3: as well, driving to the airport. I'm about ninety minutes
Speaker 3: away from the From the airport, it's a great time
Speaker 3: to listen to some really good podcasts.
Speaker 1: Right, how You've been with with them for nine years,
Speaker 1: which I feel like it's pretty unusual in our industry
Speaker 1: to be with the same company that long. What's the
Speaker 1: reason behind that?
Speaker 3: So I feel like I've had three, maybe four different
Speaker 3: jobs since I've been at Beam. So I started as
Speaker 3: an se SO systems engineer. I'll go out and keep
Speaker 3: our salespeople honest and so show prospect what we do,
Speaker 3: how do we protect this, what do we do? How
Speaker 3: do we do it? I was only doing it for
Speaker 3: eighteen months, But in that eighteen months, I was still
Speaker 3: creating content and I was still almost telling stories. Right
Speaker 3: the whole point, I would say, if you had to
Speaker 3: define what my job is, it's about telling stories. It's
Speaker 3: about telling Beam stories that I hear out in the
Speaker 3: field where much smarter people than me suffer, so that
Speaker 3: they have a story to tell, and then they tell
Speaker 3: me the story and I simplify that, put it into
Speaker 3: a demo some sort of story. After eighteen months, I
Speaker 3: moved into what we call now the Product Stratety Group
Speaker 3: or the office of the CTO, and this was full
Speaker 3: blown go anywhere, make noise, raise awareness, speak to engineering,
Speaker 3: build the product the way it needs to be for
Speaker 3: the field, go and speak to customers. Blah blah blah. Right,
Speaker 3: be part of the community we have. We have a
Speaker 3: great community around ving being just works. You've heard that
Speaker 3: tagline hopefully and yeah, we have some absolute fanboys who
Speaker 3: who love love being technologies, which is brilliant. So be
Speaker 3: present there, listen to them. What's their feedback is great
Speaker 3: as well, and then feed that back into engineering or
Speaker 3: product management. Then so yeah, that's that's the two jobs.
Speaker 3: Then in the same group I was I was, we
Speaker 3: made an acquisition of a company called Caston. Caston is
Speaker 3: focused on communities backup, so PVC is running applications data
Speaker 3: databases inside of communities or even outside. If you using
Speaker 3: URDS alongside of your application, we're protecting that. We made
Speaker 3: that purchase in October twenty twenty, the parachute got put
Speaker 3: on my back to go, go and make noise, go
Speaker 3: and go and be in that community about everything, all
Speaker 3: things communities like whoa, I've not even got I don't
Speaker 3: I've never done containerization yet, So I mean this is
Speaker 3: and this is the real start of the journey. You'll
Speaker 3: see where the devop scene comes in as well as
Speaker 3: we go through it. But yeah, parachute comes in, I
Speaker 3: go in. I'm still very wet behind the ears. I
Speaker 3: still am today, I feel. And that was my job
Speaker 3: is be all things focused on cloud Native. And I
Speaker 3: ended up running some collocated events at Cubicon called Cloud
Speaker 3: Native Data Management Day and we had some really good
Speaker 3: speakers talking about databases on Kubnetes, databases outside of communities,
Speaker 3: just data in general around that then probably, well it
Speaker 3: must be two and a bit years ago. I got
Speaker 3: handed some more stuff to look after and talk about.
Speaker 3: And it kind of fit because speaking to all of
Speaker 3: these kubunettes admins or even developers that were using communities,
Speaker 3: the the trend was they were never exclusively using just cubunettes.
Speaker 3: They were using virtual machines with databases on. Because the
Speaker 3: database is too hard to containerize, it was too important
Speaker 3: for everything else. Because traditionally we took that expensive Oracle
Speaker 3: database and we threw everything on. We threw everything into that.
Speaker 3: In the cloud native world, we don't need to do that,
Speaker 3: but that doesn't stop the plane still having to fly right.
Speaker 3: So anyway, so I got given the remit of now
Speaker 3: go and look after our cloud products are being back
Speaker 3: up for a ws as you'r and Google and come
Speaker 3: up with stories to tell around that. So I did,
Speaker 3: and then fast forward is now we're looking at how
Speaker 3: what is Beam's cloud strategy whilst also still trying to
Speaker 3: raise awareness drive adoption of everything that we're doing. So
Speaker 3: that's really so I think why nine years or how
Speaker 3: It's because I've had three to four different jobs within
Speaker 3: it within the company. To be fair, I've only reported
Speaker 3: into three different people as well, all in the same
Speaker 3: structure as well. But yeah, yeah, it's it's strange as well.
Speaker 3: When I was at when I was in my English
Speaker 3: class at school, and I'm sure you guys are the
Speaker 3: same in the in the States. You stood up and
Speaker 3: you read read like a chapter of the book or
Speaker 3: a couple of pages of the book out loud to
Speaker 3: the rest of your class. I was so scared I
Speaker 3: would almost have sick days because of that. And now
Speaker 3: I get to speak to you guys, or speak in
Speaker 3: front of audiences at events. It's a funny, this imposter
Speaker 3: syndrome is such a funny, funny situation.
Speaker 4: No, I can totally get that.
Speaker 2: As long as your career is changing in some way,
Speaker 2: migrating from one area to another one and having those
Speaker 2: different jobs even over a long tenure, the brand of
Speaker 2: the company that you're working for is sort of less
Speaker 2: relevant in a.
Speaker 4: Way because your role is growing with you and me
Speaker 4: be on that.
Speaker 2: I may ask in the context of the ninety days
Speaker 2: of devlops, has there been like some particular area that
Speaker 2: you really enjoyed learning more than others that maybe comes
Speaker 2: out more or as you know, more fleshed out, like
Speaker 2: you you see people gravitating towards more than some of
Speaker 2: the other areas, or you know, was particularly thing for you.
Speaker 3: So so for me personally, it was around databases, learning
Speaker 3: more about databases because I was in the traditional shop
Speaker 3: where Microsoft, Sequel, Oracle, and maybe we started to see
Speaker 3: a bit of Mango, but they were the three. They
Speaker 3: were the three de facto databases. Maybe some of my
Speaker 3: squel postgress, but now if you look at the cloud
Speaker 3: native ecosystem and the amount of databases that we have
Speaker 3: available to us. It's incredible, like you can really pick
Speaker 3: and choose the right tool for the right job. And
Speaker 3: I feel like that that could be the next space
Speaker 3: for like some huge, big hitter that that really changes
Speaker 3: what we do with data. And I've always been like
Speaker 3: a massive fan around like data visualization and being able
Speaker 3: to use data for for something good. So we're obviously
Speaker 3: backing up a lot of stuff. I would a lot
Speaker 3: have worked on prototypes where and take that data from
Speaker 3: our backup and glean some insight out of that. So
Speaker 3: that those were the two big areas in I guess
Speaker 3: they span twenty twenty two and twenty twenty three, two
Speaker 3: different topics that I think I probably could do a
Speaker 3: few more days on on there because I was learning
Speaker 3: a lot more about what is aws, neptune and just
Speaker 3: things that you like. I've personally never spoke to a
Speaker 3: customer that uses that and needs to protect it, so
Speaker 3: it's good. It's better that it's not glazed by oh,
Speaker 3: this is a customer meeting, you have to talk about this.
Speaker 3: It's actually my interest on data. Yeah, I don't know,
Speaker 3: like I think go lang and if I had a
Speaker 3: chance to change if I could go back and change it,
Speaker 3: knowing what I know now, I wouldn't have started talking
Speaker 3: about a programming language upfront, like we started talking about
Speaker 3: it here because it's the first module. I would have
Speaker 3: moved that because I feel like that is a barrier
Speaker 3: to entry, to think that someone, Oh, I'm gonna learn
Speaker 3: DevOps today. They come in, they've never learned a programming language. Oh,
Speaker 3: we've got to go and learn go Lang or Python
Speaker 3: or something. And you're like, maybe maybe that was just
Speaker 3: a little like, maybe I should have moved that down.
Speaker 3: Maybe maybe we should have started with the Linux module,
Speaker 3: which was second, and then the networking, and then we
Speaker 3: should have got onto a like containerization, and then I
Speaker 3: feel like there's a better, a better flow that I
Speaker 3: would have used. But the programming language. Do I really
Speaker 3: need to learn a programming language to be in DevOps? Well, actually,
Speaker 3: yeah no, you could probably get away with not until
Speaker 3: way down the line. You can you write a bass script?
Speaker 3: Are we classing that as a programming language? Probably not?
Speaker 3: But it gets it gets a job done, and it
Speaker 3: it might just be enough if you If you can't
Speaker 3: write a basscript, though, then probably don't bother learning Golang.
Speaker 3: Yet that's that's kind of yeah, So that would be
Speaker 3: that if I had any regrets, that would be that
Speaker 3: would be one to move.
Speaker 4: It's interesting you bring that up.
Speaker 2: Actually, I feel like it's easier to learn a programming
Speaker 2: language than it is to try to write a bash
Speaker 2: script correctly.
Speaker 4: And I think there is something to.
Speaker 2: Be said about the complexity of understanding what you're deploying
Speaker 2: or what you're running or what you're evaluating is can
Speaker 2: be quite complex, and I get the sense that learning
Speaker 2: a programming language is something that has well more complex
Speaker 2: to work with, has a much smaller impact, Like I
Speaker 2: can write a small little app on my machine and
Speaker 2: not have to think about what the data layer is
Speaker 2: going to be like, or what of the thousands of
Speaker 2: different kinds of databases out there providers you know which
Speaker 2: one to pick or even which cloud you go do,
Speaker 2: or how to deploy things, or you know, credit cards
Speaker 2: being involved and money to actually pay for those resources.
Speaker 2: Where I feel like all of that does come in
Speaker 2: to when you're working more in a DEUBL space, and
Speaker 2: so I can totally see the well, if you don't program,
Speaker 2: here may be is an easy way to get into it,
Speaker 2: rather than you know, immediately start trying to think about.
Speaker 4: What you're doing, because I think there is this hesitation or.
Speaker 2: Even maybe a crutch in the world where it's like,
Speaker 2: I want to go learn something infrastructure, What should I do?
Speaker 2: You know, what should I go? I was like, well,
Speaker 2: what's your business problem? You know, what are you actually
Speaker 2: trying to do? And then there's this disconnective Well, I
Speaker 2: don't know. I just want to learn how databases fit together.
Speaker 2: I'm like, well, it's a good start if you have
Speaker 2: a need, you know, like I want to build a
Speaker 2: recommendation engine or a website or something like that. And
Speaker 2: then I feel like you're sort of stuck if you
Speaker 2: don't have at least willing to go and take the
Speaker 2: step forward of building something out.
Speaker 3: Yeah, yeah, absolutely, you just made me think about So
Speaker 3: I have a lot of ideas. I'm sure you guys
Speaker 3: do as well, about little project, little project ideas, and
Speaker 3: I know this goes out to fair few people as well. Well.
Speaker 3: I'll be interested in what people think about source code,
Speaker 3: repository back up. Completely changing the direction, but think about gethub,
Speaker 3: think about get lab. How do we protect that and
Speaker 3: is it is it important just to go on the
Speaker 3: business outcomes I had that conversation this morning. I thought,
Speaker 3: I know two people that will that will have an
Speaker 3: answer or I have an idea or a theory on that.
Speaker 2: Well, well will want you to just you know, your
Speaker 2: code is backed up directly in production because that's where
Speaker 2: you're edited it right.
Speaker 1: Right right CICD means VIILM on the production server, and it's.
Speaker 2: Already replicated to multiple machines, right because you need to
Speaker 2: scale up, so you have you know, all your code
Speaker 2: automatically replicated to you know, tens, maybe hundreds, thousands of
Speaker 2: machines already.
Speaker 1: No, but that's that's actually a problem I've never thought of,
Speaker 1: you know, with get lab, for sure, because when I
Speaker 1: think of get lab, I think of running your own
Speaker 1: get lab servers on your own infrastructure. So there is
Speaker 1: a definite need there for GitHub. Though I'm paying for
Speaker 1: the service, I'm assuming and maybe that's my fault. I'm
Speaker 1: assuming that they're backing it up.
Speaker 2: You, I mean, realistically, you are paying for that. Then
Speaker 2: there's the second question of whether or not it's happening.
Speaker 2: And I think we know of recent like just recent
Speaker 2: incidents involving some companies who we thought would have had a.
Speaker 4: Better strategy to avoid a.
Speaker 2: Full incident related to individual customers losing all of their data.
Speaker 2: So I mean, realistically, it's something you could be concerned with,
Speaker 2: I think understanding the business continuity strategy that your company
Speaker 2: has or needs to have, and what the risk is
Speaker 2: and what the impact is of that. For instance, if
Speaker 2: you have lots of engineers who are working across multiple repositories,
Speaker 2: you have well defined teams with a well defined remit.
Speaker 2: I bet you've got the source code cloned end times already.
Speaker 4: It's unlike you actually do need something stronger than that.
Speaker 2: However, you're going to try to get fed ramp certification
Speaker 2: or ISO twenty seven KO one, you may actually need
Speaker 2: to do something else. And so I have seen people
Speaker 2: run if they're using GitHub or get lab managed, they'll
Speaker 2: run like get tea or something else, or another get
Speaker 2: provider and run some sort of script to back that up.
Speaker 2: Because while it's actually I think a really easy thing
Speaker 2: to do to actually achieve backing it up, the thing
Speaker 2: that another provider gets you is sort of the insurance.
Speaker 2: You want to be able to say, hey, while we
Speaker 2: can do it, we don't want to because you want
Speaker 2: to be able to have someone pay you or compensate
Speaker 2: you when it does go wrong. And if you're in
Speaker 2: charge of your own backup strategy, then you're almost you know,
Speaker 2: putting more of the eggs in that same basket, and
Speaker 2: so you really want to be careful there if you
Speaker 2: do decide to take ownership of it.
Speaker 1: So I feel like there's a story here, Michael, Like
Speaker 1: that didn't just come out of nowhere.
Speaker 3: So I write a blog post so I'll get asked
Speaker 3: about it the time, literally more than any other feature request.
Speaker 3: And we as a company have never never gone down
Speaker 3: that road because and I think to your point, Will
Speaker 3: like it's a SaaS and I'm talking about get up here.
Speaker 3: But we all trust Microsoft, don't we Microsoft don't get
Speaker 3: herb We all trust them. Yeah, they have data.
Speaker 1: I'm counting on the on.
Speaker 3: Yeah. And if they turn around and charge you on
Speaker 3: a per repo basis, we're going to get rid of
Speaker 3: a load of homegrown projects pretty damn quick because that
Speaker 3: just like I wrote a blog post where basically I'm
Speaker 3: using I'm using Canister. Canister is an open source project
Speaker 3: that we maintain that is more of an application freight
Speaker 3: application specific framework. And you can push this blueprint to
Speaker 3: go and put a lot basically interact with any API.
Speaker 3: And there's a great open source project out there, gick
Speaker 3: up gick up, and I use that basically to go
Speaker 3: and protect it and send it to S three just
Speaker 3: to say, look, we can do it, but if you
Speaker 3: want to do it, do it this way. Are other possible.
Speaker 3: But even then you're going to get hub and you
Speaker 3: go to the marketplace or the app store or whatever
Speaker 3: it's called. I think there's either fifty seven or one
Speaker 3: hundred and fifty seven back up tools natively in their marketplace.
Speaker 3: So to your point, Warren, there's definitely a use case,
Speaker 3: but people just want to offload it to someone else,
Speaker 3: like can you just can you just look after that?
Speaker 3: But that was really the only I realized I was
Speaker 3: talking a lot and needed to need to switch gears
Speaker 3: and change it into something else. So I wanted to
Speaker 3: get your guys view on that as a topic.
Speaker 1: You can't do that. We're here to grill you, not
Speaker 1: the other way around.
Speaker 3: Now, think about what other services, what other sad because
Speaker 3: you'd be you'd be wrong in thinking that get hub
Speaker 3: back up your data. It's a shared responsibility model. So
Speaker 3: the data and the information that you've put in there
Speaker 3: is your responsibility. They'll keep the service up and run
Speaker 3: in for even free free tier users, but they're not
Speaker 3: going to back up your data. The data is your
Speaker 3: response toility.
Speaker 2: I mean, I think we have to sort of dive
Speaker 2: into what we mean by backup, so you know, we're
Speaker 2: talking about what is the reliable the durability of the
Speaker 2: of the repositories we give to get hub. I mean,
Speaker 2: I think everyone would believe that that it's as durable
Speaker 2: as possible, which is different from if you accidentally believe
Speaker 2: the data from there, whether or not. Like if you
Speaker 2: accidentally go into lead a repository, what's your remediation strategy there?
Speaker 4: So you know, if that's the risk, then for sure
Speaker 4: you need something else.
Speaker 2: If get hub does go down in some way permanently,
Speaker 2: you know, zero zero, zero one percent or whatever, you know, what's.
Speaker 4: Your business continuity strategy.
Speaker 2: But like if if someone came to me today and said, hey,
Speaker 2: you know, your data could get.
Speaker 4: Accidentally deleted from GitHub or get lab.
Speaker 2: Or whatever the provider you're using, and they're not going
Speaker 2: to do anything, like they have no strategy to do
Speaker 2: with that. That data isn't replicated across at least two
Speaker 2: physical drives somewhere. You know, I think they're going to
Speaker 2: lose a lot of customers, you know, just listening to
Speaker 2: this podcast.
Speaker 3: One hundred per right, and they're going to keep that
Speaker 3: infrastructure up and running. And the accident of deletion is
Speaker 3: kind of hard, Like you've all deleted it, we've all
Speaker 3: deleted a repo on there, like you have to go
Speaker 3: through some boots to make that happen. But what about
Speaker 3: this is a sonar like, so hopefully all three of
Speaker 3: us have MFA on our GitHub account as access, but
Speaker 3: it's a SAS service, right, so anyone could get if
Speaker 3: someone bad or malicious gained access, or a malicious internal
Speaker 3: user had access to a repo and they decided to
Speaker 3: delete or not even delete. Let's look at the open
Speaker 3: source issue that happened, is it x Y a couple
Speaker 3: of months ago, the Impression library? Sorry, yes, and and
Speaker 3: that that's not the same scenario. But you you let
Speaker 3: people in in to maintain, they can make changes, blah
Speaker 3: blah blah. Someone makes a change that's malicious to the
Speaker 3: code or potentially many different malicious activities within that. Do
Speaker 3: you want to go back to all of your developers
Speaker 3: laptops and hope that get clones of happened and or
Speaker 3: do you want a point in time restored? I think
Speaker 3: I think we're all onto something. But I think I
Speaker 3: think I think I think it's an interesting topic. That's
Speaker 3: where I was.
Speaker 2: Yeah, for sure, I think it's one of those things
Speaker 2: that's a long poul Like it's a very long tail responsibility,
Speaker 2: Like there are tons of companies not even thinking about that,
Speaker 2: and then there are but there are things that they
Speaker 2: should be doing first, like they still have passwords as
Speaker 2: the requirement for authentication for their UIs for their users,
Speaker 2: and so like, please do something about that first before
Speaker 2: you even start to think about you know, source code
Speaker 2: backup or you know, you mentioned MFA, like companies that
Speaker 2: don't you know, have passwords but no MFA. Right, It's
Speaker 2: like passwords are like eighties, Like if you have passwords
Speaker 2: as any sort of authentication, like eighty six percent chance
Speaker 2: it will get popped in the next two years. It's
Speaker 2: it's like ridiculous. And yet they're, you know, they're thinking
Speaker 2: about these long teraim things. Oh well, what if one
Speaker 2: of our developers like exposes their source code or takes
Speaker 2: it with them.
Speaker 4: I'm like that is not the biggest risk.
Speaker 3: Yeah, the CEO right in his or her password on
Speaker 3: the post it note in their office, is that that's
Speaker 3: the biggest risk.
Speaker 1: But they have to show that their assistant has access
Speaker 1: to the password when they don't make it into the office.
Speaker 3: And the calendar. Obviously they need to be able to
Speaker 3: get into their Zoom account.
Speaker 2: Right absolutely, Yeah, I'm if we're going to go down
Speaker 2: the rest page right now, I think it's the deep
Speaker 2: fakes being sent to your finance or accounting department on
Speaker 2: behalf of the executive team saying that they should pay
Speaker 2: out an invoice to a third party company, and they
Speaker 2: go and do that, and so I think, you know,
Speaker 2: that's that's the biggest risk to a company right now,
Speaker 2: is a direct attacks on their their wallet more so
Speaker 2: than anything else.
Speaker 3: That was so that made that reminded me of another
Speaker 3: massive knee jerk change of direction on I watched a
Speaker 3: YouTube video of Ryan Goslin explaining the one oh one
Speaker 3: of l l M's It wasn't It wasn't And he's
Speaker 3: got a ridiculously huge left arm, but yeah, it like
Speaker 3: he's nailed it. He's really good at explaining because someone
Speaker 3: someone has put that data in there, but a huge
Speaker 3: deep fake. Yeah, that is the biggest, a bigger risk.
Speaker 3: So yeah, fully just to get away from structured open
Speaker 3: source learning as far as possible, source code, repository back
Speaker 3: up and deep fake.
Speaker 4: Ryan Goslin's well, I mean I think it's super relevant, right.
Speaker 2: You have such a good source of knowledge here that
Speaker 2: would be a shame to lose in some way. And
Speaker 2: I think, you know, even Getthub has this idea of
Speaker 2: the Arctic code backup program where they're locking it in
Speaker 2: some vault hypothetically. I don't know what that actually amounts to,
Speaker 2: so I can imagine you know, I didn't I didn't check.
Speaker 2: But maybe you've got an award here associated with this
Speaker 2: that says it's being saved somewhere important.
Speaker 4: I don't know what they did with their awards.
Speaker 1: Yeah, I've got a badge for contributing to the Arctic
Speaker 1: Vault program, although I have no idea what that program
Speaker 1: is or what I did to contribute to it.
Speaker 2: You shoud actually should actually tell you, like mine was
Speaker 2: like contributing to some AWS source code and some things
Speaker 2: that were used on like one of the NASSA rovers.
Speaker 1: I just saw a bunch of colorful badges there one
Speaker 1: day and Howard out them for them and then moved
Speaker 1: on with my life. You know, like in the I
Speaker 1: try not to get involved in side quests.
Speaker 4: How do you know what the main quest does?
Speaker 1: So funny story, because at the end of every day,
Speaker 1: the last thing I do at night is I write
Speaker 1: down the five things that I'm want to be focused
Speaker 1: on for the next day, and anything that's not one
Speaker 1: of those five I just ignore a barring, you know, like, hey,
Speaker 1: we've got a production outage. You know, I can't really
Speaker 1: go up. Sorry didn't schedule that. I'll see if I
Speaker 1: can get it on tap for tomorrow.
Speaker 3: But I use that.
Speaker 1: I've used that method four years and it's been the
Speaker 1: only way for me to stay focused and on track.
Speaker 4: I think that's a really great idea.
Speaker 1: Actually, I've tried the every electronic version of it I
Speaker 1: can find. I've even tried like just doing it in notebooks.
Speaker 1: But for me personally, the only thing that works is
Speaker 1: is the three by five card, and then it's just
Speaker 1: either on my desk or when I leave my desk,
Speaker 1: I put it in my pocket, so no matter where
Speaker 1: I'm at, I know what I'm supposed to be focused on.
Speaker 2: That's the legacy units for anyone who doesn't know. He's
Speaker 2: saying inches, which not centimeters.
Speaker 1: That's three centimeters by five centimeters.
Speaker 3: Pretty small.
Speaker 1: Yeah, it keeps me from taking on too.
Speaker 3: Much each day.
Speaker 1: By limiting the writing space, my day has gotten so
Speaker 1: much better.
Speaker 2: There's something that goes you know, when you're actually physically
Speaker 2: writing it out. I do find that has an imprint
Speaker 2: in you more than say typing it into it. So
Speaker 2: like when I'm in my meetings, I tend to have
Speaker 2: a notebook and I write things down.
Speaker 4: Actually it's not like saved.
Speaker 2: I usually write on a piece of scrapaper and then
Speaker 2: throw it away after the meeting. And it does wonders
Speaker 2: for me realistically to remember what I've gone or what
Speaker 2: I've discussed with really has nothing.
Speaker 4: To do with medium which I've chosen.
Speaker 1: Yeah, agreed, physical, physically writing something is increases my retention
Speaker 1: and comprehension immensely. What about you, Michael, you're digital or analog, so.
Speaker 3: A bit of both. You can probably see there's pa
Speaker 3: paper all here. Yeah, so bitter boat. But because I'm
Speaker 3: constantly it seems, but at least recently on an aeroplane, there's
Speaker 3: a lot of notes and a lot of draft emails
Speaker 3: actually that I seem to use. I use email for
Speaker 3: that that I do actually communicate.
Speaker 4: Definitely got the emails of my outbox for sure.
Speaker 2: When I'm traveling, there's there's no ultimate unfortunately excellent.
Speaker 1: Well should we move on do some pics? All right,
Speaker 1: let's do it. What'd you bring? Warren?
Speaker 2: Yeah, so I'm on my book rants. So this week
Speaker 2: is going to be management three point zero.
Speaker 4: By you're gonna pillow.
Speaker 2: I found that very early on in my career. It
Speaker 2: was a great way to think about as an aspiring leader,
Speaker 2: to how to build the work around a team and
Speaker 2: even move to an agile perspective. There are still companies
Speaker 2: out there that aren't doing agile, and whether it's.
Speaker 4: Not totally married to that aspect, it really does.
Speaker 2: Help you think through what to do in certain situations,
Speaker 2: how to prioritize work effectively at a team level. And
Speaker 2: I just I can't recommend it enough for those that
Speaker 2: are thinking about not just the code that they should
Speaker 2: write or what they should work on that day, but
Speaker 2: how to collaborate effectively, how to track that work and
Speaker 2: prioritize requests that are coming in from either.
Speaker 1: Other teams or from the business speaking of collaborating effectively,
Speaker 1: hearing is such a key part of that, and I
Speaker 1: have terrible hearing like between just like the background roar
Speaker 1: and tonight is with the really loud ringing. It's really
Speaker 1: hard for me to hear. And I've had my hearing
Speaker 1: tested multiple times and they say, oh, there's nothing that
Speaker 1: here in ads can do for that. Best of luck
Speaker 1: to you. Okay, thanks, But I did get recently a
Speaker 1: pair of AirPod Pro AirPods Pro two and they've got
Speaker 1: like a background noise reduction feature on them and that's
Speaker 1: actually been super cool. So that's my pick for the
Speaker 1: week because it does a great job of like filtering
Speaker 1: out that roaring background noise, especially when you're in a big,
Speaker 1: open environment, so that you can hear the conversation going
Speaker 1: on around you. The downside to it is that everyone
Speaker 1: sees you have AirPods in, so they assume that you're
Speaker 1: listening to the Adventures in DevOps podcast and not really
Speaker 1: interested in talking one on one.
Speaker 3: So that's the.
Speaker 1: Trade off there. But that's gonna be my pick of
Speaker 1: the week. Michael, what about you.
Speaker 3: I guess mine goes. I know we spoke about the
Speaker 3: five k's a day, I think, but my background is
Speaker 3: rugby knocking seven bells of stuff out of people on
Speaker 3: a Saturday after a busy week of weird and wonderful things.
Speaker 3: Obviously that's gone a way you're getting older. I can't
Speaker 3: really do that anymore for that five k a day.
Speaker 3: Just as Warren kind of put it as well, is
Speaker 3: it just takes you out of that that busy, busy mode,
Speaker 3: and I massively encourage it to any Everyone should be
Speaker 3: moving anyway for health and fitness, but that brain rest
Speaker 3: as well, Like I get some of the best ideas
Speaker 3: when I'm at least two and a half k away
Speaker 3: from my house. So just that mindfulness of escaping from
Speaker 3: something that you're potentially stuck on trying to fix takes
Speaker 3: you away from it like that. That seems to be
Speaker 3: working for me at the moment. I'm up to one
Speaker 3: hundred and fifty odd days of continuous, continuous walking or
Speaker 3: continuous five k in the spirit of Devils nice.
Speaker 1: You know. That's why I asked you about listening to
Speaker 1: podcast or music, because I've had a similar experience when
Speaker 1: I'm out on runs. It's number one meditative, but number
Speaker 1: two just so helpful for sorting the mental clutter and reflection.
Speaker 1: And I've gotten to the point now where I don't
Speaker 1: take any I don't listen to anything, no music, no podcast, nothing,
Speaker 1: just out there, just me and my thoughts. And that's
Speaker 1: been pretty wild.
Speaker 3: Yeah, don't laugh more.
Speaker 1: This is the Homer Simpson quote. All right, brain, I
Speaker 1: don't like you and you don't like me, but it's
Speaker 1: just the two of us. So we got to get
Speaker 1: through this, or let's get through this so I can
Speaker 1: get back to killing you with beer. Yeah, so that's
Speaker 1: I hear you on that. Like, getting out and moving
Speaker 1: is just great, not only physically, but it's so helpful
Speaker 1: mentally as well. And I would I would highly recommend
Speaker 1: at least giving it a shot without anything, you know,
Speaker 1: just you and your thoughts, because it's going to be
Speaker 1: it's going to be wild. But so there we go. Michael,
Speaker 1: thank you so much. I really enjoyed having you on
Speaker 1: the show.
Speaker 3: Yeah, thanks for having me guys.
Speaker 1: I would love to have you back at any point.
Speaker 1: Just hit us up and let us know, and for sure,
Speaker 1: when we're ready for the I got to figure this
Speaker 1: is twenty twenty four, so when we're ready for the
Speaker 1: twenty twenty five edition of ninety Days of dev Ops.
Speaker 1: I look forward to having you back.
Speaker 3: Awesome. We'll figure out what it needs to be. I'm
Speaker 3: sure there'll be some llms and AI associated to it
Speaker 3: as the trend keeps going.
Speaker 1: Right, just ask chat GPT to create it for you.
Speaker 3: Yeah, there you go, because there won't be any hallucinations
Speaker 3: in that right.
Speaker 1: Awesome, Warren, thank you for joining me today of course,
Speaker 1: and for all of our listeners, thank you for listening,
Speaker 1: and we will see y'all next week