mulander

In the article, mentioned Linux is mentioned as the underlying OS. Wonder what approach Ubicloud takes (if any) to have actual diversity in the software stack for the purpose of reliability and security. My assumption here being, that different OSes, while increasing the attack vector also make it more likely that the whole fleet is not susceptible to the same software problem or vulnerability at roughly the same time. Just something I started pondering about after seeing Hetzner, which is quite popular in the BSD land.

Because with schema-based sharding in Citus, the schemas are the sharding unit and the system can move them to new nodes being added to the cluster.

You can start with all your microservices sharing a single node, add nodes and have the storage layer distributed horizontally in a way transparent to the services themselves.

They can be different, as long as your application can handle them being different (which makes sense for microservices as an example).

Schemas are groupings of tables and other entities that can be defined within a database. You can think of them like of a namespace in programming languages. You can have the same table definition, within the same database, defined multiple times (each in a different schema) and each holding different data.

By large and small we are referring to the amount of data each schema holds currently. They can grow over time and some of them may become very big while others will remain small (storage wise).

Hi Nathanba, I am a technical program manager for the Citus extension at Microsoft.

> Citus also exists for Postgres but their docs basically tell you that it's only recommended for analytics

Could you point me at the docs that made you think that? We find Citus very good at multi-tenant SaaS apps (OLTP), IoT (HTAP) workloads and analytics (OLAP).

> And it sounds like all it's doing is a basic master-slave postgres setup with quite a few manual things you have to do to even benefit (manually altering tables to make them sharded/partitioned)

This is true for now. We are looking into ways to make onboarding easier. That said, the time spent on defining a good sharding model for your data often leads to very good perf characteristics. Regarding the architecture, I personally find Citus closer in spirit/design to what Vitess is doing. Additionally, every node in the cluster is able to take both writes and reads, so I don't see the parallel to a basic primary/secondary setup.

Developers are categorized as people with commit access to the project. So contributing patches itself is not enough to add entries to this specific file.

- Meetings are remote first. If at least one person is remote then the whole team video calls in. There is nothing worse than being a person on the virtual end trying to understand a mic grabbing voice from a room full of people.

- Schedule peer programming sessions, especially with less senior staff. Without the office environment they have less opportunities to grow.

- All meetings should have a note listing all decisions made.

- Promote async communication. Have people describe a problem instead of saying hi and waiting for a reply.

> just that it minimizes the attack surface

I stopped using multiple browser for exactly that purpose. It actually increases your attack surface. While compartmentalization of browsers helps somewhat against tracking you now have to keep all of them updated. RCE bug in one of them already compromises everything you have on your machine, so having multiple browsers just means the attacker can pick from a wider array of targets.

History is funny. KHTML (a KDE project) was repurposed to WebKit by Apple and integrated with Safari. Which in turn was taken by Google that built Chrome on it. They later diverged more and now other browser are being built on repurposed Chrome. It would be funny if Safari was really replaced by Chromium as that would mean the offspring has eaten the parent.