#90DaysOfDevOps - The DevOps Learning Journey

Thanks for joining. So, really, what I want to do over the next 30-40 minutes is talk about a little project that I started at the beginning of 2022. One of those ideas you come up with on New Year's Eve when everyone else is partying and drinking lots of booze. I was thinking, "How can I make sure that I go into the new year and start learning and filling in some of those gaps that I had around DevOps?" and that big wide world of DevOps right? Around all of the processes, the principles, but equally the tooling and all those different facets of DevOps.

Spoiler alert: you're not going to learn DevOps in 90 days. And we're definitely not going to learn DevOps in 38 minutes now. But it should give us an idea about some of the areas. One thing I found was just putting it into a bit of perspective. Put it into little modules to get a better understanding, a foundational overview of some of the most topical areas around DevOps.

And I'm going to talk about what we've started for 2023 to continue this journey. The premise of it is around learning in public, showing a bit of vulnerability. Like, I've worked in tech for nearly 20 years, very much from the infrastructure and operations side. I've worked at Veeam Software that is focused around data protection, data management. I've just been parachuted into an acquisition that we've just made around Kubernetes backup called Kastan. There were a lot of new faces and people, and a community that I was engaging with that made me feel vulnerable in my learning.

So with that, let's get into what it is. Myself, I'm Michael Cade, and as I said, I work for a company called Veeam Software. My focus is a Field CTO Technologist around Kubernetes backup, all things DevOps, Cloud native, all things cloud, and open source. If you see my LinkedIn profile, you'll see my job description is more than an essay. Some of the projects that we have, the Open Source One, is Kanister. It's focused on an application framework that enables you to jump inside of data services such as Postgres and trigger or orchestrate PG dump or MySQL equivalent and various other pieces that's open source. We also have Kubester, which gives us a project that enables us to look into your Kubernetes storage, see what's available to you, how it looks, how it feels, and then also be able to provide you some of the bandwidth and throughput that you can get from that storage.

Especially in the public cloud, where you have different node sizes and storage capabilities, they're not always equal. So you might want to have that insight as to what your application is going to look like on there.

And then the final one, and this seems fitting to talk about here, because we've got a new project called Navigate. It's a Helm visualizer, and based on us being at Civo Navigate, I wanted to mention that as well.

The mission was to take 90 days. So, from the first of January through to the 31st of March in 2022, I aimed to cover as much on a foundational level of DevOps topics, principles, processes, tools. And really, it started out as just me doing it in public, writing on GitHub in a repository, writing notes. I never thought that it would get to where it was. It's had well over 20,000 stars, which, if anyone's familiar, it's kind of like "likes" on Twitter. That's how I look at that, right? It shows that it's helping someone, in my opinion.

If you want to take that QR code, it's going to take you to the README. I can jump into that as well towards the end just to show you what it looks like. Hopefully, the navigation is good; we've worked on that a lot. Rishab's, who's also here and giving a talk at 4:30, go and check his SMS-like a PagerDuty-type session. He's been massively helpful about what that experience looks like from an end-user point of view because we want to be continually learning. But the barrier to entry needs to be minimal; just give me something to learn and let me crack on with that.

So why did I do it? I kind of touched on this before. It's a role change and speaking to a new community, right? Speaking to the cloud-native ecosystem, the community within that, speaking to a lot of potential developers that have moved into that automation way of thinking, that process and principles around DevOps. But then equally, the operation sites that have also moved the other way into being more automated around what they're trying to achieve.

I had a lot of existing knowledge around things like infrastructure as code. I'm a HashiCorp Ambassador, so I've done a lot with Terraform, for example. I've done a lot with Chef and Ansible. I've lived and breathed Linux for a while and networking. But that only really gives us a small glimpse of the bigger picture when it comes to DevOps. And as I mentioned, you definitely can't cover everything, all aspects of DevOps, in this 90 days. I'll get on to more about that as we go.

A big part of my whole career has been about learning in public: sharing blog posts, finding something wrong, blogging about it. If it helps one person, then I find it's well worth putting a little blog together. And then obviously, over the pandemic, we found the ability to become content creators around video and creating YouTube videos and such.

