Thanks to Forge’s use of Auto-Deploy, when you push up your code changes, they will automatically be rolled out to all your clients!Enter Pulse — your monitoring solutionAs you can imagine, if you’re successful and onboard dozens, hundreds or even thousands of customers, then your infrastructure would end up being equally impressive.
You’ll need a tool to keep on top of that…Pulse’s server monitoring dashboardPulse was designed specifically for the purpose of being used by developers to automate server monitoring.
It includes the APIs required to create a new server profile, configure the relevant monitors for hardware and key services, set the alert notification channels and retrieve server logs.
You can learn about Pulse’s APIs through the documentation.
You might be wondering how the job to create the profile works.
Actually, it uses another great feature of Forge… recipes.
Essentially the job generates the code for a shell script and then stores / runs it on the server using a recipe.
The recipe sends the API requests, downloads the monitoring script, makes it executable, then creates a CRON entry for it.
Conclusions of the approachHopefully, this short article has shown you that it is indeed possible to run a server per client strategy that doesn’t involve a manual process.
Nevertheless, using this kind of strategy has both pros and cons.
Let’s take a look at them:ProsYou never need to mess with / worry about the problems that go with creating an application that uses multi-tenancy.
Data is forever isolated and you don’t need to wrap your application logic within scopes.
Your clients are protected from server failures… to an extent.
If you run a multi-tenant application / server infrastructure and something brings it down, all of your clients’ sites go down.
With a server per client, this can’t happen (unless the entire data centre goes down).
Creating backups of the database and application files is considerably easier.
Likewise, purging a customer is also easy… just delete the server.
Performance is generally better.
With a distributed architecture, no single set of servers is being hammered by thousands of users.
Developing custom features is generally easier thanks to a separate file system for each client, and may provide a vital source of revenue.
You can charge your clients when they wish / need to upgrade their infrastructure, which may serve to supplement revenue.
ConsThe on-boarding process takes about 30 minutes.
Depending on the type of application you’re building / what your customers are prepared to accept, that may not be viable.
Your cost per customer is higher as they each require a server, which you will be charged for.
You’ll need to factor that into your app’s pricing, but if you’re charging them hundreds or thousands, it’s not much to swallow.
If you need to fundamentally change the nature of your application, its dependencies, the services it needs etc.
you might be in for a long road to prepare all your customer servers for the change.
When should I use it?Generally, I would say that if you’re not offering clients’ subdomains for their accounts / vanity URL integration, then you don’t NEED to use the server per client approach, but it doesn’t mean you can’t.
As I highlighted above, there are other hurdles involved in multi-tenancy applications.
Your code is also a lot more complex than it would otherwise be, so that may also be something you want to consider.
Wrapping upThanks for reading, and if you have any questions, please do feel free to share them.
I’ll do my best to answer them!Be sure to follow me here, and on Twitter, for further articles and updates on what I’m currently up to.
Oh, and if you feel so inclined, please check out / spread the word about Pulse.
It would mean a lot to me ????Remember that even if it’s not for you, you can still earn a 30% commission by referring friends, colleagues or followers to the platform.
Happy coding… ????????????.. More details