SysAdmin to DevOps?

Development DevOps
1

Hey thanks in advance for reading and any insight that you can provide. I’d like to post here most often so here goes…

I’m around my mid 20’s and have recently moved country, previously I was the sysadmin guy, mostly on Windows but sometimes on Linux, however much of my Linux knowledge is homegrown. I’ve taken my country move as an opportunity to try and expand my horizons and would really like to try and move towards DevOps.
I feel like I have years to go before I’m fully there but I’d like to ask a few questions:

Cloud providers, especially AWS seem like a required knowledge base, how did you gain experience in using AWS, AZure, etc before you landed a job with AWS as a requirement? It kind of appears like you can’t reasonably access the enterprise stuff unless you have an enterprise bank account, but then where can you make your mistakes before your ready for the prime time?

In the development space, it seems rather popular for people to have their own online portfolio, blog or just a public github. In order to demonstrate their abilities. Is this also valuable for employers in DevOps and if so in what form? How do you show your extensive skill set in the many area’s other than just the interview questions? Or I guess how do you stand out from the rest outside of the interview stuff?

I’ll leave it at this, otherwise I could go on for a long time, what resources or communities can you recommend to me?

Now I’ll just stalk this post, All the best!

3 Likes
2

All them cloud providers just build APIs cobbled up on top of opensource tech, they take simple concepts and expose them in complicated ways.

I’d recommend you’d have learned how to develop/engineer software, and that you had familiarized yourself with kubernetes (build a pair of 10 node clusters at home, learn enough networking to have functioning vxlans). Learn how to load balance incoming traffic as well as multiple frontends to multiple backends grpc traffic using something like envoy. Learn a bit of ceph and ipfs cluster storage and cockroach , try spinnaker. Learn python really really well.

As for aws/azure/gcp/… the all have handy but not that handy rest APIs, they’re all cloning each others features and competing to move the dots in some random analysts magic quadrant. The big differentiator between these is thoe terminology and how they provide auth. There’s a gazillion third party companies out there selling consulting services and products that minimize people’s cloud expenses and claim to do something easy and awesome - don’t drink their kool-aid, learn your fundamentals, learn how to schedule workloads, how to auth those workloads to talk to other workloads, how to loadbalance rpcs and you’ll be good.

Focus on the fundamentals, the lifetime skills, basic software engineering and development skills and coding in any language and networking protocols that won’t be going anywhere for the next 20-50 years. And build yourself up one skill at a time.

3 Likes
3

This might sound annoying but the easiest way to learn something is to just do it. Azure and AWS both offer free tiers that include a small subset of services. Azure offers a $200 credit and you can use Azure DevOps for free I believe, you could set up automated builds/pipelines, test environments, etc. Throw the code for it on your github and then boom you have something new to add to your resume.

It might not sound like much, but if you have a small software project and you go through the extra effort to build a CI/CD pipeline for it, you’ll look great for entry level software engineer or devops engineer roles. Personal projects go way farther than you’d think.

1 Like
4

I went through the same journey you are aiming to start. I rose from Help Desk to sysadmin, learned about this thing called DevOps, and decided that’s where I want to be. So it’s definitely something you can accomplish.

Bash and Python are your friends. Learn them well. Learn a low budget editor like vim really well, too. Don’t forget things like Sublime and VS Code if you prefer those, but getting a really solid handle on those three things will serve you well in the Linux Engineer/DevOps Engineer role.

I used the AWS Free Tier Account. You get a year of full access under their free tier, which is 750 hours of usage a month. If you don’t leave stuff running 24x7 that’s more than enough.

GCP has a similar offer, but it is a little bit more complicated to use. Azure gives credits per month under their student/developer accounts.

Many of the services are free, such as AWS Code Commit, Azure DevOps, etc.

I recommend having a plan to utilize these services, such as studying for an AWS cert, learning something like Terraform, etc.

Yes. My website, GitHub, and podcast has come up in an interview far more often than my education and experience.

Start small. Install Apache and write a simple “Under Construction” site in HTML. Make it pretty with CSS. Give it a domain.

You can use Vultr, Digital Ocean, or Linode for your infrastructure needs. All of the above offer free usage in a form of credit. After that, I strongly recommend learning Apache or Nginx and using that to serve your web site.

Having a GitHub is pretty common among sysadmin, DevOps, SRE, and software folks these days. They now offer free private repositories, so even with a personal project you can host it on GitHub. GitLab is another service you might be interested in checking out. They have a bit more “features” but are essentially the same thing.