So, I started doing that as well. It's always about being able to give back to the community. I learn so much from the community, so it's that flywheel, right? If we help each other, we're only going to progress but constantly be learning as well. Share that learning in blogs, in videos, etc., and make content that you feel like you should have had. I've found that you can't go and buy DevOps off any vendor. You could go and buy bootcamps, and you could do that. My key part here was, I don't like paying for Udemy courses. I do buy a lot, but they tend to sit there at zero percent for a long time. So, I wanted to make everything free and accessible for absolutely everyone, especially in our community that spans the world, with different diversities around that as well.

Okay, so Level One DevOps, where do we start? I had to think: Where do we start? And then you start to see all these logos. If you think about this, I come from a VMware background. I come from operations, mostly storage, NetApp storage, and you start to see all these new logos and names, and it just massively overwhelms you as to where you need to start. What do I need to know? A programming language? Where do I need to start?

So, the first thing I did was, okay, fundamentals. What is DevOps? And why do we need it? Why do we need DevOps, that process, and principles in our mindset when we're delivering either platforms for our developers or even from an infrastructure point of view? Why should we consider that automation engine or automation mindset to make sure that we can automate a lot of that menial task away?

So, I created this mind map and went, okay, this is how we're going to split out the 90 days. First of all, we need to spend some time on understanding the process and principles around DevOps. What is it? Why is it important? And then I started going around and spending seven days on each of these, like learning a programming language. I'll get into why Go as a language is there in a bit as well because I'm going to go through each of these in a little bit more detail. Just a very, very little detail because, as you can imagine, something like Go could have its own 40-minute session. In fact, you could probably spend 90 days just looking at Go. Same with Linux. Linux is a big beast with lots of different variants. Networking, probably the worst seven days of creating this whole project, was looking at networking. And again, remember, we're just looking at a foundational level. We look at the OSI layer, what that means, the application stack, but I still managed to get some Python in there and automate some of that away. Apologies if there are any networking engineers in the room.

And then so on and so forth. Like, we get to stick to one cloud provider. My biggest advice to anyone is to go and learn one of the big three cloud providers because you can take those skills into another. If you start with Azure, you could pretty much go and understand what AWS is up to with all their services, or you can understand what Google is saying as well. And then that will translate absolutely into like Civo as well. In fact, Civo might be a great place to start because the limited services make it much easier, and the barrier to entry is much simple.

Then we get into the cool stuff, right? Git, and then Docker, and containerization, and Kubernetes underneath that. And then we get around to Terraform and automating infrastructure as code. We get around to configuration management around Ansible, Chef, Puppet for example. Then CI/CD pipelines. A massive bugbear that I have now, because I've gone into it, is that why do we have CI and CD always together? It doesn't have to be that way. But anyway, I'll get into that as well. That's a bit of a rant.

Then observability. And you see that I've left these until the last because they're always on the bottom of the call list, right? Observability, yeah, it might have been starting to become a bit cooler over the last few years, still pretty boring. And then storing and protecting your data. Remember, this is the game that I'm in, right? It's always bottom of the list until it's absolutely necessary to start protecting your workloads and your databases and data services within your platforms. And I just use Kubernetes as just another platform alongside virtualization, alongside cloud. Okay, that was a big slide to go over.

So, Level Two: What is and why do we use DevOps? And I'm gathering that many of us are either starting that journey, in the middle of that journey, or we've been doing things around DevOps for a while. Responsibilities of a DevOps engineer, the first asterisk that I've put up there is, how many people are actually a DevOps engineer in the room? Okay, so the reason why I put that asterisk is because it's quite a loose term that we've made in the industry, right? Because, like you two, I don't know if you work for the same company, but your DevOps engineer, and your responsibility, and your responsibility are probably completely different, right? And I feel like DevOps is the new ITIL, the new cool ITIL, right? It's the change management. It's how we make things happen. Whereas, probably better suited would be like an SRE, or a platform engineer, or a cloud engineer, a systems administrator. I've always said that actually, it's a systems administrator that saw the future of where they should be going, around automating.

