On 6/27/24 10:26, Marthin Laubscher wrote:
On 2024/06/27, 19:04, "Adrian Klaver" <[email protected]
<mailto:[email protected]>> wrote:
And substituted a single platform dependence.
Even bare metal can lock you in without some abstraction layer between your code and the
hardware. It's true that Kubernetes is a "single platform" but it provides the
same facilities in all of its guises from bare metal implementations to what you can rent
on demand from public clouds. I've made peace with that being about as cloud-agnostic as
I can realistically achieve.
Which now leads you to above.
To me that's a good thing. I've got no time for puristic idealism. It's a pragmatic
choice which always involve compromises. "Compromise knowingly", an old manager
of mine used to say.
Yugabyte, if I did go with it, would have been a tough choice because it would
lock me into them as database vendor which would only make sense if it unlocked
a massive performance upside. For all intents and purposes I'm already locked
into PostgreSQL as my application's database because it's reliant on a custom
extension like no other database would let me do. But single database isn't
single vendor, as long as it's open source. If YugabyteDB did support my
extension (I tried but they won't consider for their DBaaS/Managed/Yugabyte
Anywhere/Yugabyte Aeon commercial product built on top of an old version of
PostgreSQL) it would have meant that in a pinch I could rent additional
capacity from their commercial offering while I expand my own points of
presence. That kite's not going to fly though, so I'm back to dealing with all
of the data distribution logic in my application layer itself.
So when you're done trolling me and my choices, feel free to comment on the
actual question.
Not trolling just pointing out what you described above. Sometimes
simple is not and you end up going through all sorts of contortions to
stick to the plan. Just an observation take it or leave as you like.
--
Adrian Klaver
[email protected]
