I’ve been looking into upgrading Istio using canary upgrades. Canary upgrades let me test a new version of Istio by migrating part of the workloads to the new version and observing the impact of the change. If anything goes wrong, I can roll back to the old version.
Streaming data is a commodity. Thanks to all sorts of streaming data sources we can build reactive systems whereby an event occuring in one corner of the system triggers events somewhere else. Streaming data speeds up processes because businesses can react to events instead of proactively having to ask for “what’s new”.
In the previous article on OPA1, I asked this question:
why would Ory Keto drop OPA from its implementation?
What’s Ory Keto? After Ory Keto documentation2:
Ory Keto is the first and only open source implementation of “Zanzibar: Google’s Consistent, Global Authorization System”.
If you’re working with go on a regular basis, chances are you have come across the problem of working with private modules. Let’s quickly recap:
Your organization hosts go modules at github.com/your-org. There’s some private project at github.com/your-org/awesome-stuff. This private project depends on other private modules, you have this in your go.
This one is like riding a bicycle. Once you know it, you know it. I’ve been going down some Kubernetes rabbit holes and I’ve landed on OPA - Open Policy Agent.
The Open Policy Agent (OPA, pronounced “oh-pa”) is an open source, general-purpose policy engine that unifies policy enforcement across the stack.
Shortly after I have published the previous article on YugabyteDB CDC1, the amazing Yugabyte team released the 2.13 version of the database with a beta implementation of the new change data capture SDK. Before diving into the new SDK, let’s quickly recap the first implementation.
19th of March, 2022:
Interested in YugabyteDB CDC? YugabyteDB 2.13 comes with an all-new beta of a CDC SDK: YugabyteDB CDC SDK beta, a high level overview.
Today I’m going to look at change data capture (CDC) in YugabyteDB. Change data capture is a data integration method based on the identification, capture, and delivery of data changes.
With every version, the number of PostgreSQL features supported by YugabyteDB inevitably increases. This is good! However, it is pretty difficult to come by a comprehensive list of unsupported features. There’s a roadmap on GitHub1, but the roadmap lists top-level features and misses the exact list of statements and keywords.
I wanted to look into Keycloak.X for quite a while. Keycloak.X is a lighter, faster, easier, more scalable, more cloud-native solution than the—now legacy—WildFly based Keycloak.
Keycloak.X is now officially known as Keycloak 17.0.0, the first official Quarkus-based version. It’s been released a few days ago1 and so it was the right time to look at it.
The YugabyteDB RPC API isn’t an official API, and that’s what makes it interesting. The whole distributed aspect of YugabyteDB is based on that API. Digging through it is a perfect way to understand the internals of the database. The RPC API can also be used to automate various aspects of the database.