Speaking casually about complex technologies will come with practice and experience. I’ve been in I.T. for almost 10 years and in DevOps space for 2 years, and I still get tripped up on things. It’s no big deal. Learn to accept when you don’t know something and be willing to admit as much. Talk about how you would tackle a problem you’ve never encountered before. Don’t over think it. If you’ve never used SuperAwesomeMonitoringUptimeAPMTool, it’s perfectly acceptable to say “I’d send a curl request to see if the site is up.”

Have a passion in something inside of technology and outside of technology. My friend got an interview at the Microsoft campus in Redmond because he put he had a blackbelt in Gojo Ryu Karate and Brazilian Jiu-Jitsu on his resume. If you enjoy technology, start a video series or a podcast and discuss your interest or news in that field. Enjoy collaboration, learning, and sharing with other people. That will become infectious and you’ll take a guy crippled with burnout and exhaustion and rekindle the flame of his passion for technology.

Udemy has things on Jenkins, Terraform, Kubernetes, Docker, and various programming languages.

Checkout Colt Steele for his webdev bootcamp. It’s often very cheap and it’s hands down the best course for getting up to speed on JavaScript. That includes Node.js/Express and the stack around it (Linux, MongoDB, etc.)

Wendell also has a course on Udemy where he goes through some cool Linux tips and tricks.

There is a phenomenal course on Nginx that’s on Udemy too. It’s $10- right now and one of the more highly rated courses on Udemy.

WebDev, backend JavaScript, Linux, and Nginx skills will go a long way. Knowing how to operate and deploy those services on AWS with go even further.

I have mixed feelings about the Kubernetes recommendation, but if that’s something you are interested in, definitely check it out. Kubeadm was fairly straightforward in setting up. You can also use the AWS EKS service. After rereading @risk’s post, I am inclined to agree with it more. Especially that last bit.

Focus on the fundamentals, the lifetime skills, basic software engineering and development skills and coding in any language and networking protocols that won’t be going anywhere for the next 20-50 years. And build yourself up one skill at a time.

This is vastly more important than learning AWS services.

Eventually, something like Terraform would be useful to deploying to AWS.

2 Likes
5

Thank you very much for the extensive replies.

Focus on the fundamentals, the lifetime skills, basic software engineering and development skills and coding in any language and networking protocols that won’t be going anywhere for the next 20-50 years. And build yourself up one skill at a time.

I think this statement really resonates well with my journey so far in regards to getting the fundamentals right. In terms of programming I’ve had most experience in python and front-end but have also messed with bash, C++. It’s clear that the fundamental concepts I learned in python are now helping me learn other languages with much more proficiency. I can see this same ideology in Linux and many tools as well.

I’ll expand a little on what my plan is currently.
Right now in my own time I’m working on building my own technology based portfolio web site about the various tools and processes which I wish to learn. It’s taking a while because I intend to build it from scratch (still using programming frameworks). I’m doing it the hard way as right now I want to try and focus on the basis on the technologies used and don’t want a layer over that which may obfuscate the core aspects.

So the plan is to build my own blog/CMS and write about it’s creation and eventually if I can, get it working within a CI framework, writing about it the whole way though. If nothing else it’s serving as a great reference resource for me, so I can remember how I did a certain thing last week. Even though it’s a solo project, so it’s difficult for me to envision how it would work in CI at this time. 1 step at a time!

Bash and Python are your friends. Learn them well. Learn a low budget editor like vim really well

Yes, my Bash knowledge right now is mainly what I’ve picked up from using Linux many years but I want to become much better in this. As I’m probably considered a noob, I’m still trying to master redirection and pipes! I’ve told myself to use vim when ever I can.

Start small. Install Apache and write a simple “Under Construction” site in HTML. Make it pretty with CSS. Give it a domain.

I like this idea! Right now on my home server I’ve got services to host my own cloud (Nextcloud, plex media server, JIRA server) and so I’ve been trying to get my site to a point I’m happy with so I can setup a Nginx reverse proxy so I can host my site and nextcloud on a sub domain. I have all these dockerized so I could easily put nextcloud on another port, but it seems like a nice meaningful project to get experience in using the reverse proxy.

If you enjoy technology, start a video series or a podcast

I would like to start a small video series to go with the articles which I write for my site, however at the moment I’m sceptical if I can show my natural charisma at camera.
It’s also interesting you should mention those courses on Udemy, as I’m about half way through both Colt’s and Wendell’s courses you mentioned, but I’ll check out the Nginx one!

I messed with AWS on and off over the years but will be looking to get some more practical skills in this area when I can find the time to allocate to it, so thank you all for your feedback on this.

