5 ms·

> In the meantime, your PHP app had 40 major security flaws, no meaningful monitoring, How does Kubernetes, microservices and front end frameworks fix that? T

> In the meantime, your PHP app had 40 major security flaws, no meaningful monitoring, How does Kubernetes, microservices and front end frameworks fix that? They don't. In fact, as someone who works at the more modern end of these things, I'd suspect that "no meaningful monitoring" probably correlates quite well with cloud era microservices thingies. But we can't blame the tools, that space is just younger and by nature contains more immature stuff. I don't think the argument here is for keeping things out of version control and monitoring. It's that you can actually leave stuff alone for several years, come back and find it working just as before, when the layers underneath doesn't constantly change. That can be liberating.

CoastalCoder 3y ago
> But we can't blame the tools, that space is just younger and by nature contains more immature stuff. I think the article's point was that the industry is perpetually young and immature because it keeps (unnecessarily) chasing fads.
Quarrelsome 3y ago
> How does Kubernetes, microservices and front end frameworks fix that? Doesn't being in a container mean its much easier to rebuild it from zero and thus allowing security updates to be more regular?
- otabdeveloper4 3y ago
  Not really. A "container" is usually just an instance of a Linux distribution, and the work involved in updating it is roughly the same.
  - edejong 3y ago
    In the 27 minutes after you wrote your comment, our CI/CD rebuild two containers from a latest snapshot. No manual work involved.
    - otabdeveloper4 3y ago
      Good for you, some people can do automatic unattended OS updates too. There's no benefit to using containers here, only more pain.
      - collinmanderson 3y ago
        One benefit of containers is easy rollback.
- shocks 3y ago
  IME, this is rarely true; hence “2hrs fixing docker build”. It’s really difficult to pin everything. Even if you manage that, upstream resources change/move.
steveBK123 3y ago
As a "not a cloud guy" who only recently got heavily exposed to it.. I found the state of the art / CloudOps attitudes towards monitoring astonishingly Stone Age. Yeah observability is great, but no one I've seen in cloud manages to launch with it. So in place of SRE org with full observability stack, they launch with effectively nothing. Strong attitudes of "we don't measure hardware metrics like cpu/memory/disk, we measure customer facing stuff like throughput/error rates etc". Sounds good, but what do you think happens to those if you run out of disk bro? Pretty sure the running out of disk happens first. Imagine if you could like.. catch it?
- steveBK123 3y ago
  And I would add - All the GOOD cloud people I know are GOOD linux people. It is a prerequisite. However theres lots of cloud people who don't know linux. Therein lies the challenge. Too many of these cloud devs forget that whether its "server less" or not, theres a .. server, somewhere. All the layers of abstraction work when they work, and when they don't .. best of luck figuring out what's going on in a timely fashion. Hope you aren't running any money on top of it.
- edejong 3y ago
  CPU/Memory: scale horizontally when needed. Monitor cost. Disk: essentially limitless. If disk of VM runs out, node will crash, new node will start. Service should keep running on other nodes meanwhile. If restarts happen too often, throughput/error rate will suffer or cost will rise. Modern mentality is "let it crash" [0]. Software has bugs. Design so it can crash and scale depending on need. [0] https://medium.com/@vamsimokari/erlang-let-it-crash-philosophy-53486d2a6da https://medium.com/@vamsimokari/erlang-let-it-crash-philosop...
  - steveBK123 3y ago
    This is an adequate philosophy for like.. a CRUD app, some freemium SaaS, social media, etc. Stuff with millions of users and billions of sessions, etc. However there are industries applying these lessons in HPC / data analytics / things that touch money live .. operating on scales of users in the 10s to maybe 100s. So stuff where downtime is far more costly both in dollars and reputation. I'm also intrigued by the constant cloud refrain of "stuff crashes all the time so just expect it to" coming from a background where I have apps that run without crash for 6 months at a time, or essentially until the next release. I'm all for scaling, recovery, etc.. I just fail to understand why it is desirable for this to be an OR rather than an AND. What if stuff was highly recoverable and scalable but also.. we just didn't run out of disk needlessly?
edejong 3y ago
* k8s helps because you keep your application online during rolling updates. You keep your changes relatively small and can test your changes in isolation. * microservices help security because for each service you write, you create a minimal surface area (as opposed to monolithic applications where each method has access to maximum dependencies). * microservices also help monitoring, because failures can be contained and one application does (should) not impact another. This means that your focus of monitoring is on application performance, and less on the underlying system architecture. * monitoring can be a cross-cutting concern. For example, you can monitor all HTTP requests by instrumenting your ingress layer. Similarly, you can support a unified authorisation scheme by bringing this to the ingress layer. Even more, using microservices, you can independently promote services to production (sort of like feature toggles) or do green/blue promotion. * security of your microservices is improved, because you can independently upgrade your dependencies per service. Many older monoliths are 'stuck' in a certain dependency configuration and cannot be upgraded without a 'big bang' of expensive dependency resolution and testing. I could give many more examples, but I hope this captures the spirit a little.

