this post was submitted on 08 Jul 2023

6 points (100.0% liked)

DevOps

1698 readers

1 users here now

DevOps integrates and automates the work of software development (Dev) and IT operations (Ops) as a means for improving and shortening the systems development life cycle.

Rules:

Posts must be relevant to DevOps
No NSFW content
No hate speech, bigotry, etc
Try to keep discussions on topic
No spam of tools/companies/advertisements
It’s OK to post your own stuff part of the time, but the primary use of the community should not be promotional content.

Icon base by Lorc under CC BY 3.0 with modifications to add a gradient

founded 1 year ago

MODERATORS

[email protected]

Get into devops (programming.dev)

submitted 1 year ago by [email protected] to c/[email protected]

10 comments fedilink hide all child comments

Hello,

TL:DR Atmospheric scientist with knowledge of cli, python want change to a SRE job

Let me explain my background, I am M.Sc in atmospheric science with a few publications in the field, during my studies I work most of my time working with cli tools so I am confident with shell and cli tools, pipelines, stdout, stderr, tmux, etc. I worked using numerical model that you need to compile, this teach me tools like makefiles, modules and cronjobs to did it operational. I have experience with python and other scientific languages like R, Matlab. During my free time took some course of docker. Even I set up a Nginx webpage that I leave to die for lack of time or setup a raspberry pi to download "linux isos" using docker.

I really enjoy the automation of process, and help other colleagues to setup and install the environment to work.

I know my lack of networking, monitoring, and I'm not sure if my self taught skills (science standards) are comparable with a CS worker.

I want to learn or get the certification needed to get a SRE job to mid 2024.

Any advice, course or certication to help me to get in the road?

top 7 comments

sorted by: hot top controversial new old

[–] [email protected] 5 points 1 year ago (1 children)

I think you have an interesting background and potentially interesting technical skills, and I could totally see you catching on with someone and having a fantastic career. I could also see why it would be a weird or awkward fit, that you might be totally overwhelmed, and possibly even hate it. Let me qualify my answer(s) and see if that helps at all.

I feel like at its heart, being a DevOps is just being passionate about tinkering and technology. The best DevOps Engineers I know love nothing more than to nerd out about....well, all kinds of stuff. From K8s to Linux distros to build tools to code. DevOps is a practice, not a skill set - and that's reflected in the fact that there's no 'base' skill set for DevOps Engineers. I've known developers, sysadmins, even help desk type folks that found their way into the field and were successful. It just depends.

It kind of feels like you have the heart of a tinkerer, and the fact that you have a MS in a hard science suggests that you have the brainpower to hack it - maybe literally. :)

That said - what would worry me if I were considering hiring you is that you don't really have any exposure to Software Development Lifecycle concepts. Maybe I'm too stupid to understand all the acronyms above, but in my (limited) experience, having a good handle on SDLC is sort of the beating heart of DevOps - at least in part because being able to have the infrastructure ready to mate up with the code at the right time and right place is like, 80% of my gig. Too early is a security vulnerability (potentially), too late and the dev team misses all their sprint targets. You don't have to write code, exactly (although I wish I wrote more), but you have to be able to 'follow along' with the dev team. Especially when you're troubleshooting.

For SRE particularly - you have a lot of nice sysadmin-y type background skills, but particularly understanding design patterns and telemetry would be the thing I'd be most nervous about for you. Scalability as well - although that's hard for almost everybody. But for an SRE to improve reliability, you have to be able to really hone in on what's breaking - and once you've gotten the big pieces sorted, being able to understand resource usage, and all of that points towards good instrumentation (and good instrumentation practices).

I joke that reading logs is my superpower - both because my devs, bless them, don't do it, and also because if we've done a good job building the application, build/deploy pipelines, and infrastructure, your alerts and instrumentation will tell you exactly where any pain points are happening, and make it a lot easier to figure out where and how to focus your efforts moving forward.

So, after that wall of text - I'd point you towards the cloud. AWS is the largest/most widely known, but arguably kind of opinionated in terms of implementation. Still, AWS Solutions Architect is a pretty good 'gold standard' type certification. If you're more familiar with GCP or Azure, do the 'associate' level certs there.

