[plumeria]

> Carbon on the other hand appears to be quite a few different components, with many dependencies, some of which are SaaS products, and uses a database (Supabase) which is itself a whole microservice ecosystem that is a considerable effort to deploy

Perhaps this could be addressed by providing a Pulumi or Terraform program?

[danpalmer]

It's not just about the initial deployment, although these may help. If you're running Wordpress, the question "why is it slow" is pretty limited in scope – you need a faster webserver, database, or maybe need those two to be closer to each other. A simplification but not much of one. For this, is it the app server, the task queue, or one of several other components, or is it in the Supabase layer, or is it a dependency that someone else runs... etc.

Figuring out issues get more complex, scaling gets more complex, backup and recovery get more complex, now you need monitoring for it all too, and with many services the complexity multiplies.

All of that complexity is somewhat justified for a team that exists to build and operate the system (i.e. SaaS), but doesn't really work for a team who exist to build something else and have just been tasked with operating this.

[xorcist]

There's also the issue of having a dozen moving parts form the system, each developed for their own reasons. So you could find that upgrading one product changes something, say collation for utf-16, which might be entirely reasonable taken in isolation but that the rest of the system is unprepared for.

It is up to you to fend off dozens of small things. Over time that accumulates. It's like python programmers using two dozen pypi dependencies because they've heard nih is bad. Or think nodejs if that's your thing. What you do in practice is you freeze everything in place and then you postpone it all for an increasingly indefinite future. Organizations then periodically need to freeze work for weeks or even months at a time just to keep up with dependencies. This is clearly a lot of work.

Terraform, or even better Ansible, is a good choice to document make those changes over time in a standardized way. But it doesn't make the work go away. The work is there and still has to be done. Those tools also clearly suffers from the same many-moving-parts problem, as soon as you include external modules with their dependencies too, so you have take care not to magnify the problem by accident instead.

This is what system admins and integrators do all day. They will tell you in unison that the best integration is the one that doesn't exist.

[barbinbrad]

I think we can simplify this over time. Everything in our stack is MIT/Apache. I'm keeping my eye on this fastabase project from Drizzle: https://github.com/drizzle-team/fastabase/tree/main