hjacobs

Yes, the initial syncing and indexing can take a moment. I would recommend joining a single Pub or SSB room [1] to find people and grow your network organically. The large Pubs [2] have a lot of content to download and also follow bots (which you would have to block).

[1] https://github.com/staltz/ssb-room/blob/master/FAQ.md [2] https://github.com/ssbc/ssb-server/wiki/Pub-Servers

You need to connect with others. I think Manyverse is best used with SSB rooms where you can find others (to connect/follow), see https://github.com/staltz/ssb-room/blob/master/FAQ.md

Alternative is a Pub, but joining a Pub is not so great with Manyverse as it will download a lot of content to your mobile phone.

The Oasis SSB client [1] is a webapp which you open in the browser. Oasis (like nearly all SSB clients) is a JavaScript package which you can install via npm.

[1] https://github.com/fraction/oasis

I tried it out (see https://twitter.com/try_except_/status/1333499056769937408) and got great support in the Matrix/Riot chat (https://matrix.radicle.community). Definitely looking forward to distributed git changing the developer landscape :-)

I'm curious, did you use Patroni directly on Kubernetes or use Zalando's Postgres Operator [1] (based on Patroni)? [1] https://github.com/zalando/postgres-operator

It's a German registered association (e.V.), i.e. it's not only a single company or person behind it. Funding is done by membership fees. As a member you also get insights (regular newsletter) into the financial situation, e.g. how much money is on the bank account.

Yes, I'm actively using Codeberg for my OSS projects (I still have some on GitHub, too), e.g. https://codeberg.org/hjacobs/kube-web-view/

Some functionality is lacking compared to GitHub, but it does what it needs to do for me.

Great post, I will also add it to https://k8s.af (Kubernetes Failure Stories)

True, but at least they now have an API for account creation (AWS Organizations) --- it was really painful in 2015/16 to script (in the browser!) all necessary steps for account creation (add credit card, remove it again [to switch to invoice], etc)

It's not mentioned in the post, but PostgreSQL is the prime candidate to replace your MySQL: "The World's Most Advanced Open Source Relational Database". We are happy users of PostgreSQL in Zalando since 2010 (we switched from MySQL). Here some old slide deck (2013) where I briefly "ranted" about MySQL: https://www.slideshare.net/try_except_/goto-2013whyzalandotr...

Thanks for mentioning my collection of Kubernetes Failure Stories! I'll use this opportunity to encourage everyone to submit their own postmortems :-) --> https://github.com/hjacobs/kubernetes-failure-stories

"He" is "me" in this case, thanks for the link (and contribute some postmortems!) :-)

Also check out our Zalando Postgres Kubernetes Operator which is powered by Patroni: https://github.com/zalando/patroni/

It's supposed to be run locally. See also my small write-up on Kubernetes web UIs in 2019: https://srcco.de/posts/kubernetes-web-uis-in-2019.html

I work at Zalando where we run hundreds of PostgreSQL database clusters on Kubernetes (on AWS) using our Postgres Operator (https://github.com/zalando/postgres-operator). This gives us some added flexibility, quick startup (e.g. for e2e), and the latest PG features. That being said, I would be careful to recommend any specific stateful workload approach without good understanding of the whole setup (true for whatever cloud/k8s/onprem environment).

I can recommend joining the CNCF End User community [1] as it allows exchanging experiences around common problems, e.g. developer experience in a mid/large org, regulatory requirements (there are some banks in the CNCF End User community), etc.

For list of current members, see https://www.cncf.io/people/end-user-community/ (I'm working for Zalando and are co-chair of the CNCF End User Developer Experience SIG).

The CNCF End User community is a vendor-free zone, so you can also discuss and learn about experiences with certain vendors to have better insights before deciding on one ;-)

[1] https://github.com/cncf/enduser-public

Thanks, feel free to reach out on Twitter (https://twitter.com/try_except_/) --- we are always happy to share experiences on running K8s.

We try to keep it simple at Zalando, i.e. just using Mustache templating and wrapping kubectl to add extra commands. See https://www.slideshare.net/try_except_/developer-experience-...

As the author of the repo, I made it pretty clear that it's not about driving people away from Kubernetes. Please see my posts and talks about it, e.g. https://kubernetespodcast.com/episode/038-kubernetes-failure... and https://srcco.de/posts/why-kubernetes.html

As the owner of the linked GitHub repo (also rendered on https://k8s.af --- thanks to Joe Beda), I highly encourage everyone to contribute their failure stories (I'm still looking for the first production service mesh failure story..).

Also be aware of availability bias: Kubernetes enables us to collect failure stories in a (more or less) consistent way, this was previously not easily possible (think about on-premise failures, other fragmented orchestration frameworks, etc) --- I'm pretty sure there are much more failure stories in total about other things (like enterprise software), but we will never hear about them as they are buried inside orgs..

BTW, I also have a small post on why I think Kubernetes is more than just a "complex scheduler": https://srcco.de/posts/why-kubernetes.html

Triggered by Matthias' blog post, I wrote down my thoughts on the topic here: https://srcco.de/posts/why-kubernetes.html

There is now a Kubernetes podcast episode with me about the topic: https://kubernetespodcast.com/episode/038-kubernetes-failure...

In conversations, I often compare the Kubernetes API to the Linux Kernel API (as analogy) - both provide primitives we kind of "agreed on" in the industry. I hope the Kubernetes ecosystem will flourish in the same way as the Linux base.

Nice observation, I haven't done statistics on the linked postportems myself yet. Please note that your observation might also be due to the fact that AWS has a far larger market share and did not provide managed Kubernetes until recently (so people roll their own). We can therefore assume that any random sample of Kubernetes postmortems would be biased towards seeing more incidents with Kubernetes on AWS (compared to other cloud providers).

I agree, some better UI for end users would be awesome: Kubernetes Dashboard kind of works, but is pretty limited and more a "kubectl in the browser". There are a ton of nicer UIs for Kubernetes, but they are all part of the value-add of proprietary platforms AFAIK (think about all the managed K8s offerings out there).

Kelsey has the answer for you: "Kubernetes is a platform for building platforms. It's a better place to start; not the endgame." (https://twitter.com/kelseyhightower/status/93525292372179353...)

As an application developer, you probably also don't work with the Kernel and syscalls directly (anymore), so I guess you can expect higher abstractions and a smoother experience for Kubernetes in the future.

I'm not familiar with Docker Swarm, but the Kubernetes API is the major strong point for me (not saying that it's perfect): it has the right abstractions (CronJob, StatefulSet, ..) and is extensible (Custom Resource Definitions). There are many ways to run containerized workloads (ECS, Mesos, Docker Swarm, ..), but the de-facto agreement on the Kubernetes API is a game changer: now we can start building things on top of it :-)

DO K8s is pretty neat, but last time I checked it did not have the metrics server (CPU/mem metrics, also "kubectl top") yet.

I never used Docker Swarm (so can't compare), but I don't fully understand your point about Kubernetes cloud lock-in. Certainly there are important differences in networking, load balancing, persistent volumes, and other cloud features, but that's not something any platform can just hide/eliminate (e.g. think about AWS ELB/ALB/NLB vs Google Load Balancer). The Kubernetes concepts (Deployment, Ingress, Service) still work mostly the same for the user across clouds. Some other details like non-standardized Ingress annotations are obviously due to not having them agreed in Kubernetes core API (nginx ingress supports other annotations than say Google LB or Skipper).

Looking forward to your public postmortems.. (either yours or whatever you find in the wild)