I’m developing a SaaS application that consists of three main components: 1) a Rails application, 2) a Python backend, and 3) a small Node.js service.
For each customer I’d want to do a deployment of these three services. Something like:
A customer signs up for the service.
In response, I trigger a single API endpoint which initiates the deployment of these three distinct services.
If a customer decides to discontinue the service (churns), I can then call another API endpoint with a specific ID, which will then shut down all three services associated with that particular customer.
Just to confirm, it sounds like for each customer you’d like to spin up 3 services (consisting of a Rails, a Python and a Node service). Is that right?
Do you know for certain that you want each customer to have their own set of services? Could you tell us a little more about your project?
If you’re building a white-label product that customers can customize themselves, I think there might be a better way, but I’d love to learn more about you’re envisioning before prescribing any solutions.
Just to confirm, it sounds like for each customer you’d like to spin up 3 services (consisting of a Rails, a Python and a Node service). Is that right?
Yes, that’s right.
Do you know for certain that you want each customer to have their own set of services? Could you tell us a little more about your project?
I keep on trying to wrap my head around if I could avoid this, and somehow use db multitenancy. But it’s the type of project where traditional customers are barely used to deploying to the cloud at all. Let’s assume worst case scenario, all three.
If you’re building a white-label product that customers can customize themselves, I think there might be a better way, but I’d love to learn more about you’re envisioning before prescribing any solutions.
It’s not white-label, it would more traditional SaaS but with fewer enterprise customers and larger contracts.
Thanks for the extra information. Happy to defer to your judgment about whether to use data stores for multitenancy or not, you know your project best!
As to your initial question, Fly.io offers a REST API (known as the Machines API) which allows you to do spin up applications, manage VMs and more. Checkout documentation for this here: Working with the Machines API · Fly Docs
One thing to note is that the standard REST API covers most tasks, you may need to rely on the GraphQL endpoint or the flyctl CLI for allocating IP addresses for these new services. See the section here Allocate an IP address for global request routing
Hi @mbarbudas , I too was out for the holidays, thank you for your patience!
So without knowing exactly what you’re building, it’s hard to prescribe anything specific. The reality is depending on what you’re making, there are different ways you could architect things, but here are my thoughts:
From what you’ve described, you’ll almost certainly want 3 apps per customer, and not 3 machines, since machines should really be treated as ephemeral objects used for scaling. This gives you the flexibility to scale the number of machines per customer as you see fit.
It also sounds like you’re going to have a “parent” app that manages the creation and destruction of these customer apps, which will probably have it’s own database that keeps track of which apps belong to which customers.
You can create a single docker image with all 3 services, and define a process for each with the respective launch command, then the app will have 3 (or more, you can scale individually) machines, each with it’s own service.
After that you can create an app for each client that will have the separate machines, the only challenge could be keeping all the configs synced between apps, but there is probably some smart way to do that.
Agreed with @Tc001 , process groups is another great option. This typically works when you only have one process group (service) that accepts Internet traffic, but there are ways around that too, I believe. Definitely worth checking out, then you would have fewer apps per customer to manage.
If you know you’ll need a way of routing traffic based on which customer app is being hit, I would check out Fly replay: Dynamic Request Routing · Fly Docs – it basically lets you forward a request to a specific app, machine, or other criteria.
