5 ms·

Those who are concerned with their application code are often not all that concerned with the platform it's running in. They just want to run their code. Conta

by mfer 6y ago

Those who are concerned with their application code are often not all that concerned with the platform it's running in. They just want to run their code. Containers mixes the concerns. We now ask those concerned with application code to be concerned with the platform they're running in. To do this takes away time and energy invested in their application. So, it's no surprise they don't put much time in to it. The days of letting people who are concerned with the platform be concerned with this are gone in this season. We now overload the app dev with more stuff to be concerned with.

jonhohle 6y ago
I disagree, somewhat. Even at the highest application level developers should be concerned about their runtime dependencies. The bigger issues, imho, is that (docker at least) doesn’t make it easy to separate build vs runtime dependencies in any systematic way, and makes it very difficult to build minimal runtime images while providing access to developer tools during development. Bazel and Spring both have ways to address this, but they require knowledge of + _n_ tools on top of the native build too chain.
- mfer 6y ago
  If I hear what you're saying right... you're saying that someone working in node.js should be concerned with the vulnerabilities in system libraries of the OS that node.js runs in. Bringing up Bazel to deal with system dependencies is going down the road of DevOps rather than Dev. Docker is pitched as Dev. A lot of them don't care about the lower level ops. There is something to be said for separation of concerns and targeting each concern well. Our current problems are because we're doing a poor job mixing concerns or even understanding the separation.
  - jonhohle 6y ago
    No, I’m saying for a node.js developer all of their dependencies affect how their applications work. If they can get away with a statically linked node binary and no other libraries, great!
incrudible 6y ago
Developers should always be concerned with the platform they are running on. Yes, this takes time and energy, but so does anything worthwhile.
- mfer 6y ago
  In the past you had developers who worked on their app code and ops people who are concerned with where it runs. Now, we're moving a bunch of that ops work over to be work of the app dev. That means more context switching and knowledge outside the area of most concern. All while companies what increased velocity. Why should developers always be concerned with the platform details? If the developers should be concerned with the platform should ops also now need to be intimately concerned with the details of the apps? How much less time could they do on ops if they have to know all about the apps?
  - incrudible 6y ago
    The timeframe in which there was such a thing as an "Ops engineer" is so brief it could be considered a fad, owing to the complexity of the solutions to deploy software that arose then. > Why should developers always be concerned with the platform details? Every platform has constraints. Do you have effectively unlimited memory, unlimited storage, unlimited bandwidth, zero latency and infinitely scalable CPU available for the process(es) you are responsible for? Can you be sure that given system call is available and behaves exactly the same everywhere? Of course not. If you were to act as if these things were true at all times, you would create something with sub-par performance and reliability, eventually driving up the cost of deployments to impossible levels.
    - mfer 6y ago
      > The timeframe in which there was such a thing as an "Ops engineer" is so brief it could be considered a fad I've been working in software since I was a kid. I remember working for an ISP in the dialup days. I saw the separation of roles between those concerned with the platform and those concerned with the running applications even back then. To call it a brief fad, I think, misses a lot of what's happened in the market and the different roles with their different concerns. > Every platform has constraints. We live in a world where you have a platform built on a platform. To a node.js or PHP developer you'll have people thinking of those as the platforms. They aren't thinking about Ubuntu, CentOS, Windows, or the other lower level systems. This is why a JS dev will code something up on a Mac and then run it on Linux in production. node.js is the platform for them. But, with containers we're also asking them to make the Linux distro with all the things related to that as part of their platform. Not to just make it work but keep up on security. This is the wrong level in the stack for them. If they put a bunch of time into being concerned with that it will slow their velocity on the node.js work and be a big context switch (along with different knowledge in this context). It looks like I see a bunch of Ops/DevOps people saying that app devs should be concerned with their stuff in addition or in displacement to their own. That's not happening well for a reason.

by mfer 6y ago

jonhohle 6y ago

I disagree, somewhat. Even at the highest application level developers should be concerned about their runtime dependencies. The bigger issues, imho, is that (docker at least) doesn’t make it easy to separate build vs runtime dependencies in any systematic way, and makes it very difficult to build minimal runtime images while providing access to developer tools during development. Bazel and Spring both have ways to address this, but they require knowledge of + _n_ tools on top of the native build too chain.

mfer 6y ago
If I hear what you're saying right... you're saying that someone working in node.js should be concerned with the vulnerabilities in system libraries of the OS that node.js runs in. Bringing up Bazel to deal with system dependencies is going down the road of DevOps rather than Dev. Docker is pitched as Dev. A lot of them don't care about the lower level ops. There is something to be said for separation of concerns and targeting each concern well. Our current problems are because we're doing a poor job mixing concerns or even understanding the separation.
- jonhohle 6y ago
  No, I’m saying for a node.js developer all of their dependencies affect how their applications work. If they can get away with a statically linked node binary and no other libraries, great!

incrudible 6y ago

Developers should always be concerned with the platform they are running on. Yes, this takes time and energy, but so does anything worthwhile.

mfer 6y ago
In the past you had developers who worked on their app code and ops people who are concerned with where it runs. Now, we're moving a bunch of that ops work over to be work of the app dev. That means more context switching and knowledge outside the area of most concern. All while companies what increased velocity. Why should developers always be concerned with the platform details? If the developers should be concerned with the platform should ops also now need to be intimately concerned with the details of the apps? How much less time could they do on ops if they have to know all about the apps?
- incrudible 6y ago
  The timeframe in which there was such a thing as an "Ops engineer" is so brief it could be considered a fad, owing to the complexity of the solutions to deploy software that arose then. > Why should developers always be concerned with the platform details? Every platform has constraints. Do you have effectively unlimited memory, unlimited storage, unlimited bandwidth, zero latency and infinitely scalable CPU available for the process(es) you are responsible for? Can you be sure that given system call is available and behaves exactly the same everywhere? Of course not. If you were to act as if these things were true at all times, you would create something with sub-par performance and reliability, eventually driving up the cost of deployments to impossible levels.
  - mfer 6y ago
    > The timeframe in which there was such a thing as an "Ops engineer" is so brief it could be considered a fad I've been working in software since I was a kid. I remember working for an ISP in the dialup days. I saw the separation of roles between those concerned with the platform and those concerned with the running applications even back then. To call it a brief fad, I think, misses a lot of what's happened in the market and the different roles with their different concerns. > Every platform has constraints. We live in a world where you have a platform built on a platform. To a node.js or PHP developer you'll have people thinking of those as the platforms. They aren't thinking about Ubuntu, CentOS, Windows, or the other lower level systems. This is why a JS dev will code something up on a Mac and then run it on Linux in production. node.js is the platform for them. But, with containers we're also asking them to make the Linux distro with all the things related to that as part of their platform. Not to just make it work but keep up on security. This is the wrong level in the stack for them. If they put a bunch of time into being concerned with that it will slow their velocity on the node.js work and be a big context switch (along with different knowledge in this context). It looks like I see a bunch of Ops/DevOps people saying that app devs should be concerned with their stuff in addition or in displacement to their own. That's not happening well for a reason.