epelesis

Yep Vite is the way to go, especially if it's a static site. While server side react frameworks like Next may technically support static sites, it feels like an afterthought and IMO it adds too much unnecessary complexity.

Here's a shameless plug (and demo) for a static Vite site I deployed with Cloudflare Pages. This tech stack has been awesome to use (and free): https://bufo.nedellis.com/

Here are some popular papers: https://github.com/rxin/db-readings

Once you finish the major papers, CMU has a ton of talks from more recent database research projects: https://db.cs.cmu.edu/seminar2020/

You could also try building a simple database from scratch, like this: https://www.awelm.com/posts/simple-db/

Also if you are specifically interested in SQL, make sure to learn relational algebra/calculus.

I agree, Silicon Valley (e.g. Mountain View, Santa Clara) is absolutely full of tech talent but the average engineer is mostly interested in and optimizing for work in big tech companies.

SF tends to skew towards smaller tech companies, alongside remote and other cities.

Of course these are just generalizations.

BW Trees are pretty neat [1][2]. Typically BTrees in database engines need latches to prevent concurrent writes messing up the tree but BW Trees conveniently sidestep that requirement by appending all node updates to a linked list (called a Delta Chain), and having each reader apply the delta of updates by traversing the linked list until it hits the final node in the list. Periodically, these linked lists are compacted back into single nodes.

If you like these kinds of data structures, the Database Internals [3] book has a good introduction and explanation of a handful of BTree optimizations like this.

1: https://www.microsoft.com/en-us/research/wp-content/uploads/...

2: https://www.cs.cmu.edu/~huanche1/publications/open_bwtree.pd...

3: https://www.databass.dev/

IMO if you're working on any non-trivial backend project, then you're already a "distributed systems engineer". Distributed systems problems are everywhere in the software world if you need to manage state and consistency across more than a single machine.

If you're asking how to work on interesting distributed systems, then I'd recommend trying to work at a tech company that is either large in and of itself (i.e. FAANG), or one that makes it's money solving distributed systems problems for others (i.e. Hashicorp, Snowflake, ...).

Either way, you can get a lot of value reading famous distributed systems papers, and building your own software projects that replicate the building blocks of these systems. For example: DNS, Gossip Failure Detector, Consensus (e.g. Raft), SQL Database, etc...

One reason this is not feasible is that K8s is not designed for secure multitenancy, so for every tenant, you'll need to spin up an entire K8s control plane, which includes a database and several services - this is what's driving the cluster fees. Keep in mind that customers also expect managed K8s to be highly available, so this cost is also going into things like replicating data, setting up load balancers, etc...

Compare this to a serverless offering that is multitenant by design, the control plane is shared making the overhead cost of an extra user is basically zero, which is why they don't charge you a fee like this.

IMO if you're a hobbyist interested in K8s, your best way to go is to install K3s, which is a lightweight, API compatible K8s alternative that runs on a single node. It's pretty nice if you don't care about fault tolerance or High Availability.

https://k3s.io/

I work at a somewhat well-known unicorn in the data space that has been using this architecture for a while. In fact I'd wager that any (non-cloud-provider) company that provides any significant amount of compute or storage in their product offering will converge upon a layout that closely resembles this.

Overall I'd imagine there are a lot of parallels to other SaaS-ish architectures, one big divergence is that I'd consider the data-plane to be a special kind of client, (client in the same way that a user's phone or browser is). The big difference is that we (the company) ALSO manage the lifecycle of this "client" (i.e. shutdown, startup, repair, update). Having an untrusted client that you also manage the lifecycle of can lead to some interesting design spaces.

You might be interested in this table table mapping internal tools/technology at Google to public equivalents: https://github.com/jhuangtw/xg2xg

I've had my eye on this autoscaler for a while now, has anyone had experience running it in production with a large rate of node churn?

I think combining the scheduler and the autoscaler into a single entity makes a lot of sense, both from a latency/performance perspective as well as a data sharing perspective - we have some complicated rules on when nodes are eligible to be terminated that are tightly coupled to the lifecycle of certain pods in the system, and as it stands we have to implement all of that logic with the assumption that the scheduler may (re)schedule pods concurrently while we are performing terminations. For this kind of application where pods and nodes are tighly coupled, having all of that logic in a single place is pretty attractive to me.

Another really signifigant (and unexpected to me) scaling limit for us has been ratelimiting on behalf of the cloud provider... I believe that since AWS leads development of Karpenter they have also optimized a lot of the API calls Karpenter makes to try to more efficiently use the API Quotas in AWS that each tenant has, and this is one of the main reasons Karpenter caught my eye in the first place.

The keyword you're looking for here is Operator [1]. Kubernetes Operators are custom resources (e.g. Database, Load Balancer, ACME Certificate Entry) that manage themselves via a reconciliation loop. If you're looking for a specific piece of infrastructure, search for `<YOUR_TECHNOLOGY> + "operator"`, (e.g. "Postgres Operator", "Kafka Operator", etc...). Once you find an operator for the piece of infrastructure you need, just follow their instructions on how to set it up and configure it. Learning about how operators work is pretty neat and writing your own is fairly simple if you don't find an operator for your use case.

Personally I run my personal cluster on K3s [2], secure it with cert-manager [3] and route traffic via the Traefik Operator [4]. Right now I use Litestream for all of my DB needs, but I've heard good things about the Postgres Operator by CrunchyData [5].

1: https://kubernetes.io/docs/concepts/extend-kubernetes/operat... 2: https://k3s.io/ 3: https://cert-manager.io/ 4: https://doc.traefik.io/traefik/providers/kubernetes-ingress/ 5: https://github.com/CrunchyData/postgres-operator

Since no one has mentioned it so far, I'll go ahead and link a very insightful paper that the creator of Erlang actually wrote about how fault tolerance from the actor model make concurrent programming a breeze:

https://erlang.org/download/armstrong_thesis_2003.pdf

The guy [1] who runs this project is super nice, about a year ago I was working on my own Rust based VM and he dropped in with a couple of helpful tips and ideas.

[1]: https://github.com/lpil

I'm taking Jeff's 473 class right now and if you like his writing style, all of his lectures for both algorithms classes he teaches are online as videos - it can be a good companion to the textbook if you want worked examples. [my video] links should be raw MP4's that are not password protected.

374 (Introduction to Algorithms Videos): https://courses.engr.illinois.edu/cs374/fa2019/A/schedule.ht...

473 (Algorithms Videos): https://courses.engr.illinois.edu/cs473/sp2020/lectures.html