5 ms·

For recent projects I've been using PostgREST + postgresql-replicant + Kafka (or some durable message queue as appropriate). I don't have to work too hard to i

For recent projects I've been using PostgREST + postgresql-replicant + Kafka (or some durable message queue as appropriate). I don't have to work too hard to implement the control plane as PostgREST takes care of generating the API and Postgres already has authorization controls built-in. Authentication is the part that requires a bit of toil to figure out. The rest is managing the schemas of the control plane entities. Basically, design the data and most of the rest is generated for me. The data plane is trickier but I'm experimenting with using Postgres' streaming logical replication protocol to convert logical queries on the control plane data into business domain events that are forwarded onto the message queue. This is the part that uses the postgresql-replicant library I wrote but other libraries written in Python exist and can do the same thing. This then enables me to implement business logic/data-plane actions asynchronously down-stream as isolated, stateful services that follow the event streams and react accordingly to various policies. They can then update the control plane models as they progress, which then could add more domain events to the stream, and so on. It's a bit like a functional-reactive architecture. I don't know if it's a production ready style architecture. Monitoring replication stream performance can be tricky and integration testing is challenging. And managing changes to the business domain is not a fully-solved problem: still a lot of exploration/tooling/and do-it-yourself duct-taping to do. But it's simple enough that I can do lot of work with very little code so far.

infra_dev 4y ago
Hey, this is Ram, the author of the post. Would love to know how this architecture works in production for you. For infrastructure saas, the control plane needs to manage 100's of data planes. It also needs to own user and tenant management, security policies, billing based on usage, usage and operational insights for your users. The challenge is in building an infrastructure that can centrally manage the lifecycle of all the metadata (SaaS, app and infra) and orchestrate with all the data planes. Postgres is definitely a good building block to build on top of but there is so much to build around it to make this work well in our experience.
- agentultra 4y ago
  Managing the data plane is the more complex part of it as you would expect. I do tend to model the business processes at a high level using domain-driven design and map the aggregates to services that ingest event streams. The services then react to the event streams in several ways: emitting events, updating control plane models, issuing new commands to other services, etc. Each service keeps its own state internally and if I need to, I can blow away their state and replay all of the business domain events thanks to the durable message stream. That part is key... and is also the most duct-tape-and-toil area of this architecture. I've been toying around with ideas to generalize this into a consolidated application framework but it's still pretty experimental stuff. The high-level architecture isn't terribly novel or new but having standardized tools for common operations, managing migrations from event schemas, managing checkpoints, etc; is still a work in progress.
deleted 4y ago
[deleted]

infra_dev 4y ago

Hey, this is Ram, the author of the post. Would love to know how this architecture works in production for you. For infrastructure saas, the control plane needs to manage 100's of data planes. It also needs to own user and tenant management, security policies, billing based on usage, usage and operational insights for your users. The challenge is in building an infrastructure that can centrally manage the lifecycle of all the metadata (SaaS, app and infra) and orchestrate with all the data planes. Postgres is definitely a good building block to build on top of but there is so much to build around it to make this work well in our experience.

agentultra 4y ago
Managing the data plane is the more complex part of it as you would expect. I do tend to model the business processes at a high level using domain-driven design and map the aggregates to services that ingest event streams. The services then react to the event streams in several ways: emitting events, updating control plane models, issuing new commands to other services, etc. Each service keeps its own state internally and if I need to, I can blow away their state and replay all of the business domain events thanks to the durable message stream. That part is key... and is also the most duct-tape-and-toil area of this architecture. I've been toying around with ideas to generalize this into a consolidated application framework but it's still pretty experimental stuff. The high-level architecture isn't terribly novel or new but having standardized tools for common operations, managing migrations from event schemas, managing checkpoints, etc; is still a work in progress.

deleted 4y ago

[deleted]