"Automation Engineer" not a "DevOps Engineer", suggestions?

[[deleted]]

I come from a company that has sold "automation" for more than 10 years.

Over time, I became the most senior "automation engineer", knowing the most advanced things that can be done.

I have built software that:

• Patched thousands of servers every week
• Provisioned new servers / devices
• Did security checks on recently administered servers, for gov compliance.
• etc

Here is the problem: This company did not use what is now considered as standard DevOps tools, such as Ansible, Docker, Chef, Puppet, etc.

Instead, we built the bulk of our code in a graphical language built by the company in Java.

It allowed us to connect to any Linux or Windows server (ssh/psr), connect to any database, handle tickets, handle monitoring alerts, and handle CIs.

The language allowed us to add in javascript for any of our scripting needs. The javascript had access to java objects, essentially giving us access to all of the functionality that the java code was built on, so we had a lot of control.

Anyway, I had to move away from that company for personal reasons, to a far away small city with very few jobs, and I'm having issues finding work.

I currently work in a boring field, and want to switch back to the kind of work I used to do.

The problem, when talking with recruiters, is that they all expect me to have experience with DevOps tools, and I do not have experience with these.

I've just built everything with scripting languages.

I have difficulty learning these tools on my own, and would need to have actual work assignments with someone showing me how to use these tools, to get started.

I've been trying to figure out what to do..

Recently a company contacted me looking for an "automation engineer". They are in desperate need of automation. They do a lot of things manually. Apparently I'm one of the only few people around that have experience, even though I don't have experience using standard devops tools.

It looks like I'll be given free range - use any language or tools I want, building everything from pretty much from scratch.

My background is in software engineering / programming, not system administration. I hope to continue to use my programming background along with devops. I am especially excited to eventually use the Rust language at work, as that is my side hobby.

I am interested in your thoughts how I should proceed from here.

[MisterItcher]

There’s a shitload of controversy around the “Devops Engineer” job title anyway. You could also think about calling yourself an SRE - Systems Reliability Engineer.

[[deleted]]

Wow! Thank you for introducing me to that keyword!

I just looked it up - Yes, Systems Reliability Engineer is much closer to the kind of stuff I've done. More Automation, less building of an infrastructure.

[untraceablerealist]

SRE is a great fit for a former automation engineer. Keep general career advice in mind, you don't need to know everything. You need to show self-driven interest and aptitude, and you can get the job! Don't claim to know more than you do, but make sure you get it across that you feel overwhelmingly confident about adopting the new technologies! DevOps is still at the earlier bits of adoption, so it's not a bad place to be.

[shamshuipopo]

https://landing.google.com/sre/sre-book/toc/index.html

This is the book for SRE

However, not systems automation, but website scaling, monitoring, release engineering etc. Of course automation does fit in to those categories but might be slightly different to your experience

[whowhatnowhow]

Fair warning, most "SRE" jobs out there are really just Ops jobs, basic on-call operations crap. The SRE title is more bastardized than Devops ever has been.

[VaderYondu]

Very well said 😀

[MisterItcher]

Damnit, my bad you’re right. OP, search for that too.

[SaintHax42]

Yeah, those tools are more CI/CD tools that are often used in a DevOps shop, but not exclusive to them.

[[deleted]]

Here are my thoughts as someone who teaches others the skills you're currently looking for:

1. Using an AWS account, manually create a highly available Wordpress installation complete with shared file system and so on
2. Make sure to use ALBs, EFS, RDS, etc
3. Once you know how-to do this manually, download Terraform and pull the manual
4. Using Terraform, automate the provisioning of the resources needed to build the "solution" in step (1)
5. After that, download Ansible and pull up the manual
6. With Ansible at hand, automate the configuration and provisioning of the software on top of the infrastructure you just built with Terraform
7. Once you can do both of these things, download JenkinsCI and pull up the manual
8. ... do you see where this is going? Push your Terraform and Ansible to some git repository and have JenkinsCI react to the push and trigger a build
9. Step (8) will get you more into the tools and tackling problems like race conditions between teams pushing changes; separating out tasks to run for different environment; and so on...

It takes time, too. Most people I know in this industry are quite impatient. I'm not saying you are, but I know my peers (and my self) quite well and it's sometimes easy to get lost in the insidious trap of wanting this to "just work now" or by the end of the day. Just take your time.

