5 ms·

Hey thanks for taking a moment and writing the comment explaining what it takes to get into DevOps. I do have programming skills and understand most of the tool

Hey thanks for taking a moment and writing the comment explaining what it takes to get into DevOps. I do have programming skills and understand most of the tools but In order to get a little better I need to learn more Do you have any resources or can direct me to resources that I can use to expand my knowledge

100011_100001 6y ago
I tend to dislike reading blogs, mainly because they either don't give enough information or the thing they are trying to solve is not a need to have. I don't have specific sites to recommend. 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.

100011_100001 6y ago

I tend to dislike reading blogs, mainly because they either don't give enough information or the thing they are trying to solve is not a need to have. I don't have specific sites to recommend. 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.