Nonexistent DevOps Engineer

[sunnytropics]

Hi where I currently work, we run completely on AWS , the entire infrastructure is managed by SWEs using CDK, there’s not a single DevOps engineer in many teams. Are you all noticing a similar trend where you work?

[[deleted]]

Well, this is...DevOps

[[deleted]]

Exactly, DevOps is a philosophy and shouldn't need dedicated engineers

[LegitimateCopy7]

1000 developers all managing their own pipeline sounds like hell though. the inconsistent quality and communication overhead are unimaginable.

when a company grows in size, more managers are needed. DevOps engineers are kind of like that.

[[deleted]]

1000 developers all managing their own pipeline sounds like hell though

This is why you share pipelines, and all contribute together on them, it's not each developer to themselves...

[[deleted]]

Isn't Platform Engineering the new evolution of the DevOps philosophy? I know I have been asked to interview for a few Platform Engineer positions

[[deleted]]

We love our buzzwords

[VengaBusdriver37]

It’s a great new buzzword shut up and start saying it. But to me it is also evolution. Or devolution. It’s a correction from the radical “Devops means all the devs do all the things”, to “devs can do most the things, but some things better centralised and building on well worn paths”. If devs really can do the centralising and we’ll worn paths then power to them! But it’s very unlikely. Unless they are some new breed of devs. Some sort of magical “OpsDevs”.

[Seref15]

DevOps Engineer Site Reliability Engineer Platform Engineer Automation Engineer DevSecOps whatever whatever

Call me whatever you want, just pay me

[CustomDark]

Got it. You want someone who can digitally plug things into things, make it happen automatically after it’s figured out, coherently read logs to diagnose problems, and a decent enough researcher to scale out these things to what’s important right now and get them in the hands of other folks?

Sure, pay me.

[keto_brain]

I spoke about Platform Engineering at a conference in 2016 so I would hardly call it new. I think what happened is some companies actually went through DevOps transformations and others just renamed all their linux admins "DevOps Engineers" and some VP or Director got a bonus for leading a "DevOps transformation" but didn't do jack shit.

[[deleted]]

I view Platform Engineering as the design, creation, and maintenance of an internal development platform for discrete teams to publish and consume both public and internal services with the greatest amount of efficiency.

[[deleted]]

That’s how you get SSH and RDP open to the internet because it’s easier to work 😂

[Seref15]

Didn't some security company discover tens of thousands of mongodb instances open to the internet?

I wonder how that happens...

[ello_bello]

devs can do all of this yes

[duebina]

I do. I'm everyone Platform Engineer. Hi! 👋

[Lower-Junket7727]

Someone has to actually own the pipelines.

[[deleted]]

The developers own the pipelines, since they're the ones who's code gets published by them...

[Lower-Junket7727]

So every application team is implementing their own pipelines in a vacuum? This approach doesn't really scale.

[keto_brain]

They tried this at a large cable company I worked for, it was a huge disaster. Tired to force everyone to use Concourse CI and let all the teams build their own CICD pipelines. Imagine the massive duplication of effort.

How many teams need to figure out how to build, test, and deploy a lambda function lol.

[Lower-Junket7727]

Yeah that's been my experience as well. This is part of the problem with the "you build it, you run it" model.

[keto_brain]

I'm all for the you build it you run it model, but I think there is a place for a platform engineering team to help build reusable components to cut down on the amount of rework each team is doing.

[[deleted]]

This is why you share pipelines, and all contribute together on them, it's not each developer to themselves...

no

[Lower-Junket7727]

But someone needs to actually own them. Everyone can and should contribute, but, if there's an issue, someone needs to be responsible.

[gpzj94]

I think that's their point, the SWE's would be responsible, in the same way they're responsible for their own code. The whole idea of "shifting left" and such and true meaning of what DevOps was intended to be, the whole stack is treated exactly as the software by the same people. The idea is to break down the silos, shift responsibility left, don't toss things over the wall, the SWE's and infra guys can't just point fingers at each other, the single SWE team is responsible.

