Before giving up completly on the distributed application model I investigated PHPfog to see if it could help where Heroku failed. The description of their services sounds wonderful and exactly what I would need, basically an abstracted PHP environment distributed ontop of an Amazon Cloud EC2 backbone. However, when I created a test application in their "shared cloud" environment it failed to ever complete its initial configuration. So, yeah, its broken! lol
All of this effort and time investigating distributed applications was really just my typical "path of least resistance" mentality and my general fear of maintaining Linux servers. However, it simply cannot be avoided. The level of control and removal of the "middle man" makes the best financial sense and leaves me with the most control over my application.
So back to the Amazon AWS services I went to investigate topologies for my application. In my search I found this very useful link describing the implementation of a Facebook stack right in the AWS Dashboard: http://aws.amazon.com/articles/1044
This page shows the ideal topology for a Facebook app:
Looking at this picture made me realize a fundamental flaw in how I delivered Cruise Time. Cruise Time operated on a single EC2 instance which had the PHP application and executable .SWF file on it. As the game grew we only increased the size of the ECU to scale to demand. Since the game peaked at only 125,000 users it never stressed out the single EC instance.
To distribute this across many multiples of EC2 instances in a high traffic situation would require the entire EC2 image to be saved as AMI and allowed to scale within the Auto Scaling Group in the picture above.
So the new approach would have to divorce as much as possible from the scalable EC2 instances so they can be scaled on demand and put the deliverables off in their own space. That's S3 in Amazon parlance, their file storage cloud. Putting music files, the game executable, and other data files on S3 would allow the PHP application to swing freely with scalable demand while reading the executable from S3 at a known location.
What this does is allows me to push new code changes in the EXE/SWF straight to S3 without having to go and modify the AMI for the EC2 instances or some other crazy live-update scheme on running EC2 instances of the application.
The down side is that this is not true for the PHP application. Any changes to the PHP application WOULD necessitate an update to the AMI. So now the problem becomes: how do I make the PHP application dynamic enough that changing it wont cause a lot of AMI updates or downtime on the app?
Ah the joys of software design :)
ECU is not mentioned in the article. What is that acronym? Also can you explain some of these terms in layman language?
ReplyDeleteThis does not compute at all from that article:
The beauty about this cloud architecture is that it will automatically scale and add more Amazon EC2 Instances when your traffic is high and also maintain a minimum number of EC2 fleet size (Min size set to 1) and launch new instances in case of the instance failed.
So what is an EC2 Instance? An Instance of what? The data created by the flash.swf ? The flash.swf itself?
Also, I thought Amazon cost. Or is it free if your user base creating these instances is small.
Test post
ReplyDeleteAh finally! I can post! Was having the weird posting problem... Anyway...
ReplyDeleteAn ECU is a "computing unit" in the cloud and typical holds an image of a "server." For me I run Ubuntu AMI's on Amazon cloud with a LAMP stack installed (PHP, MySQL, Linux).
Amazon is not free but very cheap! Running the old sandbox for months cost like $17 over that period... You pay what you use so the payment scales as your app grows or diminishes..
On, as to what Heroku where it is free unless you get thousands of hits?
ReplyDeleteSo it's not very hard to set up a server unit? Having a rough time grasping this.
This is how simple I think... I have a server called erickinkead dot com.
on there is index.html.
in index.html is some javascript that calls MyProgram.swf
How do I take that and grasp it for facebook? What are these extra server steps, and how come I can't just tell facebook, "hey MyProgram.swf dudes!!"
Facebook runs your app within an ifrmae on their site that communicates to your private server at your canvas URL... Where your app lives is totally up to you.
ReplyDeleteHeroku makes it easy by giving you a url to your "App" without you havin to run any physical or even virtual servers. It's all "magic."
Amazon is just a way to launch virtual servers that you can then install linux, then apache, then php on so when you post your index.php like the code at: http://dracossoftware.blogspot.com/2011/10/heroku-facebook-php-canvas-app.html it will work.
You, the user, are now in charge of maintaining the virtual server making/installing all of the software and managing the ip address and URLs necessary so Facebook can find it.
Whereas with Heroku you just throw your code out at myapp.herokuapps.com and BAM it magically works.
Hmmm... Since I am going to just do pushes and not keep track of user data, I am thinking I should just go magic and not maintain a server. (I take it this is why you are going the more techie route, to maintain gobs of player data)
ReplyDeleteIf you never need to access a database.. I would rock it with Heroku for serious...
ReplyDelete