100098232 – Zachary Borrelli
The Social Llama
Our application, The Social Llama, is a Facebook style social system that uses several components linked together to create a distributed system. We have utilised several cloud technologies to provide a consistent web based system that can be centralised around a single point.
We started our system using the recommended components to store data and run the processing behind the scenes. After attempting this for a while we discussed with fellow peers about the idea of using Google’s cloud services to power the system. We took time out to go over Google’s services and agreed that it would be beneficial to our system to move to said provider. There were a few problems with getting the Google products off the ground as they wanted pricing plans sorted out before we could go any further, this took time. Then after it was setup we had to integrate the Google services into our app engine instance, this again took a little while as I feel the integration process is too convoluted, this would be one of the reasons that we would switch to another service in the future.
We chose to use eclipse as our IDE as it was the better of the ones we identified, its powerful Java capabilities and Google app engine integration made the choice easy for us. As stated, we opted to run with Java as the chosen coding language. This was the best language for us as we had some past knowledge to get us going with the programming and the code was best suited for Google app engine. Using examples set in class we built the base of our application. In addition to the java the made the main part of our application up we used CSS to create the look and feel of the application. CSS is a robust language that translates well to every web situation and we knew it would be the best choice for us to get across our application.
To get the application off the ground, we performed some extreme/agile programming which benefitted everyone as it helped get the infrastructure across to the group. As we all contributed ideas and helped each other understand the code as it was going into the system it made sure we got the best start and base to progress the system along.
For a user to sign up to our site we decided to make it utilise Google’s account sign up for ease of use as it was already integrated into the app engine and we’d seen examples within the module. To process when a new member signed in and interacted with something in the backend, Google cloud SQL was used. This was as system which put all database interaction up into the cloud to keep us from doing it in locally. After setting this up we immediately saw the benefits that having this part of the system happens within the cloud, it easily fit into the Google app engine’s infrastructure and worked straight away. This made our application easy to manage and robust as it was all through Google’s system, nothing else was in the way to create any incompatibility issues. The one problem with using these services is that they are costly; we could have achieved the same using local database implementations. On top of Google Cloud SQL we used Google Cloud storage for the storage of pictures and other media as SQL cannot hold these values. This put another part of our system up into the cloud, as it was another Google service it integrated nicely into application. A disadvantage of Google’s cloud services is that they operate on a public model so none