So, if we think about DevOps though, break it down a bit, DevOps is the link between a developer and operations. But I would argue actually, is I speak to a lot of companies where they're not developing their own software, but we have to take off-the-shelf software and we have to deliver that into our business for our users or for our customers to use. And that doesn't mean that we still can't use DevOps in that environment as well. So, yes, it is the link between, in a fancy world, where we've got application developers, we've got our operations, infrastructure teams, our security teams, and it is the link between. But we also know that there are businesses out there that just buy off-the-shelf software. So, we have to think about how we automate a lot of those tasks as well. I think another thing, maybe the DevOps engineers in the room or anyone that's familiar with this, is that you're not going to be, generally, you're not going to be a master of all of that wheel. At least, you're going to be a jack of all trades. You've got to have that mindset that we're in a constantly changing world. We need to keep just having familiarity with some of these concepts. GitOps is a great example, right? GitOps comes around, and like, what is it? How do we use it? And maybe you could link that to your CD pipelines as well in there. But everything starts with the app, as a mindset to begin with, is kind of where I started to think. Okay, that makes more sense. Now we start to automate everything around the app, making sure that availability is there, store and protecting the data, the observability. It all starts with that application. The application is the key part, the middle part, of everything that we do as a DevOps engineer, as a cloud engineer, as an SRE, etc.

So, this slide took ages, so I'm going to leave this on for a little bit. But if we think about the steps of DevOps and that infinite logo icon, from a DevOps engineer point of view, you're probably not developing the code for the application. Unless you're creating the CLI and you're doing your own stuff to automate your own stuff. But if you are in an app development house, you're not going to be developing, testing, and integrating that. You might be building the platform for that, but you're not going to be actually hands-on creating the application. Whereas, you are going to be involved in the deployment, the monitoring, maybe even the feedback, and making sure that these people, the developers, can actually deliver their application and make sure that the versions can go out as fast as possible without any hiccups. So, that's why I put that in the way, is that that side, let's automate as much as we possibly can across this whole infinite loop. But ultimately, the deployment of the application, the platform in which that lives, the hardware, the feedback loop back into the developers, and the user experience might come down to you as a DevOps engineer as well. Right? If something's slow to deploy, it's probably going to end up being on your head versus the developer because they've already clocked off, they've already gone home.

Okay, Level Three: Still 12 steps to DevOps. So, if we think about that first module as a "What is and why DevOps?", but then we want to get into some of the nitty-gritty of the items within that. So, do I need to learn a programming language? Probably not. Like, do you guys know programming languages as DevOps engineers?

Just basics, right? Like, okay, just enough to maybe build a CLI, a script to do something, right? You're not, but you don't need to know GoLang. You're not an app developer at that point.

Exactly that. But so, the reason why - so I chose Go simply because casting K10 is written in GoLang. So, I wanted to, and I'm not a DevOps engineer, I'm a... just a technologist, right? I come up and speak about stuff like this. But if, in order for me to help with that feedback loop, if I can understand a bit of that GoLang language and that application that we're deploying, then I can say, "That could be better if we did this," and make observations on that. So, the answer though, "Do you need to learn a programming language?" Probably not. But you're probably going to pick one up because you're going to want to build your own CLI, you're going to want to play around with some of this stuff for it. But the big thing that I got some feedback on this was, Python is actually, like, probably more applicable to a DevOps engineer because, you know, it's so... uh, versus... yeah, thank you. It's so versatile across multiple different areas. And actually, it's one of the things that Richard is gonna... he's gonna cover in the 2023 version of "90 Days of DevOps" because of that feedback. I'm not going to go into everything around that, but there's some benefits around Go. Kubernetes is obviously written in Go, Docker is written in Go. Although, we're seeing, even in the last talk, Philippe talked about like Rust, and we're hearing a lot more about Rust as a new programming language. I think Go is still pretty high up there if you look at, like reports and surveys around that. It's pretty fundamental, in terms of a cloud-native language for that.

