It usually doesn't work that way, in my experience. My title is "Senior DevOps Engineer" and I do my fair share of writing code as well as maintaining infra. But honestly, hiring for people who do what I do seems to be very hit and miss. Most people excel at one or the other, and so they only pick up tickets that fit their skillset. They might dive into a ticket outside their comfort zone here or there, but not commonly. It would seem to me that many DevOps engineering teams are just one team who has a manager that hired and manages some Devs and some Ops folk, and just wrangles each of them into doing tasks that fit the goal of the team and their individual talents. And from an outsider's perspective it would seem like one team of jacks of all trades, but internally it's very much known who is going to take on certain kinds of tasks and the siloes are all very much in place.
That situation sounds reasonable though. I don’t believe in tearing down all silos. Expertise and preferences exist, it’s human nature. I always thought the DevOps mantra of having one person be good at both was a fruitless endeavour. Have Dev and Ops collaborate closely, yes, but let them be separate people (not teams!). It’s fine.
You know how to dev and ops, and I don’t doubt it. I do too. But if we focused that same energy and expertise, we’d be double the devs/ops. Nevertheless, people like us are excellent glue for organisations. At the same time, teams and organisations of only us would be quite pointless.
I feel similarly about fullstack. You’re a front end dev that has written a controller and used an ORM before. Often not too inspiring. Backend devs are still needed, whereas full stack devs form excellent glue.
You’re right. And it wasn’t my intent to editorialize (to imply I feel one way or the other about the subject.) But I can read how an opinion could be inferred. Anyway, my actual opinion is that people like us tend to be more useful than not, but also it definitely takes people with more specialized knowledge to make progress with some organization goals. For example, at my current role we have a team of people with a much deeper background in mathematics (we’re in the financial sector), algorithms, and computer science in general. Due to a life event, I dropped out of my computer science degree towards the end of my second year, and ended up pulling myself through operations roles (which I typically found comparatively boring) until I landed in DevOps after a lot of open source work and networking. But I am not as strong as some of my peers in mathematics, algorithms, and computer science topics (what is a big/little endian lol?)
That’s what DevOps is… or, was. I remember when it was new; that was the whole thing: dev and ops should work together. A break from the norm of the time that dev throws it over the wall to ops and never thinks about it again. What a tragedy that it’s been cargo-culted into its current meaning of “devs do ops” (poorly).
I came in to my current gig as the first devops hire. We were a lot smaller then. 8 years on, I'm managing an infrastructure team alongside ops and devops teams. We also draw lines a little differently; infrastructure manages core services like auth, logging, instrumentation, etc.
In my experience, devops folks usually come from the dev side, not the ops side, and their experience and curiosity reflects that. So we let them focus on shipping line-of-business code while making sure what they ship runs in a competently managed environment, as well as handling data centers and all the more traditional infra stuff.
my experience hasnt always been this, but generally speaking, this is the way to be successful - you need developer-oriented people doing the work. in some ways its harder than coding, coding has more structure than devops automation
> Most companies that seriously deploy k8s tend to have dedicated teams for it.
Ya, and everywhere I've worked, that team is called "devops". The application developers are a different team. Maybe that's not the norm, but I thought it was.
There are app developers like that. There is a class of problems where you need to be able to do both application development and system work to be able to do well.
What a lot of people miss about larger k8s deployment is that you can create an internal platform team, like a micro-heroku within the company. The company would have to hire people who can create _products_ and also knowing how to work with infra in order to create a platform. It would be this rare combination of product, dev, ops, and focusing on supporting the rest of the engineering team and giving up on the glory of launching something for end users.
This is one of those cycles that IT does regularly every other decade.
In the early days, computers were huge things that were maintained by a team of specialists (and who actually soldered things together). Getting anything changed involved a series of paper forms and waiting for a specialist to do it for you.
Then came the microcomputer revolution and computers became small things that sat on desks and were maintained by the office geek. Changing anything meant talking to him (it was always him) and it would be done by lunchtime, and you owed him a coffee.
Then companies learned that this meant that no two offices had the same configuration, application suite, or even operating system. IT was centralised, and every office issued with the same stuff. Getting anything changed meant filling in forms and waiting for System Administrators to get around to it.
Then Agile and the Cloud happened and while the rest of the company had to carry on filling in forms, the IT Department turned into Engineering and DevOps was born. Every developer learned how to deploy their stuff to the cloud by themselves.
Then organisations worked out that that meant that applications were deployed badly, using a wide variety of tools and technologies, and essential security practices got skipped because no-one was responsible for them. So DevOps was turned back into SysAdmin and the forms reinvented as JIRA tickets.
And so we go on. There are micro-cycles within these ones, like the one about terminals (are you typing on the actual computer, or on a terminal that talks to the actual computer which is somewhere else? The answer depends on which decade you're in).
The ideal solution is somewhere in between (enough central control for it not to get into a mess, but enough decentralisation to prevent bureaucracy and allow for agility in the actual business). But that is a very hard balance to find and keep.
I started back in 2016 building k8s clusters from scratch via terraform and bash scripting. It was ugly awful but worked thru Covid with zero downtime when we switched to hosted solutions from AWS and Google cloud.
DevOps still must draw the line somewhere. DevOps people typically don't physically plug cables into switches, for instance. With the ever-growing complexity of infra, I see that line having to shift more and more, with either PaaS products or platform engineering teams filling the space by providing something like Kubernetes as a service to the DevOps folks.