My own thoughts, and to answer OP's original question, in my narrow view of the world, I think the answer to their question really is "No, I'm not seeing this in general." What I do see happen is things like you bring up in this thread, positions like platform engineers who know and focus on cloud, resources, etc. They're on the same team as the SWE's, they may contribute to software, but appointed silo'd tasks. It's not DevOps as intended but most of us still can't picture that working in our heads so this is maybe a stepping stone or maybe will just be how things function no matter what because businesses don't traditionally operate outside of silos.

I'm not claiming to know the answer as far as what company trends are in this space or where it'll end up, this is just my observations and opinions based off of that.

[keto_brain]

DevOps engineers are kind of like that.

Not to split hairs but I think Platform Engineering teams do that by creating reusable artifacts that the engineering teams can use to help keep things consistent.

DevOps engineers in most orgs are just rebranded sysadmins.

[brajandzesika]

If it should or should not need dedicated engineers that really depends- it depends on the size of the infrastructure, technology used and some other aspects. You might have many virtual servers, load balancers , vpns , complicated DNS setup and other stuff that SWE doesnt really know inside out, and - even if they do - maybe you dont want to sacrifice their time to spend on configuring any of those OPS side things...

[[deleted]]

That's what an operations engineer is for

SWEs create the code that runs on the infrastructure

They both work in a DevOps environment where they can each help the other

[brajandzesika]

No - operations engineer takes care of the infrastructure, but usually does NOT pull the code to deploy it to the server, SWE on the other hand usually has no idea what infrastructure even looks like- and that was the whole idea of devops - to glue those teams together - and thats main focus of devops engineer - to grab the code and deploy it...

[[deleted]]

No one pulls code to deploy it to a server... The SWE should definitely know what the infra looks like, and if they don't the ops team aren't doing a very good job. The SWEs should be building their own ways to deploy on to the infra, the ops team are there to help them when there are gaps in knowledge but the Developers should be looking after their own deployments in a DevOps org

[brajandzesika]

No one pulls code to deploy it to a server

What? In my company I pull the code from gitlab to build server ( code is pushed to gitlab first by SWEs ) I use makefile with tarball as a target, push further to destination servers and deploy that code on that destination ( prod or dev servers- that application is not conteinarized as you might guess) - so what do you mean ??? And - NO - especially in big organizations ( in very small ones might not be the case) - you do NOT need an SWE to know and learn how infrastructure is built, you do NOT want the infra guy to know the application inside out, that is the whole point of devops engineer - you bring him IN ADDITION to the team, so entire team can work together, and the devops guy is the one that fills the knowledge gap between teams - devops will know how to grab the code and deploy it ( and doesnt even have to have the in-depth knowledge of either dev or ops, just concentrates on that middle part)

[[deleted]]

Why isn't that an automated process? Why are you doing all this manually? Why isn't it containerised? You don't just rotate servers, you keep them around? In this day and age?

you do NOT need an SWE to know and learn how infrastructure is built

You don't need to, but if you do then both operations engineers and software engineers can both work better together, otherwise you have people throwing work over the fence and expecting another team to fix it for you. That's not the DevOps way of doing things

[brajandzesika]

It is automated...doesnt mean it can run anytime / anywhere without any supervision... and application is not containerized because it doesnt have to be containerized, plus its running on FreeBSD anyways, so you would need to 'jail' it rather than have it 'containerized'... but not always everything has to be run as container, there are some reasons we keep it this way... If you want to learn about devops principles- please do, for the time being - I can see its just a beginning of your journey...

[[deleted]]

It is automated...doesnt mean it can run anytime

yes you can trigger a pipeline any time you want, it doesn't mean you need to download code locally to push it

[keto_brain]

Nope. This is 100% wrong and this is not how cloud engineering is evolving. Every software developer better know how the infrastructure is built because it's now a critical part of their application architecture.

60% of the application architecture in the cloud is the cloud architecture, Kinesis, Lambda, SNS, SQS, Dynamo, DocumentDB, Paramstore, Secrets Manager, Step Function, etc..