So, getting into the Linux side of things. So, Linux, again, you could spend a whole 90 days just on Linux, right? But Linux and DevOps, and there's a reason for it, they share very similar perspectives and cultures when they come to... And, and I would argue that, so DevOps, the term was kind of formed in around 2009, apparently. And I would argue that Linux has probably been preaching that as a community for a lot longer than that. A lot of these, a lot of the products that I, at least, stumbled across, things like Git and Jenkins for example, they've been around a lot longer than 2009. Like, we've been doing stuff like this for a lot longer than the term "DevOps" came around. They both focus very much on customization, scalability. A lot of the technologies start on Linux, so things like Kubernetes, Git, example, etc. I've got a pop-up there. Thanks, Windows. Red Hat, Ansible also and a lot of open-source projects, right? They start from a Linux, kernel base, and then they maybe adapt into different architectures and different operating systems. But ultimately, Linux is a foundational operating system that we see across all of our platforms. So, whether it's Kubernetes nodes, whether it's vSphere and virtualization, your cloud, whatever Civo is running, k3s, it will be running on Linux as well. So it's a big foundation on that.

Now, what did I do to like ramp up my Linux? Bearing in mind I had a good understanding and a good background in Linux, like the command line and living in that terminal but if you want to learn something, then you have to get hands-on. And this was, this is not a new thing for me. This one wasn't a revelation or anything. But the thing I did is, I had my work laptop that was imaged, and I thought, "That doesn't seem right." So maybe I'm just going to throw a Linux operating system, Ubuntu, on there. Easiest one to get hands-on and live with that as a daily driver and try and make sure that you can work with it with all your work applications. Because you're going to find that that ramp up, when you start talking about the other tools, a lot easier from that perspective. So the challenge to everyone in the room, if you're not already touching Linux on a daily basis, and you're just, that's like starting that learning journey, then take up Linux for a month or a week, and try and do everything, like from a work perspective. You'll probably spend more time fixing things which will give you the fundamentals of Linux because not everything works as a desktop OS. But it will give you great insight into Linux and the operating system around that.

Okay, networking. Who loves a bit of networking? Cool. Network engineer at the back, right? I'll go steady on what I say. So then I found these new terms around like net devops, or network ops, and network devops, automated networking, which sounds amazing, right? I want to take away that laborious task of setting up networks across my platforms and environments. So, breaking down what those... like, if you think about within your business, you've probably got a network team, or maybe that's even already evolved into, it's just a platform team. They look after the network, they provision the network, and hopefully it just stays working, and they don't really have to troubleshoot too much. So, within the project, we took seven days. And this is an important point to take, is that so basically all of these sections, I took seven days. I started off with a big picture, and then we start talking about some of the theory behind the networking. So, for example, the OSI layer. What does each one do? What does it mean? Some examples around that. What is DNS? What's DHCP? The fundamentals of networking. And then, towards the end of that seven days, we want to get hands-on. Because, like I said with the Linux, is we want to be able to, I learn by doing. I learn by having hands-on and not all that theory, um, aspects to it. And it seemed appropriate to put a meme up about DNS because it's always DNS, right?

So I mentioned around "learn one cloud provider." Now, this came about, obviously, I mentioned around go and learn one, rather than trying to learn all three. And there's a lot of different services available to you within the cloud. Different clouds have different services, etc., etc. But fundamentally, if you look at on-premises, you're in control of everything. If you look at infrastructure as a service, they abstract away the hardware, especially from an AWS point of view, but also from Civo. You don't know what that underpinning hardware is. You probably don't even know where the data center is. And do you really need to know? You pay for the privilege of not having to look after that. If you do need to, then that's where on-premises comes in. You buy and you look after everything yourself. You pet, you water it, etc. But then you might go one step further. You might be using a database as a service, where you want to abstract further amounts away. And then you have software as a service, Microsoft 365, Salesforce, for example, where they just abstract everything away, and you just want to have an application that you go to a web portal, and you do what you need to do, and you pay the privilege of being able to do that. All of the clouds have something that resembles these. And then, obviously, they do have varying different levels of abstraction that they offer. The reason why I chose Microsoft Azure, because obviously I've had... this is another area that I'd had exposure to the public clouds, and probably an even spread across all of them. So I just went to the trusty Twitter poll, and Azure came out. It's very close between Azure and AWS. And I was actually a little bit gutted because I probably hadn't done enough around Google. And in 2023, Chris Williams, he's going to cover AWS. So I still get to wait again for the Google fundamentals as well.

