I’m totally in sandbox mode of build, destroy, build, modify, destroy, build etc etc etc mode trying to wrap my head around R-Cloud.
The immediate benefit of using Cloud vs Shared Hosting is being able to customize the architecture of your environment. I mentioned this when I started diving into installing the Adapt Authoring Tool. Tim has been super busy adding all kinds of neat tools so of course I want to see them.
On my shared hosting there are also lots of great tools, so when I’m there I head to cPanel, spin up a subdomain, and install an application like wordpress or lychee. My gut reaction in Cloud is to head to the market place, find the app, and one click install it. This of course spins up a whole new environment (which is so handy), but what got me reconsidering my approach and frame of mind around Cloud vs Shared hosting was the 3 environment limit for the beta.
It felt natural to spin up a new environment for every application I wanted to install, but that prompt got me wondering about adding multiple applications to one environment that used the same stack (which is how I believe the shared hosting works). I wonder how common my inclination to just spin up whole environments would be among others in the beta or more generally, and the pros/cons of that approach would be.
As I was typing this I recalled that cPanel is an option to install into an environments. Does this mean in theory I could spin up an environment with a cPanel similar to my Shared Hosting account? My brain is frying with the possibilities but also with trying to reconcile how I work with applications.
There are definitely pros and cons to both approaches. It’s cleaner to setup separate environments for every project because you can more easily track resource usage for a project, you can share that environment with other users, or even transfer ownership to another user. Logs are cleaner since you know there’s just one application you are focusing on. So lots of benefits to keeping it all separate.
The argument for multiple applications that share a stack using the same environment would in part be one of resources. For example you could absolutely have an environment with a MySQL database and use the connection details to host many MySQL databases. In fact many of the app server stacks support multiple deployments (subdirectories like /blog /course etc, not subdomains) so a single LEMP stack could get you pretty far. cPanel is overkill, technically possible but it comes with high licensing costs and rarely cost effective unless you’re a hosting company serving up sites for hundreds of users.
The 3 env limit for beta will disappear when we go commercial and there are technically no costs for an environment, only the resources that it uses (disk space and cloudlets). So in that sense while a single environment housing a bunch of projects might seem an attractive idea to save money, you have to be sure you aren’t creating a massive stack that is running 36+ cloudlets when 8 different environments running 2-3 cloudlets each might also work. So finding a balance is key and some of that comes with experimentation and also depends greatly on how you want to structure your projects. Myself I almost always lean towards 1 env per project.