4 ms·

Help me understand how this could possibly result in a healthier SDLC. Great, it is possible to run the same container on all these services (and probably more

by mlhpdx 2y ago

Help me understand how this could possibly result in a healthier SDLC. Great, it is possible to run the same container on all these services (and probably more given the usual quip about the 50 ways to run a container on AWS). And, I can see that being a tempting intellectual idea and even a practical “cheat” allowing understaffed orgs to keep running the same old code in new ways. But why? The less it changes the the more vulnerable it is, the less compliant it is, the more expensive it is to operate (including insurance), the less it improves and add features, the less people like it. Seems like a well-worn path to under performance as an organization.

abadpoli 2y ago
> The less it changes the the more vulnerable it is, the less compliant it is, the more expensive it is to operate (including insurance), the less it improves and add features, the less people like it. I don’t follow this. Complexity is what leads to vulnerabilities. Reducing complexity by reusing the same, known code is better for security and for compliance. As a security person, if a team came to me and said they were reusing the same container in both contexts rather than creating a new code base, I would say “hell yeah, less work for all of us”. There are other reasons why using the same container in both contexts might not be great (see other comments in this thread), but security and compliance aren’t at the top of my list at all (at least not for the reasons you listed).
- mlhpdx 2y ago
  If the container has any dependencies, and they change, a lack of change quickly becomes an escalating liability. I’ve heard the “fixed is reliable” arguments for decades and have never seen anything that would justify the widespread failure to keep systems patched.
  - mlyle 2y ago
    He is not suggesting leaving the container unpatched, so this is unrelated criticism.
  - abadpoli 2y ago
    As the other commenter said, nobody is saying to make your application completely immutable. You still patch it, add features, etc. But now you only have to patch one container image rather than two (or more).
nijave 2y ago
Abstracting the runtime environment is nice for mixed environments and supporting local development. Maybe some deployments have really low load and Lambda is dirt cheap whereas other instances have sustained load and it's cheaper to be able to swap infrastructure backend. It doesn't have to be about life support for neglected code.
chuckadams 2y ago
> The less it changes the the more vulnerable it is, the less compliant it is, the more expensive it is to operate (including insurance), the less it improves and add features, the less people like it. All of that is true, but all of that cost is being paid regardless while the legacy system goes unmaintained. When the company decides to shut down a data center, the choice with legacy systems (especially niche ones) is often "lift and shift over to cloud" or "shut it down". Notably missing among the choices is "increase the maintenance budget". All these hypotheticals aside, one actual bonus of shifting onto lambda is reduced attack surface. However crusty your app might be, you can't end up with a bitcoin miner on your server if there's not a permanent server to hack.

by mlhpdx 2y ago

abadpoli 2y ago

> The less it changes the the more vulnerable it is, the less compliant it is, the more expensive it is to operate (including insurance), the less it improves and add features, the less people like it. I don’t follow this. Complexity is what leads to vulnerabilities. Reducing complexity by reusing the same, known code is better for security and for compliance. As a security person, if a team came to me and said they were reusing the same container in both contexts rather than creating a new code base, I would say “hell yeah, less work for all of us”. There are other reasons why using the same container in both contexts might not be great (see other comments in this thread), but security and compliance aren’t at the top of my list at all (at least not for the reasons you listed).

mlhpdx 2y ago
If the container has any dependencies, and they change, a lack of change quickly becomes an escalating liability. I’ve heard the “fixed is reliable” arguments for decades and have never seen anything that would justify the widespread failure to keep systems patched.
- mlyle 2y ago
  He is not suggesting leaving the container unpatched, so this is unrelated criticism.
- abadpoli 2y ago
  As the other commenter said, nobody is saying to make your application completely immutable. You still patch it, add features, etc. But now you only have to patch one container image rather than two (or more).

nijave 2y ago

Abstracting the runtime environment is nice for mixed environments and supporting local development. Maybe some deployments have really low load and Lambda is dirt cheap whereas other instances have sustained load and it's cheaper to be able to swap infrastructure backend. It doesn't have to be about life support for neglected code.

chuckadams 2y ago

> The less it changes the the more vulnerable it is, the less compliant it is, the more expensive it is to operate (including insurance), the less it improves and add features, the less people like it. All of that is true, but all of that cost is being paid regardless while the legacy system goes unmaintained. When the company decides to shut down a data center, the choice with legacy systems (especially niche ones) is often "lift and shift over to cloud" or "shut it down". Notably missing among the choices is "increase the maintenance budget". All these hypotheticals aside, one actual bonus of shifting onto lambda is reduced attack surface. However crusty your app might be, you can't end up with a bitcoin miner on your server if there's not a permanent server to hack.