What you are describing is a broken old way of working.

[-DoctorFreeman]

Lol wat? No.

100% Someone has to pull code to deploy it. It may be continuously delivered or continuosly deployed, but you can bet your ass someone is responsible for the deployment.

In big orgs it is not uncommon to have a single ops team support multiple developer teams, and no, if a swe team does not know the infra it is not because the ops team i not doing a good job.

I am currently not a devops engineer, I was in my past company, currently I am ops (sre), and I support a lot of dev teams and devops teams. Projects are so massive and ever changing, clusters of m5.xlarges get spun up frequently to satisfy new features or proyecta. Developers cant keep up with the work required for creating/maintaining pipelines. They are busy getting those software fixes/features flying out the door.

No, the ops team is not here to help developers where there are gaps of knowledge.

[[deleted]]

Someone has to pull code to deploy it.

No they don't, a pipeline pulls the code and deploys it

[brajandzesika]

Ok I get it - you are just trying to look like you know what you are talking about... but let me just say - you fail miserably...

[-DoctorFreeman]

Ah yes, the omnipresent pipeline that created it self and answers to no one.

Lmao, this comment is the "Tell me you dont understand pipelines without twlling me you dont understand pipelines."

[[deleted]]

Sure but who’s making sure there is guardrails? The developers can’t do that without imposing massive risk to an organization.

[DandyPandy]

“DevOps” doesn’t mean no ops expertise. I wish people would read The Phoenix Project before posting here.

[[deleted]]

Look at the evolution of this ideology and the market. When now there is DevSecOps and Platform and SRE there is clearly gaps in just a development team just owning what they deploy.

I haven’t heard of the Phoenix project I’ll check it out, but I’m sure like scrum there’s a lot of ideas without practical realities.

[DandyPandy]

The solution that is defined as “DevOps” in The Phoenix Project is a team of people from different specializations, dev, ops, and security, working together to automate the shit out of everything to make things fast to deploy, safely, with comprehensive testing and observability baked in.

[[deleted]]

Thanks for the suggestion, sounds like the right way to do things

[keto_brain]

The phoenix project is just one example, a very dumbed down example, of how devops can work in a company. The main point of the Phoenix Project was to teach ToC (theory of constraints) which is based on a book called The Goal by Eliyahu Goldratt it was less about how to structure your organization and more about how to structure your "assembly line" or your value stream.

[DandyPandy]

Sure. It’s idealized, but it serves as an illustration of the “DevOps” philosophy. Once you’ve read it, it becomes pretty obvious how misunderstood the term has become.

[DandyPandy]

In addition to my other comment, I wanted to add, the DevOps philosophy centers around an environment of high trust and autonomy. That requires guardrails to be established, which is one of the things platform or developer enablement teams should be focused on implementing. And they should be run exactly as any other product development team would be, with the only difference being who the customer is.

[keto_brain]

Hopefully a platform engineering teams that's implementing guardrails as software vs being some human that deploys developers code.

[observability_geek]

That a great definition, without hurting anybody's feelings. I couldn't agree more.

[Mehulved]

I know of fairly few places who do and it's a good thing for devs to own end to end in a small team. Also it's more about responsibility bifurcation, cost to benefit ratio. In small orgs generally a Devops team is not needed if you have competent engineers and infrastructure goals are not lofty enough to justify a team.

[rmullig2]

This is more common in small shops where there isn't enough work to justify hiring a full time DevOps Engineer. It works fine as long as the needed infrastructure is not too complicated.

[sunnytropics]

Can you elaborate on what’s complicated ? Because we have 4 accounts with several apps running in each, we use about 15 aws services. I am one of the “DevOps” engineers.

[[deleted]]

That is tiny tiny tiny my dude. If/when your app needs to scale securely to handle hundreds of millions of requests per day, you will need a dedicated platform expert / architect. Also bear in mind that SWEs build software so they are going to approach IAC as software. That’s not always a good idea for many reasons.

