On top of that you have to understand what one company swears by might not be used at all by another company, however if you understand the main concept you can at least parse what is being asked of you. Let's call this rule #1, what is important to one group might totally not be used by another group.
Rule #2 is if a company is using AWS heavily they might or might not use AWS tools. Amazon has its own native tools, but knowing the general ones might give you a better all around knowledge.
Learn how to code. It's a lot easier to teach a Dev the Ops side than it is to teach an Ops person how to write code. What languages to learn is specific to the team and in a way the tools you might be using.
Good languages to learn
Java (and Groovy if you are doing Jenkins or CloudBees CI)
Have a really strong understanding of version control. Why it's important. Different ways people use version control to keep track of multiple versions of the same code. Git is kind of the defacto version control at this point. So learn Git.
Learn about databases. Learn at least one database tool semi well. As in be able to query things, understand how it works. I hesitate to make suggestions here because one company might only use Oracle, another MongoDB and a third PostgreSQL. (see rule #1)
Learn about some kind of infrastructure automation. Puppet, Ansible are the main contenders here.
Learn about build tools. Maven and Gradle are the main ones. Then there is NPM on the app/webpage side.
Learn about deployment platforms, and here is the main meat and potatoes of DevOps. Kubernetes is huge, so learn that, but there are layers above it. A lot of deployment platforms base things on Kubernetes, but it's not true for everyone (rule #1). However I feel that if you learn Kubernetes and EKS, which is the Amazon version of Kubernetes you can at least understand most ideas, as in how cluster, nodes, networking, security works.
Learn about containerization, as in really understand it. Why is it important? Benefits? Drawbacks? Scalability. Immutability. Most popular tool is Docker, but it's quickly losing steam. It's a good start regardless.
Learn about microservice architecture and how APIs work.
Most importantly, learn how to communicate effectively. Don't use me as an example of that. However being able to explain complex CI/CD workflows to management and regular developers is a mighty skill. A lot of times the DevOps groups do a good job and communicate poorly.
Things that matter but don't at the same time:
* IDE, yeah you might have a favorite but if the company you work for doesn't use it all your IDE knowledge is wasted. Familiarize yourself, to list a few IntelliJ, Eclipse, Atom, Visual Studio and VIM (yes, it's not an IDE, but it kind of is).
* That one super cool tool that automates that one thing really well. This is kind of tongue a cheek but if you work in any IT based industry you will see fads come and go.
This is just some quick thoughts on the subject and I probably missed some big stuff. For example I didn't really talk about security tools at all. The main problem with DevOps is that there is always something new that might be working better, faster and let's not forget be cheaper / free but it totally depends on the company you work for. If you learn all the things above, which might seem like a lot, but honestly developers need to know similar things, just not as much in depth in some cases, so even if DevOps is not for you, it will make you a better developer.
Do you have any resources or can direct me to resources that I can use to expand my knowledge
Are you currently employed as a developer? If you are, look at the tools being used. What is automated? What is not? How could you automate it? I don't like doing Ops, it's really boring to me, so instead I focus on code. What can I automate? What can I improve?
Looking at what I have done for 2021 kind of showcases my approach:
- Fixed a bug in our deployment code because of some weird configuration for a microservice
- Automated our on-boarding process for single applications and application groups. We used to have to on-board people, now we press a button, it create a Gitlab group with the right setup, Gitlab project underneath it, sets up metrics, creates Jenkins jobs, auto-generated deployment templates and sends them an email. Went from 3 days worth of work to 4 minutes.
- Update documentation for the training I do to developers trying to understand CI/CD
- When a deployment fails automatically generate a dashboard in Splunk so developers / DevOps can see what happened
- Trained new DevOps person
- Created an automated script that tracks who breaks compliance of our pipelines and bypasses the security scans
- Supported a new team to get up and going
- Setup a metrics collection microservice that various tools can send custom metrics, that then we scrape and display with Grafana
- Added a custom metric to track who is bypassing our security scans
- Added custom metrics to track all groups and every application they own so we can better see what's failing and succeeding
- Added more features to the metrics collection microservice because people want to use it more
But remember, this is my choice. Others are doing more Ops stuff. For example someone is making dashboards in Grafana with my metrics collection. They love doing that. I was more interested in creating a microservice that was super fast and easy to send data to. It runs using 0.1 CPU and 180MB of RAM, freaking sweet.
What I am trying to say is, this is my way. There are many paths in DevOps. Others like using a lot of tools. I find them constraining. I am getting sidetracked but the example I can give relates to cooking. We all know cooking from scratch is better. The question is how far are you willing to go? I don't buy pre-cooked bacon, I rather make it myself, I shred my own cheese. However I don't make yogurt from scratch, but it's possible.
My approach to DevOps is the same. I am not going to write Kubernetes. However I did write the code that automated deployments to Kubernetes because I didn't like how Helm handled security and deployment templates and ElectricFlow is too constrained. At the same time others, either due to lack of skill or maybe they are just smarter than me will use tools. I see it in the pure dev side. What libraries do you use. Is you want to check if a String is a string representation of a number are you going to use an Apache library or write it yourself?
In any case, I don't think I answered your actual question of how do I learn more fully. So if you are not currently employed as a developer I would actually suggest you try to get a job as a Dev. My path was Jr Dev, to Jr Dev for DevOps and now I am a Lead Developer for DevOps. I think being a developer first helped me. The Google SRE book also comments that the best SREs are devs to SREs. Why not Jr DevOps? In my experience DevOps is like a superset of a developer. I am not trying to say DevOps are better than developers, but the knowledge you acquire as a dev can help with DevOps. Hell, even the reverse is true.
There is a brand new DevOps person I trained this year, they are fresh out of college. They are struggling because they can't fall back to their coding experience to figure things out. To give a semi specific example. How can he automate generating build files for applications, if he has never used build files as a developer? And then how can he understand that we are creating build files that generate other build files that the application uses and we have that automated too so application names propagate throughout? I am sure there are people that can, but it just feels harder to grasp.
As a Jr Dev you will get to see the tools your company is using and you can use them as a base. Then you can start automating things. Does it take two weeks for a database to be provisioned, how can you make that easier? What if you wrote a script to pre-populate it with dev data? What if you went further, what if you wrote a script that created the VM or container or whatever and then run the script to populate the dev data?
As a third path, that probably works well for self-directed individuals is to setup a Kubernetes cluster at home. Create a small website with three repositories, it should have an API, maybe a database and a frontend. Build them as containers, see how to deploy them to Kubernetes, figure out how to make them talk to each other. How to use HTTPS. Then set it up so when you commit code in any of the repositories it automatically gets built, deployed into your cluster and comes up. You can do the same in AWS, but that requires money.
Is all of this necessary? No. However if you can do it you'll be really good out of the gate...and by then half of the stuff you know will be outdated and the new shiny thing will be out. But I'll tell you a secret, it gets easier. Sure it has a different name, it works a little bit better, but the ideas mostly stay the same.