One other thing I was wondering, there is a lot of information out there on the tools used in DevOps. How to use them and set them up Terraform, Jenkins, Docker, kubernetes etc … However are there some production frameworks that you may follow? EG, in a team of devs you may use an Agile framework. Do you use the same principles and frameworks in DevOps or are there differences in the organisational tools used?

1 Like
6

I rose from Help Desk to sysadmin, learned about this thing called DevOps, and decided that’s where I want to be.

As a cautionary tale, make sure this is true for you, personally.

SysAdmin to DevOps seems like an obvious progression, but I was three years into it before I realized I actively hated every aspect of it. I like hardware, and I dislike interacting with coworkers who don’t realize that allocating memory is a hardware operation.

When evaluating your professional progression, check to make sure that the stuff you enjoy doing remains part of your job.

1 Like
7

Yes, you’re doing work, so are others, you’re managing time (your own or others), there’s always other people involved… it’s always helpful to you to understand common work methodologies or have experience with soft skills in order to accomplish anything.

1 Like
8

I recommend you read this book

Its important IMO to understand that a lot of tools like Kubernetes or frameworks such as Spring or Laravel or whatever are just plumbing and should be treated as lower level things and try not to marry your system to these things with such a high coupling.

1 Like
9

“DevOps” has become a buzzword mangled by consultants, what do you mean when you say DevOps?

To me (and Amazon, Atlassian, etc.) DevOps is a set of practices to shorten development lifecycles. There are no “required” technologies, it all depends on your environment what you could, and should, use.

Generally there is still a division between devs and ops, they come at the same problem from a different angle, where there is tooling overlap the usage of the tools is usually different between the two.

For ops, going more in the DevOps direction is learning about automated deployment and provisioning. I’m not sure what would be required for cloud deployments, but managing virtual machines, administering stuff like Kubernetes, and automating with software like Puppet would go on the non-cloud side (or the “in-house cloud”).

If you want to become a dev then you’re looking at, well, first becoming a dev, and not just a programmer (just know that the difference is seldom appreciated). The tooling on that end of the spectrum is more focused on automated quality control (test automation, static analysis), automated builds and automated deployment (which is where dev and ops tend to meet).

Any company that expects a single person to do all of the above imho needs to hire a therapist, not an IT-person.

On the topic of “the cloud”: it’s optional, as long as you automatically deploy it doesn’t make a difference where it goes, could be a bunch of CGI scripts to some Apache instances, as long as it’s tested and automated it qualifies as DevOps.

All that said I’d argue focusing on the tools is the wrong approach, DevOps is not a position, or job title (well at some companies it is, you likely don’t want to work there), just like Agile is not Scrum, or Kanban, it’s about finding a better way to get something out the door and handle changing requirements effectively without requiring ridiculous effort from your employees (and massive uncertaintly at management level).

As far as finding a DevOps job goes, my recommendation to get into DevOps at a competent place would be to see if some form of agile is practiced. (Good) agile and DevOps tend to go hand-in-hand, so ask them about build automation, CICD or how they automate their environments. If they only do agile and no other automation then their agile is probably “fragile” and I’d recommend giving them a pass, since agile without automation just doesn’t work particularly well in IT.
If you find a place then you’ll be able to just pick up the tools they use, instead of gambling on what would be “desirable” for the “market”.

10

Hi thank you for your information.

what do you mean when you say DevOps?

I’m using the term quiet loosely here as right now my background is Ops, and limited experience in deployment, mostly automation and improvement of existing processes.
However I do have great ambition to improve on my skills in development and really see great beauty in the agile framework.

So I’d like to work on improving my skill set to mainly be in Ops but have the opportunity to work with devs in a CI environment in the future. I don’t wish to be both Ops and Dev at the same time - Ain’t nobody got time for that.

All that said I’d argue focusing on the tools is the wrong approach

I’d expect that if I would want to in a sector that uses such tools then it’s expect that I have some knowledge of those tools if possible. I understand that the tools are not the aspect to focus on and it’s better to have overall foundation knowledge. I think the tools are easier to understand and use which is why it’s heavily suggested, while the actual principles are best grasped when actually faced with the problems presented in that role.

Thank you!

11

The likes of Puppet and Ansible are, from what I understand of friends that are in that space, the way to go. Anything related with monitoring is also high on the priority list, so log aggregation, metrics and monitoring, examples being Grafana, the ELK stack (Elasticsearch, Logstash, Kibana).

Of course virtualisation and containerisation are pretty important, so setting up VMs, containers and managing them. This has been covered already by others, but Kubernetes is a good one there, though there’s also Rancher (which is related to Kubernetes, firstly by being a fork, secondly, in the sense that many of the Rancher features eventually make it back into Kubernetes). There’s also RedHat’s OpenShift, so learning Kubernetes and ending up in an OpenShift environment might result in, well, having spent effort in the wrong place (I have a hard time considering learning anything to be “wasted time”,
and concepts will more than likely carry over since they’re both Docker underneath)

