I wholeheartedly agree on most parts, with DevOps being the exception.
Devs only focusing on developing/writing source code is certainly not the way to produce sustainable, high quality software- at least in my opinion...
Devs only focusing on developing/writing source code is certainly not the way to produce sustainable, high quality software- at least in my opinion...
I think high quality comes from specialists. Sharp knives in the hands of pro's
I suspect you don't mean it like that, but developers have to care just a little about operations. There's the classic stuff about developers who build stuff, because they didn't realize that ops could do the same with a few lines in a web server config, so they waste weeks on trivial stuff. There's also the issue that if you expect databases, queues, disks and so on to just be available, while not thinking about how you use them, then you can get bad performance or cause downtime and crashes in the worst case.
The initial idea of DevOps also seems to have been twisted to having developers do operations, rather than having the two teams work in tandem. If we absolutely must combine the two roles, I'd be more comfortable having operations do development work, but that hardly ideal either.
Yes, I'm cynical. Having to use javalike stuff to do what should be a simple shell script will do that to you.
In a huge organisation, it can work well to be very specialized.
In, for example, a smaller growing business with an engineering team of < 10, having a proper understanding of the context in which your code will run is a game-changer.
Like TDD the design of software changes when you have experience with ops/maintenance. Take logging/tracing: what to log or trace is first and foremost a matter of experience with maintenance/ops! Building in logging/tracing/monitoring from the get-go because you know that you want to know what goes wrong, when it goes wrong etc...
can one regard oneself as expert if you know only a part of the domain- I think not!
Maybe "before my time" it was a webmaster or other admin. I think of "dev ops" as an umbrella term subsuming many specific titles and roles from the past, much like "data science".
Still I think having extra admins for server maintenance, or nowadays DevOps, also makes sense in my opinion. In theory I should be interested, but in practice, somehow I can not really get passionate about the details of how to host things. So it would be better to have specialists who really care.
Ultimately there are also a lot of aspects that are different from the programming problems. It's difficult to keep up to date on both fronts.
Maintenance and the automation of repetitive tasks are in my view part of DevOps, but not every dev in a team has to participate at the same degree...
But I'm a developer by heart and my heart aches whenever I see what we devs have wrought in the ops space. (Insert joke about the CNCF technology landscape map.)
There's just so many tech/tools/etc. involved that just reasonably "doing the ops stuff" on the side seems way unrealistic. Sometimes I feel that all we've accomplished was job security for legions of consultants.
> But I'm a developer by heart and my heart aches whenever I see what we devs have wrought in the ops space.
At the same time, I am conflicted. I don't care for the toss-it-over-the-wall approach that used to be the norm, but I also don't like having dev's have to take more on than they are capable.
In an ideal environment, I would like to see a crashing together of developers and operations people on teams. What I mean is that for a given team you have several developers and one or two ops folks. This way there is less of an us vs them sentiment and teams can be held accountable for their solutions from ideation to running in production. Finally while it's not the sole responsibility of the dev's to manage their DevOps stuff, they will have more knowledge of how it works, and get to put input and ideas to it.