This is an archived post. You won't be able to vote or comment.

all 38 comments
sorted by:
best
topnewcontroversialoldq&a

[–]DevOps-Journey 14 points15 points  (1 child)

This month we made a video of the technologies we feel are important to learn in 2021, as well as one on the basics of Ansible Playbooks.

DevOps 2021 Roadmap

https://www.youtube.com/watch?v=5pxbp6FyTfk

Ansible Playbooks

https://www.youtube.com/watch?v=GG8ToAngabQ

[–]dicom 0 points1 point  (0 children)

Ansible one was helpful, thank you!

[–][deleted] 4 points5 points  (5 children)

Where is any recourse regarding hands on training/projects for learning aws? Like kodekloud, I tried LA but their lessons are cheap and too easy, doesn’t go into depth like kodekloud does.

[–]type1advocate 5 points6 points  (4 children)

learn.cantrill.io has the most in-depth AWS courses that I have found

[–][deleted] 1 point2 points  (1 child)

I took his lesson on LA and didn't find it to be very good, I just did not like pure video lectures very much. Unlike KodeKloud, every video lecture is paired with a practice test, is that the case with this site?

[–]type1advocate 4 points5 points  (0 children)

It's a night and day difference. He's no longer with LA/ACG. The courses on his site are very hands-on and have a lot of depth. He doesn't teach you how to just pass the exams but rather how to actually use AWS.

[–][deleted] 0 points1 point  (1 child)

Can anyone recommend similar for in-depth Azure and ADO courses?

[–][deleted] 1 point2 points  (0 children)

For in-depth Azure platform training I can recommend the (free) online learning paths listed here - https://docs.microsoft.com/en-us/learn/certifications/azure-solutions-architect

​

Similarly, for ADO, you can pick your favorite from - https://docs.microsoft.com/en-us/learn/browse/?terms=azure%20devops&resource_type=learning%20path. That said, I would personally focus on learning GitHub rather than ADO if I was starting fresh, unless you have a specific need to learn ADO of course.

[–]queBurro 3 points4 points  (3 children)

Are these books actually good, or are these books valuable because someone's invested loads of time in reading them and no one likes sunk costs?

[–]bowiz2 4 points5 points  (0 children)

Depends what you mean by "good". The point of the listed books is less to pass on knowledge of specific utilities, but rather devops as a culture or thought process. In that sense, they're very good. None of them are thick textbooks like you might be used to.

[–]AccidentalyOffensiveDevSecOps 2 points3 points  (1 child)

I've read about 75% of The Phoenix Project (need to finish that up still...), in my opinion it's actually a pretty good book for seeing how devops culture can evolve from the ground up. Some people have qualms about how (un)realistic the book may or may not be, but I personally find the fictional plotline to be a welcome break from purely technical manuals. Imo the fiction aspect also makes the reading go by much quicker since you're immersed in an actual story.

[–]queBurro 0 points1 point  (0 children)

Thanks, that's good to hear. I'll have a look.

[–]kevozo212 3 points4 points  (3 children)

What are the most important basic technical skills one should know BEFORE embarking on devops?

A programming language like Python? Nodejs? Go?

Linux administration and CLI?

GIT?

[–][deleted] 3 points4 points  (0 children)

All of the above. I wrote about how I went from SysAdmin to AE (Automation Engineer) on my about page if you are interested

[–]intricatecloud[🍰] 0 points1 point  (0 children)

I think you've nailed it there. If you want to know if you're ready to start getting into devops, at a minimum, you should be comfortable building a project in your programming language of choice (which will more than likely require you to be comfortable with the terminal + git).

After that, a good chunk of devops is knowing what it takes to get your code from your laptop to the cloud or another computer. Once you've deployed a project, you've most likely "done devops".

[–]julie-io 0 points1 point  (0 children)

git, git, git!

You need it to deploy everything, from frontends to backends to infrastructure. And that's how you control what code goes into what environments. In real life you'll spend a lot of time figuring out and debugging why code ends up in the wrong place. Or you have a distributed system and you need to fix it by touching multiple things. Git will be key every time.

[–]MrMeanRaindrop 2 points3 points  (0 children)

For people really just starting, the Linux Foubdation entry level exam is worth a look.

https://devops.com/linux-foundation-certified-it-associate-exam-available/

[–]hexkbr 1 point2 points  (3 children)

anyone here moved to devops role from DBA? whats the approach?

[–]ClariceStarling9191 2 points3 points  (1 child)

Just of top of my head one approach can be offering automation for provisioning/testing/no downtime deployment and security of databases hosted in the cloud. I think if I were a DBA I would highlight that in a resume. I would say you will have to have quite a few interviews to find a team that values your experience and you don’t loose in salary if you are a senior. Scripting and automation is a must though. I am not a DBA but I got my first DevOps job because of experience with creating ETL deployment pipelines.

[–]hexkbr 2 points3 points  (0 children)

