Even so, the suggestion is a good one. Modern proxies have gotten much better at handling auth and processing the traffic as the GP describes. Service meshes have these features built in now when a few years ago we had to roll our own solutions with haproxy or nginx.
A bank is a bad example. The only thing we use bank websites for is to check our transactions and transfer money.
My business checking account has started offering partner promotions from the transfer screen and I’m tempted to switch to another bank because of it. Their developers and designers were tasked with delivering that component. At the same time they took away their mobile app and mobile check deposit because it was not secured properly.
Most bank websites and apps are examples of teams and organizations focusing on the wrong thing in my opinion.
Splunk has delivered this level of innovation and quality since 2007 when I first used it.
We used Splunk to associate a change request ticket number all the way through the change control process to the Puppet log output tagging each change to the original business purpose.
It was like magic for auditors back then and I rarely see that depth of tracing automated changes to business purpose in the field today, though we get close with gitops.
It’s historically been abbreviated AAA “triple A” for Access, Authentication, and Authorization. Each being a separate system, VPN’s and Firewalls traditionally controlling access for example.
No, the best organizations have a happy path laid out for org chosen tools and a platform that supports adding in “non standard” tools / libraries by individuals and teams as needed, with a defined path toward those additions become the new golden path standard.
Not at L6. Scarface is right, most of the time the org just knows something is wrong and they don’t know what it is exactly or how to fix it. Sometimes they don’t even know something is very wrong, while working on a defining problem 1 the L6 also identifies related problem 2 the org thought was minor but is actually major.
None of this is specified, there are no specs to execute up front. Much of it is defining the spec yourself and collaborating with the rest of the org to find out if other people agree with the spec.
This is a good analogy. For more context in the past 5 years working with customers in the Bay Area I’ve not encountered one who mentioned linkerd let alone ran it in production.
More than half those companies ran istio in production at large scales.
The sweet spot is for someone with deep experience to lay down the skeletal structure of the tests, rpc, infra, lifecycle, etc… then hand it off to a broader team who could learn the intention behind the decisions.
Why are discussions of web development and JavaScript unique in that we can’t discuss alternative methods and trade offs without the discussion devolving into personal attacks and defensiveness?
The vetting process is the same as if I were driving up I-5 with a gear head friend of mine having a conversation with them as we go.