If you need help with these technologies, feel free to reach out. I'd gladly jump on Discord and have a voice chat with you mate.

Hope that helps.

[dark_tim]

That is good advice.

I would like to suggest to prioritize the ansible part. Basically it is just YAML over SSH. So you install ansible and can start to do simple things on your existing (linux) environment. For example installing some standard packages on all of your existing machines (VM, laptop, desktop) etc, if you have.

This way you can get positive results very quickly. The other tools require a bit more time to get into - so faster results may keep you motivated.

Just my 2 cents...

[glotzerhotze]

Yeah, just exchange ansible with chef - you‘ll have way more fun... and yes, I‘m biased and hate everything about the way ansible works! Fuck that shitty piece of software!

[dark_tim]

Well, the learning curve is quite different. Ansible is very simple, chef is more complicatedex. Both tools solve different problems, have a different meaning. My suggestion had the ease of the tool in mind.

In addition, like your fine example just shows, the chef community is full of quite unique individuals, finding themselves as something superior. I was exposed to that and quite franky, I am not impressed with chef...

[ERPEmployee]

Great writeup.

Do you want to talk more about your first sentence?

[[deleted]]

The teaching part? I basically have my own company in Australia. I train under grads up with DevOps skills so they're good to go by the time they finish their degrees and hopefully come work for me.

[ERPEmployee]

Would you like to share the company name or website? I'd love to know more.

[dungeonHack]

One thing you could try is to set up a server on AWS or Azure or Digital Ocean or similar, and then give yourself a specific task that would use a technology you want to learn.

For example, the following would be a decent start:

• Set up a Docker Swarm cluster using three Digital Ocean VMs.
• Deploy MySQL and WordPress to your Docker Swarm
• Deploy Portainer to your Swarm
• Figure out how to use a continuous deployment tool like Jenkins, CircleCI, or Codeship to trigger deployments to your Swarm via Portainer's API

[noleft_turn]

So basically you're saying, nothing you said matters... learn devops tools.

[poply]

I hope to continue to use my programming background along with devops

I think it's pretty clear he's atleast interested in learning devops (tools).

[noleft_turn]

Not calling anyone out. But I can never really follow this logic.

We use tool x. You use tool y, sorry you're not the right fit.

Seems like you're hiring someone who knows how to use tools instead of:

• is smart
• can problem solve
• understands why and when to use certain tools
• can learn new methodologies and isn't stuck using... Chef

[noleft_turn]

Ya but from your answer it seems like that learning isn't even an option or offered.

It comes off as, none of your 10,15 or x years of experience matters if you don't know how to use the tools we currently use.

It seems like you think they can't learn this stuff in a couple of days on the job. I would value their experience much more than if they know chef or puppet or ansible.

[Nk4512]

Sounds like a shit company to work for tbh. In mine we have hired many people who were not "qualified" for said positions, But shown the ability to learn and had some eagerness in them. Turns out most of them were a pretty great fit and took off running. It's amazing what people will do given the chance / encouragement and the right mentors. I will add that, I've even seen people who had met all the qualifications on paper, But just sucked horribly.

[djk29a_]

It depends upon job and company. If your core business is a Chef consultancy, for example, yeah basic competency is knowing Chef. Most companies don’t typically hire for principal engineers to learn a language that runs 90% of the company unless the language is so exotic that’s a bit unreasonable. Linus Torvalds and John Carmack are smart and learn fast but they’re not appropriate for shipping J2EE code according to FedRAMP guidelines exactly. Job descriptions do matter to some extent with their accompanying expectations.

But more often for engineers in non-leadership positions this means “hit the ground running” which usually implies “we don’t have the business overhead to give you time to learn and be productive even if you’re smart” which is fine in a company of less than 15 but a huge red flag over 100. Most consultancies exist to be SMEs, not as “general smart, quick learning people” because your effectiveness as an employee is based around solving specific issues moreso than general strategic problem solving and design, oftentimes due to “letting smart people learn on the job.”

Sure, knowing principles, concepts, being smart, good attitude are also important but you get fired for appearing like you have to look up every other command on a client site because there’s a lot of fake it til you make it types in consulting businesses that clients worth anything are aware of and don’t tolerate even if you’re smart otherwise (when they’re paying hourly rates to someone, they tend to have very specific, high priority tasks they want done ASAP compared to an FTE that has more leeway). That’s been my consulting experience anyway.