Personally I’d start by focusing on the creation and managing of plain old Docker via the command line, in my experience understanding what tools do for you makes you understand them better (and makes it easier to debug things when they do go south) and it also makes you appreciate them more for the work they save you.

Glad we’re on the same page there. Unrealistic expectations are a staple in IT, so you’ll have to pardon me for being careful here :slight_smile:

Any good company that’s hiring juniors will consider any prior knowledge a bonus rather than a requirement, focusing on the right “direction”, and, as has been mentioned by others, having the basics down, is, in my experience, a lot more important. At least when I’m interviewing I’m less interested in what they know now than what they expect to learn and what their thoughts are on an organisational level (eg. do they enjoy thinking outside of the box).

If probing for containerisation knowledge I’ll focus on Docker, any higher level tools are nice to haves and should be relatively easy to pick up if they have the basics down.

For programmers (since I mostly deal with those, so I’ll use that as an example) I generally probe for development methodologies, are they stuck in the mindset of the OO/Procedural languages (eg. Java, C#, Python,…) or do they actually understand different methodologies (set-based programming, functional programming,…).

Further I usually try to gauge their interest in topics not directly related to programming as such: do they only want to be code-monkeys, or do they have opinions about design/architecture, project organisation (eg. opinions on agile, relationship with other business entities, like operations/internal, or external customers, management,…), etc.

I’d also note that having some stuff on your CV that isn’t directly “marketable” at a job interview, but is IT related, is, at least to the more technologically enthusiastic interviewers, generally a good thing as it indicates you’re probably not just into it to get a well paying job but are actually enthusiastic about the field.

12

within a single machine?

13

Yes.

(for practice… that’s like 20 VMs which may be tight on a typical 16G ram laptop even with ksm, but at least ram is cheap these days, it’s not unreasonable to see 64G in a typical developer workstation)

14

I just figure out that indeed VMs are needed if I want multiple clusters (instead of single node cluster like minikube), which led me to vagrant + virtualbox or microk8s + multipass combos.
ugh, I need to figure out which one allows to assign storage to different physical volume since I only have 120GB (avail: ~42GB) on system disk

I only have 16GB in my desktop :confused:

kind might be the best way to go in terms of tight resources, but I’d opt for option that’s closer to majority of production out there.

15

Would be interested to know what option you went with in the end as I am looking to do the same, i have 16GB I7 which 120GB storage to use as a lab.

16

Containers go a long, long way at preserving resources. I used a RockPRO64 and three VMs to set up a little Kubernetes cluster. All in all it was like 10GB of RAM

Don’t forget that AWS and Google Cloud give you a year of “Free Tier” services. With something like Terraform or Ansible you could spin up a ton of resources, make a few requests/calls, and tear it all down in a few minutes.

17

so when you say VMs were you running on a base OS like Centos/Debian and then installed those via docker or did you set up 3 separate VMs and within that run your containers?

18

I have Debian Buster on a RockPRO64 with kubectl, kublet, and whatever else was required. It’s the control plane. Then I have a Dell T410 with CentOS 8 installed and KVM configured. I setup three virtual machines via KVM (also CentOS 8) and installed the same services that were installed on the RockPRO64.

From there, I “synced” the VMs to the RP64 (it was the “master node”). After that, I ran most commands through the RP64. I say “most” because if you build a container on ARM64 it won’t run on AMD64.

So a RP64 with Debian Buster + Kubernetes and containerd installed, plus the networking stuff.
Three CentOS VMs (on a KVM host) + Kubernetes and containerd installed.

Each VM was 2 CPU and 2GB of RAM. Don’t remember the specs of the RP64 but it’s like 6 cores and 4GB of RAM?

Ah, not even. 6 cores and 2GB of RAM

image

19

Great thanks for the write up, much appreciated :+1:

1 Like
20

I’m in the middle of this journey and have found it hard to be taken seriously in DevOps related interviews coming from more traditional sysadmin activities. To the point where every interview I’ve had has asked why I didn’t get a CS degree if I was interested in “developer” work.

I’ve also found my CISSP cert means next to nothing to these positions as they prefer to build their own tooling and often talk down about anything they consider archaic.

It really seems like many companies are treating DevOps/SRE positions as the dumping ground for low quality CS majors they feel wouldn’t cut it in SWE roles, this mentality is reflected in compensation and work hours for positions.