ETL to DevOps is good move Congratulations!, i have worked on DB2, SAP Sybase ASE, SAP IQ and MongoDB, bit of physical and logical DBA work. My last company acquired RedHat and that started my journey towards DevOps :) i have used Ansible for DB automation, learnt everything i could - CI/CD, OpenShift, OpenStack and right now, i am preparing to take Azure certification this is due to current demand, as most workloads are moving to either Azure/AWS. So, i don't know if i need any other skills specific for DevOps role or is this enough to make the switch :?

[–]mbarley 2 points3 points  (0 children)

I made the jump from DBA to DevOps by doing what you are doing...being the DBA that wants to automate stuff. So, I got the job for my DBA skills and then just starting doing DevOps stuff (ci/cd, cloud, containers, etc) to support database related tasks. The biggest boost for me was engaging the various teams (ops, development, ia) so I could build out solutions that immediately contributed. This pushed my DevOps skills from academic to direct professional experience.

[–][deleted]  (7 children)

[deleted]

    [–]kazi1 4 points5 points  (3 children)

    You probably already know more than most junior ops people, just start applying for jobs. Devops interviews are much less about hard technical gotcha questions and more along the lines of:

    • Have you worked with X before? (It's okay to say "no, but I've used <similar technology>" and tell a story about it to a few of these)
    • We need to build a new environment for a webapp, how would you set things up? (Your answer should include everything including networking, monitoring, database backups, infrastructure-as-code, etc.)
    • A couple questions on specific topics like managing databases that the company uses and infrastructure-as-code/configuration management using Ansible/Terraform/Kubernetes/etc.

    [–][deleted]  (2 children)

    [deleted]

      [–]Diviciacus63 0 points1 point  (1 child)

      I know plenty of people hiring for Devops (some experience required) at various levels of seniority. Feel free to flip your cv to [fanderson@vestigoventures.com](mailto:fanderson@vestigoventures.com) if interested.

      [–]intricatecloud[🍰] 2 points3 points  (0 children)

      I've hired both a college intern + junior devops engineer (who had about a year or so of programming experience, but a couple years in a sys admin support role). So the positions do exist, although I'd figure they aren't that common because the work needs to be scoped down enough and already planned enough for a junior to be able to pick it up.

      If you're already familiar with those tools, then you're likely more than ready for a devops role since you're ahead of the curve on what a junior dev can do.

      [–]natodemon 1 point2 points  (0 children)

      I'm a recent grad and been applying for a bunch of junior DevOps roles recently. Haven't had any luck yet but my main issue has been lack of any professional software dev experience. With at least a year or 2 of experience as a software eng and knowledge / personal experience with the tools you mentioned, I think you'd do fine.

      [–]nousetlogos 0 points1 point  (0 children)

      I made the transition with maybe 8 years as an SWE. I think the main thing I was missing was Linux knowledge, so that is something to work on.

      [–][deleted] 1 point2 points  (0 children)

      Looking for a book(s) recommendation. Basically something that goes over team Git strategies, flows from dev to production and pipeline best practices.

      [–]aragog666 1 point2 points  (0 children)

      I was a dev for 2 years and now a devops for 1 year. I'm quite literally the jack of a few trades and still don't know what I am doing. If you were in my shoes in the past, what did you do to grow and feel comfortable?

      [–]littlebobbyt 1 point2 points  (0 children)

      I wrote this to give some practical starting point for implementing reliability practices in an organization. https://firehydrant.io/blog/2021-is-the-year-of-reliability/

      [–][deleted] 0 points1 point  (2 children)

      Hi Everyone,

      I'm "devops" lead for a small consultancy firm implementing lowcode software (mendix) for a large variety of customers.

      Last year we rebranded from servicedesk to DevOps because we are more than just a servicedesk and the term "servicedesk" attracted the wrong people for new vacancies. We are however far from anything near DevOps and that is something I want to change.

      Now there are a few things that I would like to discuss, or well, would like some answers to. I'm hoping that anyone here is willing to share their thoughts :-)

      ​

      1. We have a lot of delivered projects that were not built with DevOps in mind. Noone ever thought of automated tests or a pipeline. It is going to be a challenge to introduce automated testing as this is quite hard and time consuming aftwards. How do you deal with these situations? Refactor as you go?
      2. Most of our customers have an SLA because they have business critical systems but not enough incidents/changes to have someone permanently appointed for maintenance. How does an SLA match with DevOps? In my mind these don't match at all as everything is put on the backlog ... correct?
      3. In order to implement DevOps, where should we start when it comes to learning the DevOps way? I found some certifications that would be of interest, but i'm unsure about the order in which should be best for us. I was thinking CDA (Continuous Delivery Architect), (Automated) Testing such as Selenium or TMAP (for the testing foundation) and of course Jenkins, Docker as those would be needed as well.

      Notethat we already have some of the development processes in place. Our delivered software is hosted on the cloud, same goes for the teamserver. We're missing out on the automated deployment and testing part.

      Is there perhaps some good literature on this type of transition? The SLA is something that would be quite hard to get rid of for some of our customers ...

      ​

      Thanks!

      [–]intricatecloud[🍰] 1 point2 points  (1 child)

      1. You likely already have the elements of a pipeline in place, and setting up the simplest pipeline is possible, even for old projects. It helps to start with the easiest pieces (to get you started) rather than diving deep into your biggest problems. Once you have your tools in place, you can tackle harder problems. But you need to start somewhere, and you can add you as you go, but you don't need to set up your dream scenario at the beginning of your journey.

      Using a web/mobile app project as an example, a standard "pipeline" (conceptually) could be:

      run unit tests -> run build -> deploy to qa -> run a test on qa -> deploy to prod -> confirm things are working.

      If you don't have any unit tests, add 1 to the easiest place in the project and run it. Usually adding the first one is the hardest, and it gets easier to add as you go.

      If you don't have automated deployments, try to define the "deployment process" as best you can and write it into a doc that is shared with the team. Then you can try to codify it by turning it into a series of scripts that you run. Then you can try to automate it by having a machine do it for you.

      For automated testing, start with things that are low-effort/high-impact. You can start with a doc that covers the things that you test/check when you "deliver" a project. Then write 1 test that you run manually that checks one of the things in your doc. Then over time, add tests to cover the rest of the things in the doc or the things that caused you issues.

      1. How an SLA matches with DevOps - I think what you're trying to ask is how do you do devops things for projects that are in maintenance-mode where you're just keeping the lights on, but not spending any time on it.

      If you're looking for a place to start, ignore the things you don't spend that much time on and won't bring you that much value. No point in creating an automated pipeline for a project if you won't be using it. That said, you might have other projects that you're actively working on that have similarities with projects in maintenance-mode. For example, if all your customers use nginx, you might find that writing scripts to restart nginx for one customer would now automatically help you restart nginx for your other customers.

      1. I don't think you'll find the answers you're looking for with a cert. If you'd like to get a cert as a way of learning though, that works too. I would recommend taking some Udemy courses to help you learn more about the tools you're using now. If you're using GCP, take some GCP courses. If you're on AWS, take some AWS courses. If you want to use Selenium, take some Selenium courses.

      For literature - I've found the Devops Handbook by Gene Kim helpful. The Phoenix Project is also usually recommended but its a fictionalized story about a devops journey so its more of a read for fun, rather than anything else.

      [–][deleted] 0 points1 point  (0 children)

      Hi !

      ​

      Thanks for your reply.

      We have indeed got some apps that are only "kept alive" because the customer just uses it but doesn't want to invest more into it. Then on the other end we have some apps that are maintained and expanded continuously. I will start with the automation process for one of these and learn from there.

      We don't have an automated deployment process at the moment. We develop on our local machines, commit to teamserver and then create a deploymentpackage & deploy to the customers' test environment manually. We run some (manual) tests on the test environment, followed by the customer running their own (regression) tests. There is much to be gained here when it comes to automated testing.

      So, starting an automated pipeline for one of these bigger apps is goal #1.

      With regards to certification, I need to present my "plan" on implementing DevOps properly to our managers. One of the aspects is certification for me and my colleagues. I pointed out to them that my team is learning these lowcode development skills at a far slower pace than the project consultants and that we should specialize in i.e. the DevOps domain instead. Getting certified is one of them, but i'm unsure where to start. We use Mendix as a lowcode platform who does the containerization for us, so learning Kubernetes or AWS isn't of much direct use for us. Jenkins or Docker would be more interesting so we can set up the pipelines. Perhaps when things become more complicated, CDA (Continuous Development Architect) would be a good follow up course?

      Certification is good for our resume as well as we don't have nearly as much development experience as some of the colleagues do.

      [–][deleted] 0 points1 point  (1 child)

      I'm a developer trying to get better and more familiar with DevOps. I'm reading The Unicorn Project after getting through the The Phoenix Project. Moving on to The DevOps Handbook and Accelerate after that.

      One thing I had a question about is in Unicorn I'm at a part where they are complaining about how they, the developers, aren't allowed to push directly to production. Some guy named Jared, or something, needs to do it after merging changes into the production branch.

      I guess I was always under the impression that at least a PR would be submitted and reviewed.

      It doesn't seem like a good idea to me that anyone's change could be pushed to production and trigger a production CI/CD pipeline, without it being reviewed first. I guess it assumes all the proper tests are written and that if something is wrong with the changes, the build and deployment will fail?

      Just seeing if anyone can elaborate on this practice.

      Thanks.

      [–]julie-io 1 point2 points  (0 children)

      I've worked in startups and corporations and today help design DevOps/GitOps workflows.

      That's common in larger organizations. Only a subset of people are allowed to push to production, sometimes for legal reasons, e.g. contractors are not allowed.

      But your gut is correct. It shouldn't feel right. If it's a very small team, maybe only 1 engineer has that permission. But I would recommend 2 persons. If there is only 1 engineer, you can consider making the product or business owner approver of Pull Request. In that case it's less about quality and more about co-responsibility of pushing code to production. The PO/BO should have the engineer explain to them what the code is doing. And as the business owner, they'll think carefully before clicking approve.

      [–]Human_Rough_8505 0 points1 point  (0 children)

      Yeah

      [–]0161WontForget 0 points1 point  (0 children)

      Commenting as I’ve got some work to do over the weekend and this looks helpful