using zalando's patroni operator in k8s at scale for years (mainly OCP but pure k8s as well).
Features like in place major version upgrade are no match for any of the alternatives checked.
Close to it is CNPG (cloudnative-pg) which is 2nd best and in 1yr might take the crown.
(for companies, best part is that cnpg has enterprise support for it (named pg4k, a fork of cnpg).
But, above all, I would warmly recommed anyone to first do their best to use cockroachDB (or yugadb if you like more) instead.
The benefits of distributed/horiz scaled DB usually overcome the effort of moving to it (which should not be big as it's using same pg client/protocol). And it's free if you don't need enterprise features like partitions, etc.
A “graduated” project might find it easier to get adoption, contributors, as the guarantees (stability, integrity, security, governance) are some of the criterion that org use while deciding on tooling.
It’s basically saying: If you were shying away from using Istio in production, we graduated, take a look now?
The graduation criteria I care about is "Have completed an independent and third party security audit". Lots of software in the cloud native world puts security in the back seat sadly!
LimeSDR didn't make nearly the splash it should have; why? I recall hearing the first iterations of the hardware were skittish and noisy; did they never improve?
Thanks for the links. Yes it might. In the same time the ADPS has lower requirements to operate: a PC and a USB-flash. LoRa requires specific boards, in some countries it's much easier to buy old PC than to find LoRa boards. And the ADPS can transmit and receive much larger files compared to LoRa.
as some mentioned, there are benefits and there are costs applying the 'lift and shift' for big things like kafka (and elastic search, DBs, etc).
The main assumption is that MOST of your apps (especially the ones affected by kafka access latency) run in k8s already. Access from outside should be mainly for:
a. integrations with other systems which do not have very strict latency constraints
b. replication to disaster recovery site
The benefits are listed (between lines) in both article and below.
Price is is usually still treating those pods like pets:
- one pod per k8s node (taints&node selectors)
- special sizing & tunings of the targeted nodes (resources, kernel params, etc)
- one LB per Pod. yes, costly and against what you would expect, but that's what is required for a bullet proof deploy. (delay is not always there, especially in clouds, LB have super efficient implementations (especially gcp)
- bullet proof storage, with the required performance computed in your sizing phase.
maybe we skip the need and move to https://crossplane.io, to abstract all this part as well as gain 2nd day operations natively, and k8s readiness.
(bonus: the closest path to cloud agnostic definition)
But, above all, I would warmly recommed anyone to first do their best to use cockroachDB (or yugadb if you like more) instead. The benefits of distributed/horiz scaled DB usually overcome the effort of moving to it (which should not be big as it's using same pg client/protocol). And it's free if you don't need enterprise features like partitions, etc.