jsso2

ce which is pretty easy to find. (I am not sure I would steal my database setup / teardown utilities from that project. The tests end up indented too far. A more idiomatic Go way is "app := testapp.New(); defer app.Cleanup(); tests go here"; in that codebase I picked the "testapp.Test(t, func(t testing.TB) { tests go here })" pattern. Definitely something I look for and avoid these days, but didn't in 2020 ;)

that maintains username -> WebAuthn credentials, and use it for my personal projects. I wouldn't recommend that someone else use it (incomplete featureset, not security reviewed), but it's totally open source so you can steal the bits you like: https://github.com/jrockway/jsso2 The end result is that I can open up Grafana on my phone and sign in with FaceID. Or if my face falls off, I can scan my YubiKey with NFC. All given to you for free for using WebAuthn. And it costs $0/month, which is much less than the Oktas of the world charge for a more

re yourself. People generally aren't willing to do that, and so are upset when their favorite application doesn't work their favorite observability stack. (I remember being upset that my traces didn't propagate from Envoy to Grafana, because Envoy uses the Zipkin propagation protocol and Grafana uses Jaeger. However, Grafana is open source and I just added that feature. Took about 15 minutes and they released it a few days later, so... the option is available to people that demand perfection.) Auth is another issue that has been punted on. Maybe your cloud provider has something. Maybe you bought something. Maybe the app you want to run supports OIDC. To me, the dream of the container world is that applications don't have to focus on these things -- there is just persistent authentication intrinsic to the environment, and your app can collect signals and make a decision if absolutely necessary. But that's not the way it worked out -- BeyondCorp style authentication proxies lost to OIDC. So if you write an application, your team will be spending the first month wiring that in, and the second month documenting all the quirks with Okta, Auth0, Google, Github, Gitlab, Bitbucket, and whatever other OIDC upstreams exist. Big disaster. (I wrote https://github.com/jrockway/jsso2 and so this isn't a problem for me personally. I can run any service I want in my Kubernetes cluster, and authenticate to it with my FaceID on my phone, or a touch of my Yubikey on my desktop. Applications that want my identity can read the signed header with extra information and verify it against a public key. But, self-hosting auth is not a moneymaking business, so OIDC is here to stay, wasting thousands of hours of software engineering time a day.) Ingress is the worst of Kubernetes' APIs. My customers run into Ingress problems every day, because we use gRPC and keeping HTTP/2 streams intact from client to backend is not something it handles well. I have completely written it off -- it is underspecified to the point of causing harm, and I'm shocked when I hear about people using it in production. I just use Envoy and have an xDS layer to integrate with Kubernetes, and it does exactly what it should do, and no more. (I would like some DNS IaC though.) Many things associated with Kubernetes are imperfect, like Gitops. A lot of people have trouble with the stack that pushes software to production, and there should be some sort of standard here. (I use ShipIt, a Go program to edit manifests https://github.com/pachyderm/version-bump, and ArgoCD, and am very happy. But it was real engineering work to set that up, and releasing new versions of in-house code is a big problem that there should be a simple solution to.) Most of these things are not problems brought about by Kubernetes, of course. If you just have a Linux box, you still have to configure auth and observability. But also, your website goes down when the power supply in the computer dies. So I think Kubernetes is an improvement. The thing that will kill Kubernetes, though, is Helm. I'm out of time to write this comment but I promise a thorough analysis and rant in the future ;)

ps://github.com/vouch/vouch-proxy [6]: https://github.com/simov/grant

t, I use it many times every day, and have even convinced other people to use it without writing any documentation. (There are binary releases and a --help though!) "kubectl jq": I wanted to play with writing kubectl plugins, so I made one that is just "kubectl get x -o json | jq". I use it pretty regularly, but the Kubernetes client machinery doesn't give you autocompletion for free, so it's pretty painful to use. When they fix that, I plan to write more kubernetes extensions (including one that invokes jlog on the logs, saving a pipe ;) https://github.com/jrockway/kubectl-jq alertmanager-status: How do you know if your Prometheus/Alertmanager is working? If it breaks, it won't be sending you an alert, after all. https://github.com/jrockway/alertmanager-status ekglue: The good parts of Istio, for internet<->internal proxying, written by someone who read the xDS spec :P https://github.com/jrockway/ekglue For my day job, I work on Pachyderm Hub, which you should totally use if you want to run production-quality data science workloads (data provenance, reproducibility, etc.): https://hub.pachyderm.com/ I could write a lot about it, but basically... we have customers that want to use Pachyderm, but the complexity of Kubernetes stands in their way. How do you store logs? How do you monitor things? How do you give your coworkers access? We solve those problems by letting you click a button in a web UI. (As for why you'd want to use Pachyderm: https://www.pachyderm.com/use-cases/)

ke that all work yourself.) I've run into the situation at least twice where some app has bought into that mindset and made auth an external factor (don't send HTTP requests unless the user is authorized), and found that there was pretty much nothing good to provide that feature. So... I wrote my own thing both times, and am loving it. (You could use it too! But I wouldn't necessarily recommend it: https://github.com/jrockway/jsso2) I never have to think about auth again. Having also done the infrastructure and library work to get Prometheus/Grafana/Jaeger/Loki doing what I want (https://github.com/jrockway/opinionated-server), I am almost happy with the remaining cross-cutting concerns. I am ever closer to my "1 hour app", where I can just type in some code and have a fully-working production-quality app available to users. I'm not there, but I'm getting closer by the year. (Sometimes I wonder if we were wrong to totally get rid of the "just rsync some PHP files to a server" model. There were good things and bad things going on there; we should bring the good things back.)

ant to manually revisit every metric. It's a straightforward refactoring that you will probably never do more than once, so I don't think it's worth making it "easy" out of the box. Finally, we let you configure your app with either flags or environment variables. Generally, I like flags for running things while developing (go run main.go --foo=bar) and environment variables for production. Why pick one or the other when you can do both! Extensive care has been taken to be able to log everything, including all payloads for bidirectional streams. (HTTP logging is a bit of a disaster; check out the code you have to write to be able to hook every type of http.ResponseWriter without the consumer noticing: https://github.com/prometheus/client_golang/blob/master/prom....) Some features that are missing or sub-optimal: * A long chain of interceptors for every request is very expensive. They should all be condensed into one wrapper that does "everything" explicitly. I don't think it's worth the debugging complexity to be able to compose a bunch of middleware at runtime; just write a function that wraps every request that does the stuff you want. If you want more stuff, type it in right there. Easy to read, easy for the computer to execute. * There should be fine-grained control over logging at runtime. I think you really want to be able to pass in configuration for every sub-logger, rather than a global log level. For example, you may want to adjust log sampling rate at runtime for a particular component, or upgrade a particular component from INFO to DEBUG for temporary investigation. (Without these controls, people stop writing log statements because they're too spammy, and then you have absolutely nothing to help you with ongoing issues.) * There is absolutely no support for mTLS, which is a crime in this day and age. This is probably the next thing that I'll add; you should be able to watch a volume for changes in TLS key/cert/ca material (so you can rotate keys frequently and without restarting), and require that incoming requests have a certificate trusted by the loaded CA. Outgoing requests should also be marked as "external" or "internal", and use the correct client cert for internal requests. (I somewhat promise to add this soon, because it's sorely needed.) * I don't think applications should support any non-production features for development, like a different logging configuration. opinionated-server apps take a --pretty_logs argument that configures it to print plain text instead of JSON, but I don't use it anymore; I just pipe the logs through jlog (`go install github.com/jrockway/json-logs/cmd/jlog`) and the results are much prettier than what zap would do itself. And it's the same tool I use every day to look at production logs, so there are no surprises. Ultimately, I wrote this because I like small pieces of software that do one thing, and found myself writing the same boilerplate over and over. Overall, this has been a success. I have written small utilities (github.com/jrockway/alertmanager-status, github.com/jrockway/nodedns, github.com/jrockway/alertmanager-discord, which I forked from someone else and converted to use opinionated-server), and larger applications (github.com/jrockway/jsso2, github.com/jrockway/ekglue), and overall not having to write the same monitoring/logging code over and over has proven quite productive. I have not achieved my goal of "1 hour to make a production application" quite yet, but opinionated-server is certainly helping.

a little better here. We use GraphQL at work, and the methods are typically of the pattern: func AutogeneratedMethod(context.Context, ...) { foo := MustGetFoo(ctx) bar := MustGetBar(ctx) return ActualThingThatDoesTheWork(ctx, foo, bar, ...) } This makes testing the Actual Thing That Does The Work easier, and the reader of that method knows exactly what sort of state the result depends on (the most important goal in my opinion).