Another obvious thing that I didn't see in your background - VCS. Git gud, as it were. I'm a big fan of hanging pretty much all your personal projects on GitHub. Mine is atrocious since I got hired, but before that I had a full year straight of commits. Sometimes it was impressive stuff, most of the time it was just messing around with code - but all the companies that gave me an offer letter mentioned it. Ymmv.

Finally - you might expand your search a little wider (SysOps instead of SRE off the bat? DevOps as well? Maybe going straight stick software dev, with your background, at a company where your science background would be a real value add is something to look at) and also be prepared to 'take a step back' if you do jump. I'd definitely hire you to see how things go, but I'd want you to come in as a Junior, and based on what you wrote above, that's probably a bit of a paycut for you.

TL;DR - Do cloud certs, practice on GitHub so employers can see what you're working on, consider SysOps/DevOps as well as SRE.

Best of luck to you!

[–] [email protected] 2 points 1 year ago (1 children)

Thank you so much, you did a fantastic job finding my weakness.

what would worry me if I were considering hiring you is that you don't really have any exposure to Software Development Lifecycle concepts.

Yes, I'm aware of this, I need to take some time to learn it and get familiarize it.

but particularly understanding design patterns and telemetry would be the thing I'd be most nervous about for you. Scalability as well - although that's hard for almost everybody.

Also true, hope some of these topics have an overview in a cloud cert.

I joke that reading logs is my superpower

I have similar experience with my colleagues when I was able to compile climate models, the difference was I spent some time reading the logs and look what's dependencies are missing or the path is wrong

Still, AWS Solutions Architect is a pretty good

Thank you I'll take this one

Another obvious thing that I didn't see in your background - VCS

I have some experience using git and svn, but really never work in collaboration with others, in my current work we used but only git without external service. Just to keep track of the personal work.

I'm a big fan of hanging pretty much all your personal projects on GitHub.

I need to use it more, I only use it for "more" important projects, Now I think is bad approach

