I’m working on Alaska, a serverless compute platform I built entirely from scratch — no Kubernetes, no existing orchestration layers. It can spin up dozens of containers in parallel in just a few seconds. The platform is designed around a fast feedback loop — you write code locally, test instantly, and run it remotely with minimal friction. There’s a Python SDK that uses decorators to define what runs on the platform, so your local functions become distributed services without extra boilerplate. I also built a custom filesystem using FUSE to handle code, data, and runtime synchronization cleanly across nodes. It started as a personal exploration of distributed systems, but it’s grown into something that feels genuinely exciting! It's created by a developer for developers. Planning to open it up for beta testing soon.

I'm always impressed by the quality of the blog posts coming out from clickhouse.com! Super well written!

Thank you! We try ;)

Basho blog quality 4ever.

It's a deep-cut reference. But it's one I am honoured you made.

:mug:

Redis I would say, by Salvatore Sanfilippo (https://github.com/antirez)

OG redis was great. I think post-antirez it has grown too complex.

I'd be interested in a redis-lite fork.

It's kinda natural evolution. It started with "just a KV store with few extras" and just grew more and more and more extras over time. It's "... and the kitchen sink" of databases.

Thanks for sharing the link and your advices. I've never thought about squads as they are explained in the website.

Thanks for the tips! I appreciate them :)

I've been noodling for a while regarding Kanban. Where do you see the main advantages in using it?

I think scrum is great when you have following properties: - clear goals - not a lot of interruptions - tasks / projects are particularly timeline sensitive. - you want to measure output and plan initiatives far into the future

Scrum can also have a fair amount of overhead, all of the rituals, eg pointing tickets, refining the backlog.

Also daily standup / status updates for 12 people can be a lot of time.

When you have support queue, operational responsibilities and regular dev work all going on in the same time, you might find you're spending a lot of time trying to ensure some amount of work gets done in a sprint, while support burden / operations supersedes estimates, which then pushes work to next sprint. So the sprint effectively becomes meaningless, because there is always lots of carry over.

Kanban does require a mature, self motivated team too though, since deadlines aren't as clear necessarily.

Thanks for the tips. I do appreciate them :)

`Don't let them get bogged down or pinged constantly. Try to make that request flow async.` - This is very true yet so hard. Slack is not helping at all with this issue. I will check with the team about office hours or maybe a triaging system to minimize the Support effort.

If you have a #platform team channel don't let that become the place the rest of the company comes and makes unfiltered requests. That's the channel for your team. It's really important to have that boundary, otherwise they don't have a safe space to communicate and have to resort to private channels. People should be able to see what the platform team discusses but not necessarily just start asking random support questions.

Also, try create a knowledge base for the rest of the company. If there's frequent issues that are already resolved which others could just search a page for or some runbook for things they can do themselves it's best to give them that "self serve" method.

Makes sense -- Knowledge Base is something I should definitely tackle. Thanks :)