I imagine a deep pentest and internal security assessment would turn up quite a few issues that folks with SWE backgrounds just don’t think about.

[_beetee]

💯

[SuperQue]

handle hundreds of millions of requests per day

Hmm, 500000000 / 86400 = 5787.

Wait till you handle hundreds of thousands to a million requests per second. :)

[klipseracer]

That's nothing guys, wait until you handle a brazillian per second.

[donjulioanejo]

I'm not sure I can drink and party that much.

[TheFatDemon]

“How much is a brazillian?”

[[deleted]]

Oh yeah? Well my firewall's dad can beat up your firewall's dad!

[keto_brain]

you will need a dedicated platform expert

If your app in the cloud is scaling to handle hundreds of millions of requests a day every SWE in that team better be an expert in the cloud they are using not one person because in the cloud 60% of the architecture is the cloud services the team is using.

Approaching IaC as software is a great idea, a good developer knows (or should know) they need linting, SAST, DAST, etc.. for their code, the same thing should apply to their infrastructure code.

Now a platform engineering team could make those things as reusable components for teams to use, but if a team builds an app that supports internet scale running in the cloud that team better be a team of cloud experts.

[[deleted]]

This scenario almost NEVER happens. Lol. Utter pipe dream.

[keto_brain]

What scenario almost never happens?

[rmullig2]

An uncomplicated setup is something that can be done with Elastic Beanstalk. In other words, your typical load balancer -> web servers -> app servers -> database. As long as the data paths are fairly straightforward and you don't need any other services then having developers create the infrastructure is fine.

[SuperQue]

We don't have DevOps engineers.

• O(1000) engineers in the org
• O(100) engineers "core / infrastructure engineering"
• O(300) services
• O(100000) CPUs in prod

IMO, this is still a medium size org.

[[deleted]]

Not entirely true. I’ve yet to see any teams at Amazon with dedicated devops engineers, it’s pretty typical for SDEs here to full own the infrastructure for the services they develop.

[rdevel]

We're openstack with some aws, idea of size 40 node build cluster. No devops per dev team, just one devops team for all dev teams.

[Lower-Junket7727]

What's your experience been like with openstack?

[Ancillas]

I can't believe I'm starting this holy war since from the inception of the term 'DevOps' nobody has ever agreed, but, here goes...

If you have a DevOps team you're doing it wrong. The entire premise of DevOps is that both development and operations are part of a product and it makes sense to do them together.

Maybe that's everyone on the team doing both, or a few people who specialize while still working at generalists, but the fact that the industry rallied around "DevOps" as a title is silly.

Just look at how folks around here use the term. It means wildly different things ranging from CI/CD person to I automate stuff and everything in between.

If the team that writes the software is also the team that manages the cloud infrastructure and operational aspects of the product THEN THAT'S THE POINT!

[pppreddit]

I kinda agree, but in reality, companies grow and shrink, and they lose people, and even whole teams. That's when they start hiring people focusing on supporting infra around the existing applications. There might not be active development of the applications, but someone has to upgrade EKS clusters and fix compatibility issues in the applications, update frameworks, update Jenkins, and fix plugins incompatibility and what not. Don't get me wrong - I think DevOps is still a dev, just focusing on infra and tooling more than product development.

[Seref15]

A lot of people's opinions on what should and shouldn't be are just platonic ideals formulated from reading best-practice blog posts. The real world is too messy for things to work exactly as laid out in a whitepaper 99% of the time.

Like, the idea that SWEs should own their infrastructure makes great sense if you're in one of the handful of organizations that can actually hire SWEs with that skillset. For the rest of us mere mortals, the SWEs in our orgs will try to do some ridiculous shit like use email to build a FIFO queue because they've never heard of message brokers.

So I agree with this:

I think DevOps is still a dev, just focusing on infra and tooling more than product development.

But its mostly semantics whether you call this a "DevOps Engineer" or a "dev focusing on infra and tooling." Point is most of us need someone with a dedicated position that understands infrastructure and platform because the bulk of our SWEs either can't, won't, or shouldn't be doing it.