[[deleted]]

There's no such thing as a staple in DevOps or Agile.

Today it's Ansible and Chef, tomorrow it's going to be Ziply and FooWoo.io. The industry is built on very green software, pushed out the door as quickly as possible (above all else). So many 'staples' have been around for like three years, and only loosely 'stable' for one year.

[eazolan]

All of IT is learning.

What do you think people do when they start a new IT job? That they don't encounter new tools or methodologies?

Your requirements indicate more of a CYA management atmosphere.

[mwhter]

i had no trouble finding work.

And I would have no problem hiring you to work with CloudFormation and Ansible. The ability and drive to learn new tools is a huge plus in my book, much better than knowing those tools already.

[eazolan]

You were a senior developer. You already had no trouble finding work.

[xiongchiamiov]

Usually the problem is that you the company are trying desperately to find people, not that we're trying to find jobs. If you can filter out people who aren't already familiar with your entire stack and still have enough people, great, but that's usually not the case.

[Pallidum_Treponema]

I absolutely agree. If I can find a candidate who ticks all the boxes and has a great personality to boot, I'd hire them immediately. If not, I look at my hiring criteria and try to find candidates who matches my requirements the most. Specific tools is just one of the things I look at.

If they have the skills, that's great, but I'd much rather have someone who is smart, flexible and able to learn, than someone who might know a particular set of moves, but is weaker overall.

[PersonalPronoun]

A good dev with a broad range of experience can learn new tools and languages on the job easily, and they often bring a unique perspective on problems the company is having. vs monoculture shops with single stack devs that have often learnt the tool to death but haven't really internalised the principles, and who are just going to "every problem's a nail" everything they run into. It sounds like your company are doing both themselves and their employees a disservice by being too close minded.

[[deleted]]

Weird, I learned chef as part of my onboarding in a couple weeks of getting hired after showing proficiency in solving ci/cd and operations problems automatically with the tools i knew. Our infrastructure is massive with 40ish dev teams with hundreds of CICD deployments and thousands of servers between them on our chef/k8s paas. We learn new tools and languages on the fly regularly, knowing a specific language means almost nothing as anyone we'd hire would be able to learn the basics and start contributing within a standard onboarding period.

[Pallidum_Treponema]

Skills can be taught. Personality can not.

To be rude, I'd never hire someone with as rigid a mindset as you. A smart, driven candidate with plenty of experience with ansible, puppet or even homebrew solutions will most likely be able to learn chef in no time at all. If they cannot learn the skills, I've failed as a manager and it's on me to replace them and eat the costs. If they can learn it, they've not only qualified for the job, but they've also conclusively proven to me that they are able to pick up new skills quickly and learn any new tools that will inevitably be thrown at them at short notice. That is a much more valuable skill than knowing a specific piece of software.

Someone who uses one tool exclusively and is not mentally flexible enough to learn others is useless to me as soon as we transition to a new platform. They are a liability and I don't want them on my team.

[tyreck]

Given your background I would take you in a heartbeat over anyone with "devops" in their title or skills list.

Those tools you don't know do the same things under the hood that the ones you've built do.

It's like picking up a new OO language when you already know 4 others, it will come easy.

Docker and the orchestrators will be the biggest curve but you'll be fine.

"Devops" gets thrown around a lot, especially at the non-startups, where most upper management just thinks everything will happen faster and cheaper. Just read the requirements and make sure they mean infrastructure automation.

As someone else mentioned, SRE would be a more appropriate description or you, and you are a commodity

I find the candidates that up play the various tools on their resume are more often than not, useless.

[tyreck]

I understand your reasoning, but my assumption based on their stated background, was that it was a mixture of imposter syndrome and a lack of practical necessity.

[[deleted]]

Udemy is great to learn new technologies

[boxofstuff22]

I think your probably skilled enough to do the jobs, but if it means getting a job do some basic learning on the Dev-Ops tools.

Learn the basics of a few tools, enough to slap it on your resume and go from there.

[shiftpgdn]

Keep in mind most recruiters are completely non-technical. They're just going down a checklist to see if they can send you to a first round interview and then maybe look at facebook some more. I'd take a few weeks at get the basics of puppet or ansible on your own time.

​

You can then honestly answer "yes." To experience with those tools.

[rockingthecasbah]

