Re: Evaluating SC and trying to see how I can do this deployment…
Hi Chris,
I am going to give you my 2-cents worth of advice, as I have developed a system for companies where I too had a unique filesystem install and database and subdomain for each company who uses my service. It has been working flawlessly, but I have nevertheless been working for months on a different approach. As soon as I can get mine completed, I will slowly migrate all my sites over. Here is my experience:
I too have something like company A paying $20 / month for a “site”, company B another site, etc. I know python and used that language on my hosted server to copy each site’s filesystem from a special install/version2.3 folder, etc. Just a straight copy. But each site had some configuration - DB name, DB password, initial admin user/passwed, site name, etc. I had a config file that I would copy and then use Python to insert or overwrite certain lines, like a pattern replace function. Then used python and my hosting services API to create a DB, populated it with some basic data, etc. Then the same API to create a subdomain. All works great - no chance of one site polluting or corrupting another, plus sites (filesystem) could be spread out over multiple servers - which I do use 3 right now for about 45 sites. Loads are all great.
The downside: The biggest issues are patching bugs and doing upgrades. It turns out that is a BIG pain in the ass, with so many file systems. I automated that too, but the problem becomes hard to manage. Also, when you upgrade, say, one of the php files for a particular grid or form, then you may have to (my biggest fear) change the database schema. Now these are all on “running” sites. So you never do anything till you develop on a development filesystem/database - then move to a testing filesyatem/database - and finally deploy to production. You have to make tons of backups for all filesystems and databases before doing ANYTHING, no matter how much you test. THERE WILL BE PROBLEMS 5% of the time, so you have to be able to roll back both.
Second downside is just sheer number of backups that stack up. How to management that? I have scripts that log into a system database everything my scripts do (upgrades, etc) then make filesystem backups and database dumps. That is all at 1am every night. I have been very lucky and have not had to do much with the backups, but if you don;t do it, it is 110% sure you will need it…
So my solution - I am redoing my entire scheme to have a single large MYSQL database, with a siteID field in almost all my tables. So the SQL SELECTs have to filter on siteID on most pages, so that a user on a subdomain only ever knows there is their own site. Me or other admin can have a different interface that lets us see all tables for sites, etc.
Scalability - there are lots of ways to scale up for higher demand websites. Be on better server, have multiple front ends feeding off one DB, etc. I would rather tackle those issues than the way I spread them across multiple servers.
The main tricky thing for me is that I have what I call “teams”, which a team leader (a registered user who agrees to pay and be responsible, etc) can create one or more teams and invite user to join one or more teams. Teams then have ability to work on one or more sites. That may be way more than you need, but in my business model for my application, it will be terrific for the customers.
I am evaling SC right now and am 99% sure I will use it to be a the core of my systems, as it seems to have really create custom scripting system. I need lots of that for my logic. But SC has the BEST grids/PDF/print/export stuff built in I have ever seen. That saves me tons of time over how I coded stuff before. I also have used another code system phpmaker, it was good but it is more primitive than SC IMHO.
So anyway, I hope that helps you a bit. Glad to answer any questions if I can help. MY advice if you are starting out is to go thru your list of features and decide on the smallest functional system you can start with. Program that with SC or whatever combination of tools you need, then deploy - get some users going, even if free beta users. Get soem feel for how running the site and upgrading and fixing bugs goes. Meanwhile, create the next iteration list of features for version 2, etc etc. Better to have 99% of a smaller feature set making some customers (and you) happy, than 45% of everything working - with unhappy people. Mostly it will be you.
Plus as you run a system, and users are actually using it, your whole scheme will probably morph. You can add all those cool ideas and focus on adding in new stuff, rather than reprogramming things you spent a lot of time on.
One last thing, read some of the books or the blog of Seth Godin - his books Tribes and Purple Cow are really good. Not technical, but about digital business schemes and ideas.
OK, one final last point, to you and anyone else out there - build your business systems into your programming. By that I mean, how do you handle and track 'returns" or refunds? Not by cell hone calls to you I hope. How do you know if someone has referred someone via a link? Viral marketing is key these days, so put that in. How about help and support. SC has this forum (I am working on one using SC for my system) , help docs, faqs, etc. Put all that in your system. People will not be impressed if you don’t have that at launch. I would almost build the help before I programmed everything. Users seem to barley be able to click a mouse out there - at least the ones that have questions. So have someone go thru it step by step and build the help. If you do it all yourself, it will be too technical.
Really, I am done now.
Peace,
Jamie
Nobody cares about what is behind a Facebook or Amazon web app anyway, just that it works well.