CoastalCoder 3y ago

> But we can't blame the tools, that space is just younger and by nature contains more immature stuff. I think the article's point was that the industry is perpetually young and immature because it keeps (unnecessarily) chasing fads.

Quarrelsome 3y ago

> How does Kubernetes, microservices and front end frameworks fix that? Doesn't being in a container mean its much easier to rebuild it from zero and thus allowing security updates to be more regular?

otabdeveloper4 3y ago
Not really. A "container" is usually just an instance of a Linux distribution, and the work involved in updating it is roughly the same.
- edejong 3y ago
  In the 27 minutes after you wrote your comment, our CI/CD rebuild two containers from a latest snapshot. No manual work involved.
  - otabdeveloper4 3y ago
    Good for you, some people can do automatic unattended OS updates too. There's no benefit to using containers here, only more pain.
    - collinmanderson 3y ago
      One benefit of containers is easy rollback.
shocks 3y ago
IME, this is rarely true; hence “2hrs fixing docker build”. It’s really difficult to pin everything. Even if you manage that, upstream resources change/move.

steveBK123 3y ago

As a "not a cloud guy" who only recently got heavily exposed to it.. I found the state of the art / CloudOps attitudes towards monitoring astonishingly Stone Age. Yeah observability is great, but no one I've seen in cloud manages to launch with it. So in place of SRE org with full observability stack, they launch with effectively nothing. Strong attitudes of "we don't measure hardware metrics like cpu/memory/disk, we measure customer facing stuff like throughput/error rates etc". Sounds good, but what do you think happens to those if you run out of disk bro? Pretty sure the running out of disk happens first. Imagine if you could like.. catch it?

steveBK123 3y ago
And I would add - All the GOOD cloud people I know are GOOD linux people. It is a prerequisite. However theres lots of cloud people who don't know linux. Therein lies the challenge. Too many of these cloud devs forget that whether its "server less" or not, theres a .. server, somewhere. All the layers of abstraction work when they work, and when they don't .. best of luck figuring out what's going on in a timely fashion. Hope you aren't running any money on top of it.
edejong 3y ago
CPU/Memory: scale horizontally when needed. Monitor cost. Disk: essentially limitless. If disk of VM runs out, node will crash, new node will start. Service should keep running on other nodes meanwhile. If restarts happen too often, throughput/error rate will suffer or cost will rise. Modern mentality is "let it crash" [0]. Software has bugs. Design so it can crash and scale depending on need. [0] https://medium.com/@vamsimokari/erlang-let-it-crash-philosophy-53486d2a6da https://medium.com/@vamsimokari/erlang-let-it-crash-philosop...
- steveBK123 3y ago
  This is an adequate philosophy for like.. a CRUD app, some freemium SaaS, social media, etc. Stuff with millions of users and billions of sessions, etc. However there are industries applying these lessons in HPC / data analytics / things that touch money live .. operating on scales of users in the 10s to maybe 100s. So stuff where downtime is far more costly both in dollars and reputation. I'm also intrigued by the constant cloud refrain of "stuff crashes all the time so just expect it to" coming from a background where I have apps that run without crash for 6 months at a time, or essentially until the next release. I'm all for scaling, recovery, etc.. I just fail to understand why it is desirable for this to be an OR rather than an AND. What if stuff was highly recoverable and scalable but also.. we just didn't run out of disk needlessly?

edejong 3y ago

* k8s helps because you keep your application online during rolling updates. You keep your changes relatively small and can test your changes in isolation. * microservices help security because for each service you write, you create a minimal surface area (as opposed to monolithic applications where each method has access to maximum dependencies). * microservices also help monitoring, because failures can be contained and one application does (should) not impact another. This means that your focus of monitoring is on application performance, and less on the underlying system architecture. * monitoring can be a cross-cutting concern. For example, you can monitor all HTTP requests by instrumenting your ingress layer. Similarly, you can support a unified authorisation scheme by bringing this to the ingress layer. Even more, using microservices, you can independently promote services to production (sort of like feature toggles) or do green/blue promotion. * security of your microservices is improved, because you can independently upgrade your dependencies per service. Many older monoliths are 'stuck' in a certain dependency configuration and cannot be upgraded without a 'big bang' of expensive dependency resolution and testing. I could give many more examples, but I hope this captures the spirit a little.