This is exactly my experience at Lovable. For some parts of the organization, LLMs are incredibly powerful and a productivity multiplier. For the team I am in, Infra, it's many times distraction and a negative multiplier.
I can't say how many times the LLM-proposed solution to a jittery behavior is adding retries. At this point we have to be even more careful with controlling the implementation of things in the hot path.
I have to say though, giving Amp/Claude Code the Grafana MCP + read-only kubectl has saved me days worth of debugging. So there's definitely trade-offs!
Neon does a variant of this. The WAL goes through a Paxos consensus directly on NVMe, which then is transformed to page files and stored in Object Storage
Django was the whole start of my career and I still thank it for many of my opportunities. I started in 2012 to work with Django at Billogram, then founded a Django consultancy which lead me to work at King 3 years later.
Who knows where I would be today if not for Django!
We're working on a Container Registry for https://molnett.com. We don't really want to use Harbour as we want to manage our own AuthN/AuthZ and are fully multi-tenant, so we decided to build our own on top of Distribution.
Going from Manifest to OCI is a bit tricky and performance for calculating total storage based on metadata is hard to get right. But the result is that we own our full registry implementation and can take it any direction we want. Quite happy with that!
I don't think you are wrong at all. As we are all founders with an OK salary and this is our area of expertise, so we're able to take advantage of our previous experiences and reap the benefits. We're probably uniquely positioned here.
I had massive issues at my previous employer with Bazel. They did not try to make Bazel work for non-SREs, which as you can imagine didn't work very well. So it's definitely not a silver bullet!
We should probably write a blog post about our setup!
I think this take is quite shallow and lacks insight into how one would actually build a somewhat complex technical platform.
We are not using a microservice pattern at all. I am not sure where you get that from. If anything we have several "macro services".
Our final setup is quite complex as we are building a literal cloud provider, but in practice we have a Go API, a Docker registry, a Temporal Worker and a Kubernetes controller. Whats complicated is everything else around it. We run our platform on bare-metal and thus have auxiliary services like a full-blown Kubernetes cluster, Ory Hydra + Kratos, SpiceDB, Cilium, Temporal Cluster + Workers and some other small things. We need to be able to test this locally to feel safe to release to production. And in turn our production environment is almost identical to our local environments.
None of that would be possible unless we've done something similar to what we have built today. Most companies cannot run their entire stack on their laptop, more unlikely that they could run a full cloud provider.
I firmly believe that us at Molnett(serverless cloud) going for a strict monorepo built with Bazel has been paramount to us being able to make the platform with a small team of ~1.5 full-time engineers.
We can start the entire platform, Kubernetes operators and all, locally on our laptops using Tilt + Bazel + Kind. This works on both Mac and Linux. This means we can validate essentially all functionality, even our Bottlerocket-based OS with Firecracker, locally without requiring a personal development cluster or such.
We have made this tool layer which means if I run `go` or `kubectl` while in our repo, it's built and provided by Bazel itself. This means that all of us are always on the same version of tools, and we never have to maintain local installations.
It's been a HUGE blessing. It has taken some effort, will take continuous effort and to be fair it has been crucial to have an ex Google SRE on the team.
I would never want to work in another way in the future.
EDIT: To clarify, our repo is essentially only Golang, Bash and Rust.
I just used Sonnet 4 to analyze our quite big mono repo for additional test cases, and I feel the output is much more useful than 3.7. It's more critical overall, which is highly appreciated as I often had to threaten 3.7 into not being too kind to me.
I really do hope that their OSS strategy does not change due to this, as it's really friendly to people who want to learn their product and run smaller deployments. It's (intentionally or not) really hard to run at a big scale as the control plane is not open-source, which makes the model actually work.
I'm right now working on the Managed Postgres offering for our European Serverless cloud provider, https://molnett.com/. We're building it around Neon and are happy with it so far, but are stumbling upon unforeseen issues like query modes (Thank you Pgx for not being compatible by default with PGBouncer).
Our company's biggest remaining problem is finding a reliable IdP that isn't primarily for individuals, self-hosted or based on Active Directory. There are some alternatives, but they are mainly country-specific (like Freja) or not well integrated enough with e.g. OAuth. We've considered at some point to pivot our company to focus on a fully European IdP, as we feel it's a fundamental missing puzzle piece!
I didn't expect the comments in here to be so negative.
It's a decent service in itself and a good alternative to many other traditional VM-based hosting companies, which Europe is absolutely full of. They are not really competing with the hyperscalers, nor even Digital Ocean in my opinion, but rather providers that likely sell pre-committed OpenStack clusters and such.
I don't believe they are fully clear of American-owned companies in their entire dependency chain, nor do I believe that it's possible to do that today. Companies like Equinix provide a damn good solution for homogenized infrastructure that is invaluable for cloud providers.
I can't say how many times the LLM-proposed solution to a jittery behavior is adding retries. At this point we have to be even more careful with controlling the implementation of things in the hot path.
I have to say though, giving Amp/Claude Code the Grafana MCP + read-only kubectl has saved me days worth of debugging. So there's definitely trade-offs!