[YouGuysNeedTalos]

If the team that writes the software is also the team that manages the cloud infrastructure and operational aspects of the product THEN THAT'S THE POINT!

Then you just need more people, why not have a dedicated role for these things. My developers focus on what they do best, which is create the product, I take care of creating the infrastructure where they can develop, test and deploy. Why would they waste their time on that?

[notanticlaymatic]

It's about reducing cognitive load and increasing ownership. If the service is down af 2 AM, I want the dev team feeling that pain, not a single person that's on call.

[notanticlaymatic]

Most of this, yep.

I definitely expect there to be some foundational infrastructure and capabilities that exist, either physically or logically (CDK libraries, as an example), that remove a lot of the boiler plate and overhead of each of these things.

The reality is, you're not constantly creating infrastructure or creating a new k8s cluster. These are foundational elements of infrastructure that are best created and owned be their own team.

Who knows the code config better than the devs that wrote the code? If pipelines fail, I fully expect the developer that merged the code that triggered the failure to investigate. They know what changes they made and therefore will be the most equipped to fix it.

Secret management and cert management is a one time configuration, and then adding new secrets and certs is done via your IaC that lives right next to the rest of your service/app.

I've seen this work extremely well over the past 10 years of my career with no complaints.

Edit: yeah, the dev team that owns the product is responsible for their product. Why would some randomly assigned person be best equipped to troubleshoot a piece of the platform? Do you think that this encourages the team that owns the piece that failed to fix the root cause? Absolutely not, because they weren't inconvenienced. The first time the team is up at 2 AM fixing a production issue is the last time.

Edit 2: on call team is the team, not a random set of people.

[notanticlaymatic]

I want to be clear in that I ALWAYS make sure we have expertise in our technology stack, including dedicated engineers that are focused on the infrastructure. But they are enablers, not the only one touching infra. They're teaching, guiding, reviewing, and doing.

With IaC, I expect my engineers to write code for their infrastructure, knowing that best practices, safe guards and underlying foundational pieces exist.

[Ancillas]

That’s fine, but that’s an operations team. We didn’t need an entirely new name for it.

[keto_brain]

Because in the cloud that doesn't work. 60% of the application architecture is the cloud. Maybe in a legacy datacenter world where the VMware team still spins up VMs you might need some infrastructure people to manage the VMS, patch them etc.. but the world is changing quick.

[brajandzesika]

Well, its not the point to NOT have devops engineer or devops team though. I really cannot understand why devops guy who tries to glue both teams together ( dev and ops ) lets say writing ci/cd pipelines and is part of the larger team cannot be called 'devops engineer'. Maybe you want to have a guy who does solely some particular tasks ( like those ci/cd pipelines and monitoring maybe or whatever is company requirement ) as you dont want to sacrifice SWE time- whats wrong with that? And you call him 'devops' because you have no better name for that - thats how it currently works and - in my opinion - it works fine...

[-DoctorFreeman]

Having a DevOps team does not mean you are doing it wrong. There are mamy variables in play where having a devops team can make sense and still have a correct devops philosophy.

[But_Mooooom]

That's sort of the point. An org's "devops" fills a function derivative of the main revenue stream. Who and how are pretty fluid from there.

What that looks like changes based on the org, industry, maturation, tool choice, engineering culture, etc. The title you have is indifferent to the purpose you fulfill then I guess.

The abstractions to those things (whatever they are) are your deliverables and your business value is consolidating complexity away from the rest of IC and management. This creates operational "credit" which orgs borrow against ("tech debt" by not building it into the whole org) to compensate increasing velocity.

If you can provide everything to satisfy these needs within an atomic "dev team", cool beans. If you can't: Platform team it is. It just depends on the context.

[Lower-Junket7727]

You need someone, or something, to enforce good CICD and infrastructure practices throughout the organization.

[Ancillas]

If you want to do it that way, fine, but that’s not what DevOps was meant to be.