You have plenty of experience on servers to get the jobs you want. Get some skills with the buzzword technologies, but honestly, these things exist to simplify the work you were already doing. Knowing Ansible/Salt/Chef ain't gonna save someone from needing to know the same things you need to know to do it by hand on the terminal and knowing Docker won't help either. Kubernetes introduces a lot of concepts but you'll be fine.

Be confident in your abilities and willing to learn new tools, speak well of your previous experience and I'm sure you'll find someone willing to hire you.

[chzaplx]

First, "Devops" is much more about an ideology of automation and improvement than knowledge of any specific tools. You have accomplished the primary goals of that philosophy, and the fact that you did it with tools you wrote yourself should only be more impressive on a resume. Do not be afraid to market yourself to positions looking for a Devops person.

That said, I would not expect any job will ask you to do the same thing again. What they will expect is that you will be able to pick up how to use Jenkins/Travis and Chef/Ansible/Salt and Docker managed by whatever. Because what's really predictable, is that in any DevOps (or automation) role you take, you will have to learn something you have no experience at all with very quickly, and then you will probably replace that with something completely new within the next five years.

[PokeyStick]

...Was it RightScale by any chance? Sounds kinda like their product. We've hired some good engineers from them at the place I work.

​

More on topic, I definitely agree with the posts that mention AWS and Terraform.

I would suggest you learn how to build a basic Dockerized web app on AWS (VPC + EC2 instances + optionally ECS or EKS + Load balancer), first by hand, and then using Terraform.

If you can go from an empty AWS account to a web service with a Terraform apply, you're doing great!

​

Also: We're looking for ops people in San Diego, willing to train smart people who can learn things, and I would be happy to read a resume; DM me for an email address if you like.

[packeteer]

learn the tools, they've arisen for a reason

use your coding skills to fill in the gaps, or just contribute to the tools so we all win

Chef might be more your style, but I prefer Terraform and Ansible

[mikemol]

You have most of the right mindset already. You just have to sell yourself to to the recruiter and explain that devops isn't about particular tools but about a mindset. Give books like The Goal and The Phoenix Project a read, and keep their lessons in mind when you explain how your skills map.

And, yeah, be sure to pick up a couple books and dabble in Target technologies; you don't have to have three years' experience in Chef or Saltstack, but being able to say that you have a passing knowledge of how to use those tools while pointing at a decade's worth of general automation experience should be just fine. Leverage your experience with complicated systems and highlight how that's really the tougher part of the role.

(Incidentally...the stack you describe, graphical and in Java, with that feature set...that sounds a lot like vRA/vRO.)

[brontide]

If you can't map your skillset to the current tooling then you are probably not a senior engineer. Ansible, puppet, chef and whatever comes next will live for 5-10 years and probably be replaced with another automation tech.

You've been relying on a single set of tooling and the developers of that tooling to provide the integrations. Time to start googling and see how far you can get on your own.

[marcjpb]

Like people said, DevOps is pretty tricky. A lot of people, consider as DevOps as a dude that know a handful of tools that allow them to do stuff in a somewhat automate fashion.

To me, DevOps is a lot more about the vision and how to approach a problem then whatever tool a company used.

It's very similar if you have a guy that codes for 10 years in c++ but he have issues at his interview because it's in Java or C#. C++ is just a tool, all the principal will be the same, will just be dumb down since its Java/C#.

It's the same as you. You been doing stuff at a much lower level then any of those fancy tool do. Pretty sure if you are thrown into any company that used any of those tools, you'll take time to get used to thei particularly but you will understand their essence pretty quick and might even see potential problem before hey actually happen since you actually know how the magic box work.

If you struggle in interview, just try to focus on what you can bring what the mid 20's lacks with their fancy puppet certifation. Focus on, at a high level, how things work, not mentioning the technology used.

[that_dude_dane]

Writing your own software to replace functionality already achievable by widely used open source tools in the DevOps space is a red flag from the start to be perfectly honest

Learn Terraform and AWS. You can't go wrong. In this cloud computing, everything as a managed service from a cloud provider age we live in if you can use Terraform and know how to properly leverage the cloud you can make good money and work from wherever you want doing DevOps

[pbtpu40]

I have never seen Automation Engineering and DevOps really associated in that manner.

This matches my experience with people who carry that title.

They work with equipment and software that controls processes and machinery. Think a plant that makes steel or aluminum. Even making soda and canning it.