So also, I think this is a fundamental skill that everyone should have. Whether you're preaching devops principles, whether you're a developer, that you should already have. Although I did hear that people were using much older tool sets yesterday in some conversations. But, Git as a source control, version control system to manage your application is a must. And understand just some of those basic commands that come with that. And again, we went through the big picture. What does it look like? What is Git? How was, where did Git come from? What was before Git? And then you start to realize, a bit like what Wozniak was saying yesterday, is that the world was a very different place. And we all came out of that keynote feeling very, very little from what he's achieved, especially with the tooling that he would have had available to him. So the ability to track those projects, the ability to... And another key part here is that I was dog fooding here as well. Like everything I was doing around this repository was all in GitHub as well. So there's Git, and then there's Git-based services such as GitHub, GitLab, etc. There's a lot more out there as well that you can look at. The big part there, as a technologist or an evangelist around data protection, data management, version control is not a backup. So that doesn't matter whether you're a software developer in the house, whether you're a devops engineer, or whether you're an operations engineer. Version control is not a backup.

Containerization. I probably don't need to delve too much into this, but I delved into the big picture surrounding containerization. I explored Docker because everyone has heard of Docker. It's likely the best way to explain and show what that progression looks like before getting into ContainerD, LXC, and others. But if we think about a container image, it's a lightweight, standalone, executable package that basically allows us to put our software on to it and run that wherever we want. You can choose to run that standalone on a container host that doesn't have the orchestration or high availability. But a lot of us are probably running containers just standalone in our businesses.

And then comes container orchestration. Again there's a lot of variants our there. Kubernetes, as Cheryl mentioned it this morning around it being the winner. I don't know if that's being awarded because the others are still around but if we think about that, it's about thinking that its about What does Kubernetes look like? I speak to a lot of people that needs to learn Kubernetes but you need to learn containerization first.

You need to understand networking first and other fundamental building blocks. So there was a reason for this flow when it came to building the repository out.

And I speak to a lot of vSphere admins, virtualization admins. So, when I explain Kubernetes to those virtualization admins, it's very easy to correlate. If you think about a Virtual Center and you think about your ESXi nodes, your Virtual Center is a VM orchestrator to your VMs. It's very similar, you know, in a roundabout way, in a very high-level way. Infrastructure as code was another area. I already had a good understanding of Terraform, so this was kind of an easy week for me. Is that right? What's the big picture around infrastructure as code? What other options are out there, Pulumi, etc.? Editing's gone, so I shouldn't have mentioned his company, but because he decided to go home early. But the whole point around infrastructure as code is, let's automate that deployment of our infrastructure. We make mistakes. If we have to do click-click-click and we have to do that 10 times, we're probably going to make a mistake. And that's the whole idea. Tools like Terraform allow us to codify what that looks like and then be able to deploy repeatedly our infrastructure.

Yeah, humans make mistakes. Automation is the way to go. And we're again preaching that principle and the process around DevOps. At that point, they're moving more into the application. Again, we make mistakes. So if we've got to deploy the same application in 10 different places and maybe they're not load-balanced, maybe we've got 10 different ROBOs that will report back into our main data center. I don't really want to go to each one of those, like back in the day, and deploy the same application because each one of those, there's a chance they're not going to be the same, mistakes that we made. Configuration management tools such as Ansible, Chef, or Puppet, to name a few. There's SaltStack as well, and loads of others. This gives us a defined way of being able to deploy our application in a solid, consistent, and repeatable manner.

