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.
150 karma · joined March 2, 2022
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.
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.
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.
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.
More than half those companies ran istio in production at large scales.
* automatic service account for each workload
* automatic service to service auth to 3rd party services
* the audit log
* role based access control
* well defined api
* the explain subcommand
* liveness and readiness probes
* custom resources
The list goes on, but the big ones for a small team just getting started are workload identity and security.The ideal trade off is a single Kubernetes cluster with as much in the cluster as makes sense for the team and stage of the project. As you say, toss the app on a single node to start, but the control plane is tremendously valuable from on the onset of most projects.
The project I’m currently building is an enterprise b2b SaaS and I’ve gotten it fully functional without writing a single line of JavaScript. By functional I mean it looks and behaves like there is JavaScript, because there is with HTMX, but it’s abstracted away to the point of taking none of my time, which is what matters.
There’s no way I could learn the JavaScript ecosystem in a day. Maybe I could get something functional in a day but the technical debt would be too costly. I’m not sure any human could learn it in a day with acceptable technical debt trade offs.
For my situation of an enterprise app that’s mostly declaring resources in the backend via API, it’s been much faster to write in my preferred backend language only. I build the API, make a command line tool in the same language that calls the API, then add a basic HTML form for the demo and it’s great.
The host key is the only thing ensuring you’re actually talking to GitHub.com when you push code.
To add to sibling comments, it should not have been possible to make this mistake. That it was possible is concerning.
I’m comfortable doing exactly as GP described to make payroll.
This has held consistently true for as long as Ubuntu has existed.
In recent years this is also true on the desktop.