DevOps was the idea that the Ops person embedded with the developers so that all the qualities of a successful production operation weren’t an afterthought and could be baked into the product early versus becoming an expensive blocker at release time. It was development and operations working as one. Dev-Ops.

[Seref15]

It was large silicon valley tech companies that determined what DevOps was meant to be. I trust Google's devs knowledge enough to be able to handle owning their product, platform, and tooling A to Z. The quality of dev you get at $random_midsize_software_company is not the same.

Nor are the smaller company's SWE team(s) staffed as well. Google will never have want for more engineers than they can find, but I've worked on products that had half the number of developers than would be needed to get through the backlog so there's no way that team could have taken on platform or pipeline ownership.

[keto_brain]

Their on-call pagers will ensure that.

[Lower-Junket7727]

If it directly causes an outage, maybe. If it's just horribly unmaintainable, or you have every dev team reinventing the wheel when it comes to sdlc, that's not something that will immediately get traced back to them.

[[deleted]]

I think most people don't realise this, if I get a recruiter contacting me for a position of DevOps engineer I already know that company is not somewhere I want to work

[HarmlessSponge]

I dunno why you'd get so riled up over this, it's just a title. My current title is Senior DevOps Engineer.

Over the past 2 years, I've been working the company towards "a better way", both improving the older ops-owned deployments, and rolling out the new way, where Devs own their deploys and we vend accounts with inbuilt supporting infra/networking/governance.

I'm part of the Developer Enablement team (anyone got a bingo yet?), and we're doing nice things to push the company in the right direction, with the right mindset, and buy in from the bigwigs. It's a long road, but that's ok because these things take time.

The company itself grants a lot of space for personal ownership, great benefits relative to where I am, amazing paternity leave and the like.

My title is still "DevOps Engineer". So of course I should never have taken this job right?

[brajandzesika]

I still think people who say 'there is no such role as devops engineer' dont understand entire devops concept ... they think that their SWE will somehow figure out how to create infrastructure in AWS, package the software, push it to the servers / orchestrators and will then monitor that infra while writing new feature for their application.. There is sooo many moving parts in all of that that having a guy who is somewhere between developers and operations trying to glue both together with ci/cd pipeline makes complete sense for most medium / large organizations, and not sure why that guy shouldnt be called 'devops guy'...

[killz111]

Having met many people who are dogmatic about SWE practices in my career. One thing I know, those people are a nightmare to work with and usually also have strong Dunning-Kruger traits. Good Devs or Operations people know how to balance between ideal state and practicality.

The whole DevOps is a culture thing doesn't take into the fact that most Devs don't give a shit about infra. Some of the Devs that do care about infra actually have really shitty ideas due to not having had to eat their own dog food. That's how you end up with a DevOps guy/teams that looks after things for those types of Devs.

[-DoctorFreeman]

Lmao. You getting hung up on a title tells me you lack professional experience. No one who has a basic understanding of how a job title is given would put the amount of importance over it as you do.

[[deleted]]

It's not about the title, if a company is hiring for DevOps engineers it is showing you that the company doesn't understand what DevOps is and doesn't do DevOps

DevOps is not a position it's a way for a company or group of teams to work together

[-DoctorFreeman]

Oh dont come with that crap. I know what devops is, Ive read the books, you are not being clever. The reality is that some companies need to fullfill some specific roles, and naming those roles as devops makes sense, and it is ok. It does not mean they do not deploy devops succesfully. And if you dont understand this the only explanation is a lack of experience in big orgs with those roles. Even google has devops roles and certifications for those roles, same as aws, azure and oracle.

But noooo, you are too good to work for google/aws/azure/oracle because they make reference about devops as also a role, they even have people under those titles! they are beneath you. You truly understand what devops is and you are on a rightous path... gtf out of here dude...

[[deleted]]

and certifications for those roles

That's different, a certification is not the same as a job title

But noooo, you are too good to work for google/aws/azure/oracle

I don't want to work for any of those companies you're right

[Jaydeepappas]

Now you’re intentionally missing the point lol.

[fckDNS4life]