Then we get into the bugbear of mine around CI/CD pipelines, and we're always coupling these two together like twins: continuous integration and continuous development or continuous deployment or delivery. But ultimately, they can be separate. You might have a different tool for CI and for CD. If you're one of those companies that have got that off-the-shelf software, and you're not a development house, you might just have CD because continuous deployment enables us to deploy the application in a consistent way and very quickly as well. And with an option to be able to roll back. I'm sure many of us have upgraded something and then gone, 'Oh dear, how do I get back to how it was?' That's where CD can come in and really help automate that process. They don't need to be together as much is what I'm getting at. If you're not a software development house, you probably don't need CI. If you are, then you've got CI over here and that might be one tool, and then you might be using something like Argo CD for your continuous deployment run over there.

Ah, I didn't change this. So this is observability. We're getting to the end of the 12. I already left off the title of this. This was meant to be monitoring, but it's about keeping a close eye on that entire infrastructure, but mainly also the application that you're looking after. Again, whether it's off-the-shelf, and you might have some built-in functionality to be able to offer that observability. From a Kasten K10 point of view, we ship, as do many other cloud-native technologies, they ship with Grafana, Prometheus so that you can have that federated into your main global one or you choose to just send that data there. So you've got an idea of what's happening within there. It's important to understand what that looks like, what data visualization looks like. We're trained as humans to look at that traffic light system from a very young age. If we see red, we know that's stop, danger, etc., and we need to fix it. Whereas green, we know that it's good. So, it's about not just setting it up, but configuring this to make it useful for you. So that when something bad does happen, or something's on that amber, like a warning, you don't just go, 'Acknowledge, green,' and start leaving it alone like we all do in our home labs and maybe some test environments.

And then the final section of the 2022 edition was around storing and protecting data. I was really focused on not making this a pitch on Kasten. In general, I don't really care, actually. I don't know, this is being recorded, I don't care whether you use our products or not. But if you're considering data protection, then I feel like that's my job done, whether it's on Kubernetes, whether it's virtualization, whether it's cloud. Just consider that, though, if there's data involved, which there generally is. And I'm not going to get into the stateless versus stateful of Kubernetes. That's another whole 90 days by all accounts. But the data is probably the most important part of your business by all accounts. So you need to be thinking about how do we protect that in the most secure way so that we can recover if bad things happen. Now, we see a lot of stuff around ransomware, etc., in the news. But generally, we all make mistakes. Even with infrastructure as code, even with application configuration management, we still make mistakes. It's very easy. How many people have dropped a SQL database and made a complete mess of an update? I know I have. And then it's gone. So you've got to then go and import all the data. And that's fine in a test environment. You learn by making mistakes like that. But in a business, you're going to get fired, and it's not going to end very well for that.

Okay, I don't know how long I've got left. Is it... ah, sweet. So, level four, 2023 edition. So I decided, if we just reflect on 2022, that ended up being a massive written format. So obviously, 90, basically 90 blog posts, 110,000 words. It got translated a few, eight times into different languages, which I remember...

It just started out to be, like me creating notes. Which is mind-blowing. And I thought, in 2023, I need to get some help from some SMEs. And I also realized from some feedback that I massively missed one area. Can anyone, in fact, guess what the area is that I've not spoken about at all? Yeah, so DevSecOps, security. I absolutely missed it off and I did that on purpose because that would have been a much steeper learning cut. Again, you can spend 90 days of looking into just multiple different areas of security when it comes to DevOps or platform engineering or whatever we're calling it in 2023.

So, I got some help from some friends. Rishab, who's in here as well, I mentioned to him earlier, he's going to be doing the Python session. There's a few other names on there that you'll recognize within the community. But we're going to start, very much, or we have started - this again runs from January to March. And you can see that we start with a lot of that same fundamental track around the infinite loop of DevOps, around deployment or packaging, deployment, etc., and what that means from a security point of view. We get into secrets management. We then get into a bit more of the tools that I missed off, maybe from the 2022 edition - so Python, AWS, OpenShift, databases, serverless, service mesh from Merino, and then engineering for day two ops. And this is leading into whether we do it again for the 2024 edition when I'll have even less hair.

