5 ms·

Maybe I'm too old, but I don't even want to have to worry about all that. I think in terms of functions and I don't care if they are being called remotely or lo

Maybe I'm too old, but I don't even want to have to worry about all that. I think in terms of functions and I don't care if they are being called remotely or local. That was the promise back in the day of J2EE, and it seems to me Microservices are just a rehash of that same promise. Which never really worked out with J2EE - it was mostly invented to sell big servers and expensive consultants, which is how Sun made money? These days I sometimes don't even bother to make extra interface classes for everything. If I need it, I can still insert that, but no need to do it up front. And "DevOps" is just a ploy to make developers do more work, that was formerly done by admins. Writing every Microservice in a new language also seems like a huge headache. The only bonus is that you can attract developers by being able to promise them that they can work with some shiny new technology. Maybe that is actually the main reason for doing that? Otherwise, again, perhaps it is my age, but I prefer to minimize the dependencies. Do I really want to have to learn a whole new programming language just so that I can fix a bug in some Microservice. I personally don't want to.

verinus 5y ago
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...
- kkjjkgjjgg 5y ago
  It was a bit cheeky and off-hand. I am certainly interested in DevOps. If things can be automated, it is usually a good thing. 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.
  - verinus 5y ago
    Ok no argument from me there :) 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...
- baash05 5y ago
  I am 100% not interested in ops. Deploying is handled by other way more qualified than I. I never expect a JS expert to build elixir, I don't expect an elixir expert to write bash, and I don't expect a bash expert to know about switches and cabling. I don't understand where you draw the line.. Should the designer who also crafts the css do ops too? I think high quality comes from specialists. Sharp knives in the hands of pro's
  - 3np 5y ago
    Just like the preceding question, it depends on context. 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.
  - verinus 5y ago
    The goal is to sustainably build software, which only can be done if ops and maintenance is regarded a goal, a pillar to build upon. 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!
    - deleted 5y ago
      [deleted]
  - deleted 5y ago
    [deleted]
  - nerdponx 5y ago
    And this person is a DevOps person, in every org I've ever worked in. 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".
  - 5y ago
- varjag 5y ago
  If we were interested in ops we would be sysadmins.
- svckr 5y ago
  I don't know. I totally agree on the premise that developers should be involved in ops as well. 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.
  - DerArzt 5y ago
    I am sort of with you on the whole: > 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.
    - geekbird 5y ago
      This was the original intent of DevOps - a cultural shift that put sysadmins/ops people into the dev team, thus have a better feedback loop between dev and prod, and tear down the wall between dev and ops. But now it's being used as a way to eliminate ops people and push it all into dev.
solididiot 5y ago
DevOps is a sad story both for devs and for ops. It was supposed to treat operations as a SW problem thus take away the toll and draw devs in. In reality for most places it either means that devs also do pipelines and operations or that operations were rebranded and are using "DevOps" tooling to do operations.
- goodoldneon 5y ago
  To me, DevOps means SDEs can troubleshoot, diagnose, and fix app-related prod issues. SREs don’t have the app-level knowledge for that, so it’s wasteful for them to be involved. SREs should be paving paths for SDEs and responding to infrastructure ops issues. I also think silos are unhealthy. SDEs need to have some overlapping responsibilities with SREs. Otherwise, you’ll likely have a “throw it over the fence” culture
- Tarucho 5y ago
  I guess the idea is fine but the implementation tends to be about using 1 employee in multiple roles and working 60-hour work weeks while paying just one salary. You got DevOps, DevTest, then DevSecOps, etc. It´s insane, the next step is probably being a DevTestSecOps sleeping under the company desk.
alasdair_ 5y ago
> "DevOps" is just a ploy to make developers do more work, that was formerly done by admins. Developers cost a lot more than admins, so this seems silly. Moreover “devops” people are supposed to be developers, just ones with a whole bunch of networking and admin skills as well. But few places outside Google have real SREs.

verinus 5y ago

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...

kkjjkgjjgg 5y ago
It was a bit cheeky and off-hand. I am certainly interested in DevOps. If things can be automated, it is usually a good thing. 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.
- verinus 5y ago
  Ok no argument from me there :) 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...
baash05 5y ago
I am 100% not interested in ops. Deploying is handled by other way more qualified than I. I never expect a JS expert to build elixir, I don't expect an elixir expert to write bash, and I don't expect a bash expert to know about switches and cabling. I don't understand where you draw the line.. Should the designer who also crafts the css do ops too? I think high quality comes from specialists. Sharp knives in the hands of pro's
- 3np 5y ago
  Just like the preceding question, it depends on context. 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.
- verinus 5y ago
  The goal is to sustainably build software, which only can be done if ops and maintenance is regarded a goal, a pillar to build upon. 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!
  - deleted 5y ago
    [deleted]
- deleted 5y ago
  [deleted]
- nerdponx 5y ago
  And this person is a DevOps person, in every org I've ever worked in. 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".
- 5y ago
varjag 5y ago
If we were interested in ops we would be sysadmins.
svckr 5y ago
I don't know. I totally agree on the premise that developers should be involved in ops as well. 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.
- DerArzt 5y ago
  I am sort of with you on the whole: > 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.
  - geekbird 5y ago
    This was the original intent of DevOps - a cultural shift that put sysadmins/ops people into the dev team, thus have a better feedback loop between dev and prod, and tear down the wall between dev and ops. But now it's being used as a way to eliminate ops people and push it all into dev.

solididiot 5y ago

DevOps is a sad story both for devs and for ops. It was supposed to treat operations as a SW problem thus take away the toll and draw devs in. In reality for most places it either means that devs also do pipelines and operations or that operations were rebranded and are using "DevOps" tooling to do operations.

goodoldneon 5y ago
To me, DevOps means SDEs can troubleshoot, diagnose, and fix app-related prod issues. SREs don’t have the app-level knowledge for that, so it’s wasteful for them to be involved. SREs should be paving paths for SDEs and responding to infrastructure ops issues. I also think silos are unhealthy. SDEs need to have some overlapping responsibilities with SREs. Otherwise, you’ll likely have a “throw it over the fence” culture
Tarucho 5y ago
I guess the idea is fine but the implementation tends to be about using 1 employee in multiple roles and working 60-hour work weeks while paying just one salary. You got DevOps, DevTest, then DevSecOps, etc. It´s insane, the next step is probably being a DevTestSecOps sleeping under the company desk.

alasdair_ 5y ago

> "DevOps" is just a ploy to make developers do more work, that was formerly done by admins. Developers cost a lot more than admins, so this seems silly. Moreover “devops” people are supposed to be developers, just ones with a whole bunch of networking and admin skills as well. But few places outside Google have real SREs.