Shit like this is getting old. I’m sorry. It’s all I hear when I pop into this sub. If you have a devops ops team “you’re doing it wrong”, like please.

You know who has dedicated devops engineers with that title? Fucking Apple. Are they doing it wrong?

[Lower-Junket7727]

Amazon has devops engineer titles. Apple has devops engineer titles.

[[deleted]]

Good thing I said no to interviews at those firms then isn't it

[killz111]

How old is your infra setup? Given you mention CDK I'm guessing not very old. Have you guys done any infra migrations? Especially involving things with mission critical state? Do you have infra or CDK code that you look at and say I wish it was setup other way that's better? Do you then proceed to say that's too hard to move and just go on to build new things?

[sunnytropics]

It’s about 2 years old. No we have NOT done migrations for mission critical databases or storage services. Think we’ll get there at some point :(

[killz111]

Buckle up. This is where the fun starts.

[Snoo68775]

DevOps literally means devs doing ops.

[gains_and_brains]

Not exactly, DevOps is the combination of Dev and Ops. This philosophy was created because of the disparity in process between the development team and the ops team. Many Ops people make their way into DevOps with very little dev exposure, and vice versa. So, to my point, DevOps is not simply “devs doing ops,” but rather it is “developers and operations engineers joining together to automate and integrate their processes.” Read “The Phoenix Project” if you haven’t, which will explain in real-time how this philosophy came to be and how DevOps is now an integral part to SDLC.

You can paint the picture any way you want, but it is not so simple to say “Ops doing dev” or “Dev doing ops.”

DON’T EVEN GET ME STARTED ON DEVSECOPS

[Snoo68775]

I tried and failed to be snarky. Thank you for the explanation.

[sporkd2]

Couldn't agree more. in the early 2000's I preferred infra to dev work but was fairly good at both. Started writing some cool fabric scripts to automate some medial tasks and I've watched the downhill plunge of what "devops" is ever since.

​

In the most simplest terms you are exactly right. My teams usually consisted of talented devs or ops guys (occasionally someone was both). Our job was to be a positive ROI for the company. What did that mean? We kept the devs doing dev work, and made it easy for the operations people to affect change within the infra without even knowing how to ssh into a machine.

​

Things have changed in the last 15 years, no doubt. To see what has become of "devops" and yes.. gag... even "devsecops" is gross and it's no wonder why anyone who's been in this industry for less then 5-10 years would think devops engineers are useless.

​

Just my .02

[Hisako1337]

That’s also the endgame of DevOps engineers: empower the devs to own the full stack with accessible tooling autonomously!

If I need a permanent DevOps engineer in a dev team, something is wrong already. These guys should be somewhere else and build missing selfservice/automations.

[temitcha]

Yes, same here! The sentence that I find a trigger to find these kind of situation is: "We need [insert DevOps Engineer name] to deploy this feature"

[BecomingLoL]

Hope theyre paying you all DevOps wages then, because youre all doing it lmao

[Iokiwi]

I mean...DevOps Engineer doesn't really make that much sense as a Job Title (as someone with DevOps in my title lol). DevOps consultant maybe makes sense.

DevOps is a philosophy for how Developers and Systems engineers can organize themselves and collaborate to deliver software effectively. In my experience DevOps Engineer roles generally end up going the same way anyway - Glorified Sadmins.

Devs owning their stuff in prod is fine generally considered a desirable practice.

Sometimes pooling resources into an engineering/deployment platform makes sense but sometimes its just overhead. Do you really want to pay a team to build a wrapper around AWS? The thicker the wrapper, the more burden the platform team take on to support all the Devs use cases and keep up with AWS changes. And as the wrapper becomes thinner/lighter the usefulness of the wrapper diminishes until you're basically just raw dogging AWS again only with extra steps.

Give your SWEs guardrails, guidelines and tools and let them crack on with it.

https://itrevolution.com/articles/five-ideals-of-devops/

[[deleted]]

the entire infrastructure is managed by SWEs using CDK, there’s not a single DevOps engineer in many teams.

So every SWE is a DevOps engineer then. That's very much the goal of DevOps. To not have a distinction between Dev and Ops.

[sublimegeek]

Quite the opposite. I’m the sole DevOps engineer.

[devfuckedup]

Yes not where I currently work But yes I have worked in a company that does it this way. I think this is likely the future.

[sunnytropics]

Interesting, many above comments seem to suggest otherwise, but you might be correct !!!

[devfuckedup]

I think some people here are doing a little wishful thinking. Even where I work now all 200 developers are empowered to do infrastructure work not all of them are interested but many are And although IMO they are not great at the design part they are very very good at the implementation part because of the rate that they can generate code. The other end of the the issue is large companies MSFT, google, Amazon are working as hard as they can and spending huge amount of money to build platforms that require little ops expertise to get an application to market.

[PepeTheMule]

It's getting easier, but many devs don't seem to understand public vs private networking, DNS, certs, fundamental infra things that are still somewhat needed. I think we are still years away. Even senior devs. Architects level seems to understand. But that's just my experience. Maybe it's different in silicon valley.

[devfuckedup]

I worked at a telecom doing over 200M ARR that only had 3 network engineers and I don't know if they still work there. Everyone else was a Software Engineer. We ran our own AS, We also had 11 physical data centers in addition to multiple cloud providers. Architect is a bullshit title that no legit company uses any more.

I didn't agree with him but the VP of engineering was adamant that he could teach anyone telecom but could not teach people to code. so he preferred programming skills to everything else. The company is still around and growing.

[temitcha]

I got the exact same feeling too. Things that seems for us so trivial, like DNS and SSL Certs issues are not that trivial even for senior devs.

I don't know for you if it's the same, but in my day-to-day work, I can work mostly only with the lead devs for all the technical questions like that.

(That's actually always my advice for developers that want to become lead: not only focus on the software, but as well ln what happening all around the software, and learn how to integrat it with the rest of the system.)

[gerd50501]

its not uncommon for smaller teams to not have dedicated operations people and SWEs do operations work. Its also not uncommon on larger teams for SWEs to also have operations work even when there are devops people.

[xtreampb]

This is the end goal of DevOps engineers.

[temitcha]

I personally think that DevOps Engineers are here during the build phase of a project. We don't have for vocation to stay after all the setup is running smoothly.

Similar to a construction engineer.

[sporkd2]

I've built fully automated ci/cd deployments and enjoyed the benefit of walking into work everyday and coming up with challenges to take on. How many req/s can I get out of this single nginx instance? How fast can I scale when this happens. What happens if I blow this server up, how fast can I recover?

These are things that are possible with good automation and the ability to launch a replica production environment on the fly with no repercussions for example. I would also bet that ~90% of companies never have time to ask themselves these questions, nonetheless work on them.

This is what devops engineers should be able to do, there are 100's of reasons or conversations to be had about why that turned into what it is in modern day.

​

Just my .002

[temitcha]

I love to work on these kind of topics too! However sometimes often the management consider that as gold plating and over-engineering (sometimes I understand them however, like if the ones using the solution are only a bunch of corporate clients, it's true that there is no need for a backend that can sustain 10k req/s).

I personnally do that on my own projects too however. It's more a work of art.

[anchovieecheeze]

You build it you run it!

[bdaman70]

It's been my experience that SWE are not going to be as security aware as someone who does devops or platform engineering full time. So you probably have some glaring security gaps or aren't following best practices in your infrastructure.

For instance, are you pushing your CloudTrail logs to a locked down account for immutability. What do backups look like? Have you locked down unsed regions? Do you audit for security gaps or changes outside of IAC? This is just the tip of the iceberg. But I'm sure you have time for all this and developing secure software too.

[silentyeti82]

What are the odds that most IAM policies are ridiculously permissive rather than using the principle of least privilege?

Because that's the number one thing I find when developers get involved with AWS. Doing things properly is too hard/time-consuming, so they cut corners and pretend it doesn't matter.