But the whole point is about having SMEs that focus on these areas. They can give a much better perspective, a different perspective to mine on some of these areas. I think my key takeaway before we go into any questions is, regardless of where you are on that learning journey, I can pretty much guarantee that the list that I went through and this list, there's going to be an area probably that some of us are not familiar with in our day-to-day or whether we even need to know that for our business. But from a progression point of view, I keep saying about how we're learning every day, right? So just keep learning. If written content works for you, great.

The other thing to point out is that I'm not just making this stuff up. I'm going to much smarter people than me, Kunal being one of them, Siam being another, just to name the Sibo guys. Their videos on YouTube are free and accessible for everyone. I'm not linking it to any Udemy courses or any paid-for content. At the end of each day, each of the 90 days has a resource section and links to YouTube videos that you can go through and listen to. You'll learn a lot more than just reading my stuff. But the feedback that I got was that this is a great framework to get going and get started. If you do have a programming language you can skip over that one or if it doesn't interest you, skip over it. There are seven-day chunks. Just drip over them as you see fit.

Just another big shout out, we're probably a little bit more now. We're probably closer to 80 contributors, which is mind-blowing. That's just people fixing all my spelling and grammar mistakes, by all accounts. But an amazing effort. Another key area that I haven't put on the slides is people using or taking the repository and translating that into different languages. It blows my mind that it's an amazing effort. If it helps one person, then it's worth doing. And clearly, if it's just helped that person who's translated, that's amazing as well.

A couple of points: like I said about the likes, and this was maybe last week or something, 21,000 stars, which is ridiculous. 509 people watching, nearly 5,000 forks of that. If you look on the repository, if you go to that code, you'll see at the bottom of that readme not only the link for 2022 and 2023, but there's that GitHub star graph. You see where it didn't do anything during the third, during the 90 days. I know a lot of people tweeted me saying they'll come back to this when you've finished it, which is fair enough, right? And then it just went rocket ship up.

I think that's the end of it, but I'm willing to take any questions as well. Hopefully, that was useful. I appreciate everyone's on a different learning journey. Cool.

I think there's one question: "So, as we saw that this project, of course, really took off and so many people are getting benefited from this '90 Days of DevOps', did you find any trends as people started their learning journey? Did they try out certain topics before? Was there a growing trend that most people started, let's say with the programming language, then they went into DevSecOps, and then into Kubernetes?"

I think I learned that I don't know an awful lot at all about technology. That was kind of the reason why this even came around. Because you can talk to developers and be the nicest person, but if you don't understand what they're up to and you just nod, you're not going to learn anything. So, you have to go away and put that effort in to keep learning. I think absolutely, the security for 2023 is the biggest learning thing. It was like the light bulb moment. I think also in 2022, security was a big focus due to ransomware attacks. So that made it easy to start 2023 and start talking about DevSecOps and what that means to the whole software development life cycle.

I think there was another question down here as well.

Yeah, hi. I had three questions. Cool. First thing, is Argo CD better than Jenkins? Because I have not used Argo CD. In one of the sessions yesterday, they were mentioning that GitOps uses the Argo CD engine. So, I think in the CRCD section, I touch on Jenkins from a CI perspective, yes, and more of a traditional perspective. If you're using Jenkins in your business and you don't know what you don't know, you'll probably continue to use that. It's a little more versatile to the platform that you're running on. Whereas Argo CD is Kubernetes based. It runs on Kubernetes and allows you to deploy your Kubernetes application. I might be wrong, it might do more than that, but from what I found, it was not limited because it does it very well. But it does it very well for Kubernetes applications to deploy that.

Okay, my second question was, is DevSecOps replacing the DevOps engineer? I don't know where it was mentioned about platform engineering. One of the sessions talked about an evolution of DevOps and then platform engineering. And I mentioned NetDevOps as well. We can keep adding words in there like Net Dev setups, and it gets a little silly. But platform engineering, I think, is actually a nice umbrella term that factors all of them in. And you're seeing big tech companies talk about platform engineering more than operations, more than security, more like taking away the siloed approach that maybe we saw with traditional titles and teams.

Was there one more question? Oh, we're done? Okay, yeah, absolutely. Thank you very much.