Ask HN: What can I do with my DevOps Experience?

Why do you think it’s gone to waste? We have large teams of devops/SRE at my (large big tech) company. Are you interested in SRE roles?

I’m not really in this area, but something like Google SRE handbook might get you excited about it.

Move into an adjacent field? What do you want to do professionally?

I am personally using it to leverage vast amounts of cash off people and using that to do stuff I actually give a crap about. The difference between me and you is that I have come to terms with this being purely an earner, which there is nothing wrong with.

two obvious ideas:

- learn server side language(s) & become backend dev

- get an IT sales job

You can work as a developer and have excellent ops skills through work experiance. The dev in devops. This is a skill that employers are looking for. Also since you have worked in operations you will understand better how to write applications that have good operational properties monitoring etc.

Move adjacent to do Security work. That is, all companies need security help, and they know it and will pay for it. You help them.

Often Developers see security as a distraction from building features, so working with companies to ensure they have strong security is a good career.

I worked with a bank building a "secure cloud" on top of a public cloud. That is, our team got a long list of requirements, like "storage buckets encrypted at rest", we'd watch public cloud changes, then alert or fix the issue. The bank got to use the public cloud, but also had a much finer-grained control of a lot of security concerns.

DevOps is a very loose term in today's market.

It can range from developer, to pure support engineer, to a jack of all trades, to yaml engineer, to CI/CD maintainer, to Google defined SRE.

Figure out what you want to do, and what you dont want to do, filter job postings and ask questions early in the process.

I'm a "Lead DevOps Engineer", and what that means at my company is that I lead a team doing all of our infrastructure automation(terraform, python), CI pipeline creation and maintenance, update and maintain all the non-prod environments (k8s, docker compose, swarm), infrastructure architecture on all major new projects (since we'll be building the automation to bring those projects up and maintain them), we also get everything else that seems hard to other teams. We build the tools and automation that we use, as well as the tools other teams use. This is important because we provide a common interface to all our teams, even though we work across AWS, Azure, OCI, and on-prem. The developers dont care which cloud their stack is on, that is abstracted away from them.

What we (DevOps) emphatically do not do is on-call. We have a "SRE" team for that (not SRE in any sense of what you think, they deploy new app versions to prod and manage datadog, and manage on-call, they are incapable of writing even basic python).

> However, I know that I do not want to do Ops work professionally

It'd be helpful to know why you don't want to do Ops work. There are many roles that fall outside of DevOps that have the same downsides (frequent oncall, unpredictable workloads, further from the product, CEO doesn't understand what you do, etc). There are also roles that fall under DevOps that don't have some of those downsides (infrastructure architect-type roles).

For example, there are people in the comments recommending security, which is great for job security, but generally bad if you want to do interesting work. Usually developers do most of the actually interesting security work while security teams check boxes for SOCII audits unless you're working for a security product, which can be pretty competitive.

Would you please care to reflect on the following problem area, which you might be uniquely positioned to understand and help address?:

Personally, I find it alarming and problematic (though understandable and not surprising, obviously) that so many industry (services, jobs, etc.) are dependent on the big three public clouds (G, A, and M).

- Those owners (and their tenants) can decide to boot customers on whatever (illogical, political) whim; I think this is not purely fantasy.

- Despite whatever portability may exist due to the containerization and microservice standards, those owners essentially practice the "capturing" of customers (and workers) through pretty complex sets of knowledge for running, deploying, and maintaining the services. (Always be upgrading, whether for features, security, API/tool/ecosystem/business updates, etc.).

Sure, there are many other hosts. But I think there is (maybe) something where one could say:

  1) Okay, it is (stupid and uncomfortable) to depend on G, or A, or M, given all that they do, even if they abstract away a lot of details the industry has come together to solve.

  2) The solution is (stabilize, document, and publish/educate) regarding a set of tools/practices for being truly "infra agnostic"--to build and run the same microservices, but on any given set of hosts that one can own/rent/etc.

I hope I made that clear. Maybe this already exists (if so, please tell me), but I'm pretty sure it's not optimal yet, if so.

For background, and some of the above motivations aside, as someone who worked in a big company that owned its infra and did not use the big 3, and seeing all the jobs requiring experience with (one of) the big 3 public clouds, even though studying up would be doable, it seems like a fool's errand to me and a huge turn-off to learn even one much less all of the big 3 public clouds' ins and outs, because I know they will just change and I know for sure they are not thinking companies that will do the right thing.

Anything you could comment on regarding whether this is or is not a real problem (or related to one) that you might be uniquely able to solve by leveraging your experience would be very interesting to hear.

Infosec. More money, no on call except for SOC roles. Lots of folks who need secure cloud envs, container envs, cicd, etc.

If startups/small companies are of any interest, there is often a large amount of horizontal maneuverability due to people often wearing multiple hats. For example I joined one startup (~12 employees) as the sole DevOps engineer but it quickly turned into not just DevOps but security (everything from dull SIEM monitoring, to red and blue teaming), database admin/optimization, backend development, customer onboarding, and even a little frontend. Most of those came through because I was the only one with experience handling them or a specific issue (but not always on paper) and I actively offered to help. I could have also avoided them if I wanted to, but when you can actually trust your small group of colleagues to not screw you over, its a good time branching out and learning new things at the same time. By the time I left I was spending most of the time doing security and hiring to build out teams (~100 employees when left), both my preference. Would strongly recommend small startups where you talk to the CEO practically every day and you get the sense employees are pretty happy.

Companies love people with infra experience and you can easily pivot if you show initiative, I did!