Finally - you might expand your search a little wider (SysOps instead of SRE off the bat? DevOps as well?

For sure, I'll try a wider search, I always have troubles to find a job offer where I could met the requirements, thank you for suggest 2 jobs :)

Maybe going straight stick software dev, with your background, at a company where your science background would be a real value add is something to look at.

I have a "software engineer" job in a research institution, is only the title because I'm a research assistant most of the time with some dev time. The problem is there is no grow and the founding is through a international project, so the time is fixed.

and also be prepared to 'take a step back' if you do jump. I'd definitely hire you to see how things go, but I'd want you to come in as a Junior, and based on what you wrote above, that's probably a bit of a paycut for you.

My pay is not so high, is a EU salary in a semi-public institution, tho the pay is lower that the equivalent in the industry, but I'm above the average of at county level, I'll consider a paycut at least I could still pay the rent and past time with my family.

Best of luck to you!

Same to you, you are very kind with extranger a little lost about his future, I'm appreciate a lot the effort of you reply.

[–] [email protected] 2 points 1 year ago

I have some experience using git and svn, but really never work in collaboration with others, in my current work we used but only git without external service. Just to keep track of the personal work.

No this is great in and of itself - what I would tell you is to treat your github projects, even if you're the sole contributor, like you're working on a team. Checkout a feature branch, complete your code, then PR it into main/master/release/whatever, even if you're the one doing the code review for yourself. Even if you don't get to experience other devs (inevitably borking what you're working on) in the codebase at the same time, it'll give you a better idea of what the workflow should look like.

I have a “software engineer” job in a research institution, is only the title because I’m a research assistant most of the time with some dev time. The problem is there is no grow and the founding is through a international project, so the time is fixed.

My pay is not so high, is a EU salary in a semi-public institution, tho the pay is lower that the equivalent in the industry, but I’m above the average of at county level, I’ll consider a paycut at least I could still pay the rent and past time with my family.

This all makes the SRE part more understandable and more within reach. I wouldn't lead with, "I don't have any dev experience"; I would lead with "I've been a software engineer for x years, specializing in atmospheric modeling." Whoever is interviewing you will probably dig and figure out that you were a solo developer, but....you were still a software dev, and the first job in this industry is way harder than the next couple. Lean into that - you have the job title, you have the resume, you're looking to take 'the next step' into SRE/DevOps, because as a solo-dev, you had to handle all that stuff yourself, and you figured out that you liked it and were good at it.

We've all been the new guy trying to break into the field - pay it forward after you land that first SRE gig.

[–] [email protected] 4 points 1 year ago* (last edited 1 year ago) (1 children)

In my opinion, it really depends on what type of place you would want to work. There are a lot of options out there, but (specifically for SRE) "cloud knowledge" is a must most places.

I would consider someone with an SRE title more ops than dev, and wouldn't expect much in terms of writing code. I would more expect things like advanced knowledge of availablility, reliability, performance and observability on whatever cloud provider is being used. A Site Reliability Engineer is responsible for realiability of the deployed site, so it is dependent on the site/company on what the actual day to day would look like.

This isn't to say you wouldn't have a place in DevOps with your current skills. However, it may be an easier route to start more on the dev side than the ops side as, in my experience, ops are harder to learn generically because every shop has different processes and operations.

The dev side includes things like you mentioned (e.g. build/test execution/package/artifact publish/code release) and then mixes heavy into ops during deployment which then turns into SRE type stuff when the app is deployed to a real place. Often the dev side is done by people with Software Engineer type titles (potentially a DevOps team), and may even be done directly by the developers themselves.

A lot of these processes include a developer needing to execute locally as well as repeatable execution by an automated system of some type (CI). Linux and bash knowledge is very useful for these types of things, as most of the time end deployment will be on a Linux distro, although development happens on OSx or Windows.

The industry is already trying to change buzzwords, from DevOps to DevSecOps, so it is never bad to know security as well. Things like security vulnerability detection and remediation are very valuable and part of the "shift left" in terms of software delivery.

You are welcome to read my comment history to see my feelings about python in DevOps, but they are not positive, and should just use bash, unless it is actually a python shop and other people know how to use python, or else it will most likely become a security vulnerability in and of itself.

[–] [email protected] 3 points 1 year ago (1 children)

Thank you for a elaborate answer,

"cloud knowledge" is a must most places.

Yes, I will invest some time to learn about cloud. I'll search which one is most used in my area

However, it may be an easier route to start more on the dev side than the ops side as, in my experience, ops are harder to learn generically because every shop has different processes and operations.

You are right, I never have a administration role, I'm the link between IT and the researchers so I have soft skills of admin in linux but not have exp do it that.

Linux and bash knowledge is very useful for these types of things, as most of the time end deployment will be on a Linux distro

That's really good, I'm comfortable using Linux and bash

The industry is already trying to change buzzwords, from DevOps to DevSecOps, so it is never bad to know security as wel

I will let this like an extra, I need to fulfill other foundation skills, but I'll keep it in mind

my feelings about python in DevOps, but they are not positive, and should just use bash,

Yes I am in the same boat, python tend to slowdown or cause problems when we want get env with the other people in the group that only work with R, we try to use bash as much as possible. I'm thinking to learn golang to replace python.

With this I can make a better plan to leave the academia and get dev role, for me there's a lot of information, topics, technologies to learn in one year, maybe I was very optimistic.

[–] [email protected] 1 points 1 year ago

I think Go is good to learn. Many vetted open source Go tooIs use Makefiles (e.g. kustomize) which may be a good point of entry for DevOps in Go.

[–] [email protected] 2 points 1 year ago

The things I'm doing are mainly just as a hobby at the moment, so the advice of others may be more relevant to you, but I've learned a lot from and really enjoyed just creating a really overkill stack for a simple web app I made.

I'm talking setting up grafana for monitoring, using ansible/terraform, setting up backups, etc etc. Lots of just picking cool software I've heard about and trying to stuff it into my use case.

load more comments