Summary - HiOAstudent.cs.hioa.no/hovedprosjekter/data/2010/11/prosjek… · Web viewOle also has experience from both a developer and application architect perspective at ... Web-based

Cloud Computing Vendor Comparison

Bachelor thesis report

Bachelor thesis, Accenture and Oslo University College

May 2010


-Page intentionally blank-

ii Cloud Computing Vendor Comparison


Table of Contents

1 Summary.............................................................................................................................................1

2 Preface.................................................................................................................................................2

3 Introduction.........................................................................................................................................3

3.1 The group.....................................................................................................................................3

3.2 Employer......................................................................................................................................3

3.3 Assignment description...............................................................................................................4

3.4 Goals of this thesis.......................................................................................................................4

3.5 Why this assignment?..................................................................................................................5

4 The reports..........................................................................................................................................6

5 Project management.........................................................................................................................85

5.1 Short description, tools and technologies.................................................................................85

5.2 Project management tools.........................................................................................................87

5.2.1 Google Docs.......................................................................................................................87

5.2.2 Microsoft Project...............................................................................................................88

5.2.3 Self-developed tools..........................................................................................................88

5.3 Product requirements and its meaning.....................................................................................91

5.4 Working locations......................................................................................................................91

5.5 Communication.........................................................................................................................92

5.6 Documentation..........................................................................................................................92

5.6.1 Log.....................................................................................................................................93

5.6.2 Status reports....................................................................................................................93

6 Project development.........................................................................................................................94

6.1 Creating a project home page....................................................................................................94

6.2 Local project server...................................................................................................................94

6.3 Finishing up the first phase........................................................................................................94

6.4 Planning the application............................................................................................................95

6.5 Developing the application........................................................................................................96

6.6 Planning the tests......................................................................................................................98

Cloud Computing Vendor Comparison iii


6.7 Running the tests.......................................................................................................................98

6.8 Wrapping it all up......................................................................................................................99

7 Epilogue...........................................................................................................................................100

7.1 Letter from Accenture.............................................................................................................100

Til den det måtte gjelde...........................................................................................................................100

7.2 Special thanks to......................................................................................................................101

7.3 Conclusion...............................................................................................................................101

7.4 Final thoughts..........................................................................................................................101

iv Cloud Computing Vendor Comparison



Cloud Computing Vendor Comparison v



vi Cloud Computing Vendor Comparison


1 SummaryThis project is our bachelor thesis at Oslo University College, spring of 2010. The assignment is given by Accenture.

What we have done is comparing three different Cloud Computing vendors with respect to development, scalability/performance and pricing. The result of this thesis shall provide general information regarding Cloud Computing, hands on experience with development on the vendors’ platform, explain typical problems you can run into and answer the question: do the platforms fulfill their expectations?

Cloud Computing Vendor Comparison 1


2 PrefaceIn this report we will explain what we have done, how we have worked, which tools we have used and which technologies we've had to dig into. Later on, we will discuss what choices we have made throughout this project and take a look at how they have affected the projects outcome.

The report is intended for examiner and advisors, but can be read by others who find it interesting. It would be an advantage for the reader to have general knowledge within the field of information technology, this because the report contains technical terms and the reader would easier comprehend the context of the report.

Further on, this report is divided into several sections: The reports, Project management and Project development.

The reportsPresents the final product as given to our employer.

Project managementIntroduces tools and technologies we have used along with information regarding project management and how we have worked.

Project developmentThis chapter gives the reader an insight to the progress of the project.

A dictionary is included as an attachment so the reader can look up progress-related, technical terms and phrases as well as abbreviations, which are used in this report.

Also in the attachments section the reader will find all the extra documents that are not integrated in this report. This includes Technical reference, Product requirements, Pre-project report, Status reports, Log and the Project plan, in that order.

We would like to thank our advisors Ole B. Hansen and Eva Hadler Vihovde for all their help and constructive criticism throughout this project.

This report is optimized for A4 white paper and should be printed in colors.

2 Cloud Computing Vendor Comparison


3 IntroductionThis introduction contains some background information about the project and a similar introduction can also be found in the product requirements and the pre-project report. We'll start off with who we are, a short note about our employer, before going more deep into the assignment and its goals.

Throughout this document we have used these abbreviations:

Google App Engine - GAE Amazon Web Services - AWS Azure Platform - Azure Cloud computing - CC Database accessing layer - DAL Graphical User Interface - GUI

3.1 The groupThe group consisted of Harald B. Kleppe, Hans R. Løvland and Karl Gustav Røksund.All group members knew each other from earlier projects and assignments at HiO, and knew what to expect from one another. When we formed this group we knew that we could expect a great group dynamic, good communication within the group and a corresponding level of ambitions.

3.2 EmployerThe employer and customer for this bachelor thesis is Accenture Norway. Accenture is a consulting and outsourcing company with more than 170,000 employees globally.

Our technical advisor, Ole Hansen is a Senior System Analyst at Accenture, and is leading the ”emerging” capability. In this capacity, he has a great interest in measurable and hands-on experiences with the different vendors of cloud computing. Ole also has experience from both a developer and application architect perspective at various large projects. Thus he is well equipped to act as the project advisor in as well as the commissioning party.



3.3 Assignment descriptionThe assignment itself was defined pretty much from top to bottom when received from employer and is basically an analysis assignment with a smaller programming part.

What we’ve done is that we have developed a Proof of Concept (PoC) application, which was deployed on different cloud computing platforms. The PoC application simulated an online ticketstore.

Along the way we produced reports on how we have experienced development of the PoC application, migrating it and testing it.

Since this assignment has several separate phases, it was divided into three parts. Each part concluded in a report, and these reports is the conclusive product handed in to our employer.

Part 1: Getting to know Cloud Computing, the three different vendors and do a comparison of the vendors with advantages/drawbacks and pricing in focus. This comparison was based on information we gathered through the first phase.

Part 2: Develop the PoC application on one CC vendor and then migrate it to the two others. This report contained hands on experiences, problems we've encountered, solutions we've found, pitfalls, lessons learned with the different CC vendors.

Part 3: Test the PoC application on the different CC vendors, with different test-scenarios/intensity and then write a report with results/graphs and conclusions of what we've come up with.

The three parts are explained more deeply in the attached product requirements and can be fully read in chapter 4 “The reports”.

3.4 Goals of this thesisThe goal of this thesis is to compare different cloud computing vendors. Cloud Computing is an area of focus for Accenture, and want practical experience with the utilization of these platforms on a real application. Our final product to Accenture will be reports containing information about different possibilities of the platforms, development factors, how they perform, scale and how their pricing schemes compare. The application we develop are in other words just a tool we will use to compare these platforms, and not itself the goal of the thesis.

To differentiate the stages in the thesis, it will be split into three parts. Where each goes in depth of different aspects and end in a report.

The result of this thesis will be used as a in-depth resource internally at Accenture to take more educated decisions while choosing cloud computing vendors. Accenture is a multinational corporation



and therefore it only makes sense to write everything in English to maximize its usefulness for the company as a whole.

3.5 Why this assignment?We agreed that we wanted something "more" than an assignment to develop a random web-application, and went on to look for an assignment which was a few steps away from ordinary.

Our reason to choose this assignment over any other was partially because Cloud Computing is a very "hot" and trendy in the it-world right now. The fact that it also is a less explored felt tempting. We was also appreciated that this assignment not only required brute programming skills but also analytical skills and abilities to see both opportunities and limitations in different aspects of the field. Both the opportunity and the possibility to make new discoveries urged us to want this thesis.



4 The reportsAs earlier mentioned, our final product delivered to our employer was three stand-alone reports regarding three different aspects of utilizing cloud computing. What we want to achieve by this chapter, is to present the final product as given to our employer. By reading the following chapters, the reader will easier comprehend and fully understand the usefulness of this project. We would like to remind the reader that the upcoming chapters are more advanced regarding technical terms, phrases and would require knowledge of basic information technology.

Further on, our final product is divided into three reports: Vendor analysis and comparison, Hands on development and Performance comparison.

Report part 1: Vendor analysis and comparison Introduces cloud computing in general, along with the three vendors and a comparison of them.

Report part 2: Hands on development Includes experiences, problems/solutions we encountered during the development phase of the project.

Report part 3: Performance comparison Presents the testing-phase with results/graphs from different test-scenarios. This part also includes thoughts and conclusions.

Each report can be read alone or all together.

Time wise part two and three each had double the amount of time spent on part one. The following reports are as they were when handed in to our employer.









5 Project managementWhat we want to achieve by this chapter, is to give the reader an introduction to what tools and technologies we have used throughout this project and how we've utilized them. Also, we want to give the reader general insight into how we have worked, physical working conditions and communication within the group and between us and our internal and external advisors.

5.1 Short description, tools and technologiesA whole lot of the tools and technologies we used in this project were new to us. That is why we've included a short description of all the tools we've used. Because we do not have a product-documentation, we decided that tools which were used during development will also be described here along with tools used for project management.

Java - is a programming language. The language derives much of its syntax from C and C++ but has a simpler object model and fewer low-level facilities.1 We've developed our test application using Java as programming language. This is better explained in report part 2. We were introduced to Java in the first semester at our school.

PHP - is a widely used, general-purpose scripting language that was originally designed for web development to produce dynamic web pages.2

Because PHP is fast, easy to utilize and all the group members had general PHP knowledge, the project homepage was written in PHP. More on this in the “Project development” chapter.

MySQL - is a free relational database management system.3

This database solution has been utilized several places, project homepage and the applications logic layer for Amazon to name a few. For further understanding, please read report part 2.

Eclipse - is a multi-language software development platform. It is written primarily in Java and can be used to develop applications in Java and, by means of various plug-ins, other languages including C, C++, COBOL, Python, Perl and PHP.4

1 http://en.wikipedia.org/wiki/Java_%28programming_language%292 http://en.wikipedia.org/wiki/PHP3 http://en.wikipedia.org/wiki/Mysql 4 http://en.wikipedia.org/wiki/Eclipse_%28software%29



As development environment, Eclipse has been used a lot in this project. We were introduced to this program in the first semester at our school and it has been used frequently since then. More on eclipse and why we used it is better explained in report part 2.

JSF 2.0 (JavaServer Faces 2.0) - is a Java-based Web application framework intended to simplify development integration of web-based user interfaces.5

RESTful (Representational State Transfer) - is a style of software architecture for distributed hypermedia systems such as the World Wide Web.6

RESTlet 2.0 - is a lightweight, comprehensive, open source REST framework for the Java platform.7

MVN (Maven2) - is a software tool for Java project management and build automation.8

SVN (Subversion) - is a revision control system. Developers use Subversion to maintain current and historical versions of files such as source code, web pages, and documentation.9

Skype - is a software application that allows users to make voice calls and chat over the Internet.10

Google Docs - is a free, Web-based word processor, spreadsheet, presentation, form, and data storage service offered by Google. It allows users to create and edit documents online while collaborating in real-time with other users.11

Microsoft Project - is a project management software program, which is designed to assist project managers in developing plans, assigning resources to tasks, tracking progress, managing budgets and analyzing workloads.12

5 http://en.wikipedia.org/wiki/JavaServer_Faces6 http://en.wikipedia.org/wiki/RESTful7 http://en.wikipedia.org/wiki/Restlet 8 http://en.wikipedia.org/wiki/Apache_Maven 9 http://en.wikipedia.org/wiki/Apache_Subversion 10 http://en.wikipedia.org/wiki/Skype 11 http://en.wikipedia.org/wiki/Google_docs 12 http://en.wikipedia.org/wiki/Microsoft_project



5.2 Project management toolsMainly we have used two different project management tools for this project, along with two self-developed tools located at project homepage.

5.2.1 Google DocsGoogle Docs has been our online sharing and working portal for all non-code related documents. It has allowed us to work together easily even when we were not in the same cities. All our documents/files were also read-writeable by our advisors at all times, which integrated them to the project on a higher level. A short note on what Google Docs is about can be found in the previous chapter.

Picture above: Google Docs overview.



5.2.2 Microsoft ProjectMicrosoft Project being the other project management tool, creating the project schedule was an easy fix. Microsoft Project has a lot of functionalities regarding project planning and is quite easy to use. Originally three drafts were made on a three months time-span before landing on the final project schedule.

Picture above: Latest project schedule

5.2.3 Self-developed toolsAs mentioned earlier, our project homepage tools were frequently used. Other than having general information regarding the thesis, our project site also had work-hour registration with "What have you done today" information field (diary/log), to do lists and a file-upload function. The group members wrote in the log every workday and the log is to be found in the attachments. Also the to-do list was frequently used, which helped us keep track of things we needed to do.



Picture above: Log, hour registration



Picture above: Log, hour overview



Picture above: To-do list overview

5.3 Product requirements and its meaningWhen we got the assignment from our employer it already contained a large segment of guidelines. When we wrote the product requirements we formalized these guidelines into one document, and decided how to proceed where it was up to us to decide.

The product requirements meant a lot to us when troubling through the developing phase of the project. Please read the “Project development” chapter to see why. The requirements of the application listed in the product requirements almost became a to-do list for us, and was very helpful when designing the application.

5.4 Working locationsFrom project start, we wanted a structural working environment. What we wanted was to have a default working location and regular working hours.

We decided that our regular working hours was going to be 8 hours a day, Monday through Wednesday. The reason we landed on these three days was because the group members had part time jobs on Thursday and other school activity on Friday.

Since our employer did have a lot of office space, we were offered our own desks at their location. In the beginning this seemed like a great solution, working close by our external advisor and other IT consultants.



Because our employer is a larger international company with over 170 000 people, they have multiple Internet proxies and servers in different countries working together to make it easier for support desk and maintenance to get overview and control. This also means that the Internet can run pretty slow when every request has to go through 5 countries before reaching its destination.

We recorded 21 hops from our employers’ office to a national newspaper site, visiting countries like Spain, Netherlands and England before reaching its goal in Norway. This complex proxy/Internet solution really did not work for us when we reached our second phase in the project. Deploying code to the vendors was extremely slow and sometimes impossible. So we had to find another working-environment solution.

What we ended up with was working two days a week at the school, and the last day at our employers’ office. This was most definitely the best solution for us because we then got to have regular meetings with our internal advisor at school and our external advisor at his office. This way we didn't lose any time travelling to other locations to have meetings.

Almost every piece of this project was done together while working at the same location. It meant a lot to this projects outcome that we were able to have face to face discussions regarding problems and solutions at almost all times, rather than having discussions over e-mail or chat-services.

5.5 CommunicationThe internal group communication has been oral while working together at the same locations. Due to illness or other reasons for project absence, chat-services or text messages has been used to keep communication flowing.

To-do list and log function located at project homepage has been used to keep track of what has been done and what we've had to do. These tools have concluded to better workflow internally in the group while in absence of the project or not.

The communication between the group and employer has gone through our external advisor and was done on several "channels": text messages, e-mail and chat-services along with a regular meeting every week. Text-messages and chat-services was used when needing immediate answers while working, all though these "channels" are hard to document. That is why it was important to our employer and us that status reports was handed in before the regular meeting every week, to document what decisions we had made, what we were working on right now and what we were going to work on next week.

5.6 DocumentationBecause of final documentation and to follow up on progression, we have written weekly status reports along with daily log. Every report has been written using Google Docs and then finalized in Microsoft Word at the end of the project. All status reports and log can be found in the Attachments.



5.6.1 Log The log has been used to keep track of who did what, when and also helpful to even out total number of working hours internally in the group.

5.6.2 Status reports These reports have been important when it comes to documenting choices, problems and every week’s current project status.



6 Project developmentSince we have no separate progress report, the following chapters will give the reader a better understanding of the decisions we’ve made and our progress throughout this project. Please note that some of the chapters are explained on a more technical level in their respective reports.

6.1 Creating a project home pageIt was a requirement from the school that we needed to have a thesis homepage. We were all familiar with PHP, so we decided to write a simple homepage in PHP using SQLite as a relational database solution.

We agreed that the project page should have these functionalities:

An overview of what the thesis was about. Time consumption log - a log of how many hours we used on the project and what we used

them on. Log - a day by day log. ToDo - a list of current objects that needs completion. Files - somewhere we were going to upload documents/files we made for the project.

Later we realized that we didn’t need the upload and day- by day log functions. Time consumption log (later named just log) and weekly status reports were enough to cover what we’ve done on a day to day basis.

The project site was hosted on a private web hosting provider.

6.2 Local project serverAt project start we were initially thinking about running the tests from our school. For this purpose we got a dedicated server on the school premises. This machine was never used for testing because of old hardware. Instead we used it to centralize development code through SVN and to keep test results. Every night this server was backed up by one of the group members’ server in another town to prevent data loss.

6.3 Finishing up the first phaseThe first report “Vendor analysis and comparison” was finished in late January and handed in according to schedule. As mentioned in the preface of “The reports” chapter, this part was not the most time consuming. Because this phase was mainly just research, we didn’t experience any major problems or delays. But after this research phase, we kind of got a feeling that we were going to regret choosing Windows Azure Platform as our third cloud vendor because of the complexity and lack of information available.



6.4 Planning the applicationPlanning the Proof of Concept application was scheduled to be done in 2 weeks according to the final project plan. This did not happen. We ran into a lot of unexpected problems, mainly that it was more difficult to find frameworks that worked on all the three vendors. This topic is better explained in report part 2.

When reaching the development phase we also discovered that designing the application itself was a bigger job than expected. A lot of functionalities had to be integrated and at the time not knowing how to write a basic webpage using Java Server Pages didn’t help either.


Use case diagram


Application GUI and data-flow

Another tough job was designing the application in a RESTful manner. This meant dividing the application into two separate layers and loosely couple them together. It took some time to structurally get this to work as one application. Fortunately as the picture above shows, human computer interaction (GUI design) was a low priority since mostly scripts and test-functionality were using the application.



RESTful design. (BLL being business logic layer, which is DAL)

We were a week behind schedule before we actually started writing any code at all. This meant extra work hours trying to catch up with the project plan.

6.5 Developing the applicationAs we briefly mentioned in the chapter above; we had almost no experience developing with JSP and since many of the frameworks built for GUI is based on JSP and its structure, we had to study.

In the beginning developing became a lot of testing and failing, but after a while of tumbling in the dark our learning curve drastically rose and we realized we had a lot of work to do in a already tight schedule.

Because we had a lot of technologies and stuff to dig into, we split up working on three different parts of the application. One working on the front-end GUI part using JSF, another learning to use RESTlet and creating the back-end DAL layer, and then third group member focusing on the communication between the splitted application using REST and JSON. Looking back, this decision was a very good idea and we probably would not have finished in time if we hadn’t split up like this.



After discovering many of App Engines unexplainable error messages, we finally finished the application for the first cloud vendor (Google). Surprisingly we were a little bit closer catching up with the project schedule, but not for long. It turned out that our application was using Google’s BigTable database solution in a very ineffective way, draining CPU power and a giving our application a major bottleneck. More on this, please read report part 2.

Since we already were behind schedule, two of us moved on trying to migrate the application to the two other cloud vendors while the third group member were trying to optimize and find a solution to this database problem.

With a little bit of luck and a lot of reading and testing, our application was finally working as planned on the first cloud vendor. Please see report part 2 for solution. We were on a lucky streak when migrating to the second vendor (Amazon). Planning the application with migrating in mind paid off. Re-writing the database methods to communicate with MySQL were surprisingly easy, and the application was up and running in no time.

Unfortunately our luck ran out while trying to get the application working on the third vendor (Microsoft). We partially got the back-end DAL application up and running, but the database solution was unstable and not working. Due to even more complications with the front-end GUI working on Azure, we decided to drop Windows Azure for further development and testing. For technical reasons and further explanation, please read report part 2.

Now because we were already far enough behind schedule, looking back we see that dropping Windows Azure was the right decision. When we finally were ready for the testing phase, we were about 2 weeks behind schedule and we had dropped one of the three vendors for testing. It felt like we had seen every error message the different platforms had to offer. Lesson learned; never give up!

Report part 2 was just a bunch of keywords during the development phase and was completely re-written right before we started the testing phase of the project. Because developing the application and then migrating it took a lot more time and was a more complex process then we originally planned for, our employer received this report later than expected, but in return the report was a loaded with useful information.

To draw a full week-to-week picture of the development phase, please read status report week 6 till 12.



6.6 Planning the testsWe are reaching the middle of April and as mentioned above, we’re 2 weeks behind schedule which means we have to be very effective. Of course a new project phase means new technology, new problems /solutions and another report. What they have in common is time-consumption.

Beginning this phase several questions were running through our minds; how are we going to run the test? How are we going to compare them? What test scenario would be most realistic and fair?

While we’re trying to come up with good solutions to all our questions, we also had to read up on JMeter which we found out was the best tool for testing the application. For information on why and how please read report part 3. Furthermore we had to find a neutral place to run the tests from. We decided to use Rackspace Cloud servers, since it’s an infrastructure as a service much like Amazon EC2, which is perfect for running JMeter and the tests. Also we already knew some about this vendor from the research phase of our project.

We decided to make one test scenario and then run this test on different levels of intensity to see how the cloud vendors scaled. The reason we only made one scenario was because of the lack of time we had left. We figured we were going to get much more information out of one scenario running on multiple intensity levels rather than several scenarios running on few intensity levels.

Later on, we saw that a lot of the functionalities we had included in the application weren’t going to be used when running the tests. This meant that if we had focused developing a simpler application, we would probably have more time doing the actual testing of the clouds.

For specific details regarding the scenario, please read report part 3.

6.7 Running the testsAs you might have guessed, running the actual tests became a background process. Preparing for testing, gathering information, test-files and graphs before and after the tests was not. While the tests were running we were writing reports and generally documenting the project. Report part 3 gradually took shape as the tests were finishing up.

After we had all the test results we needed, we ran into a problem. Getting something useful out of an over 300MB XML test-file was easier said than done. While we delegated a group member and a 16GB of RAM server to crunch the massive text file, the two other group members focused on documentation.

Luckily the student and the machine together were able to pull out some useful results and finish up report part 3.

The hindsight of this phase tells us that we should have spent more time testing to get an even better picture of how the different cloud vendors scales. Please read report part 3 for a more detailed and technical understanding of this and previous chapter.



6.8 Wrapping it all up The last two weeks of May was used primarily to document the project. A lot of things needed to get done like final adjustments of the three reports and finishing up all parts of the documentation. These weeks went by extremely fast and we barely finished everything before sending the project in for printing.



7 EpilogueWith this final chapter, we want ease the reader’s mind and follow up with a project ending. First off we will include the letter our employer gave to us at project end, and then we would like to thanks the people who helped us during this project. Finalizing this project, a conclusion and our final thoughts of this project have been included.

7.1 Letter from AccentureTil den det måtte gjelde

Jeg har vinter og vår 2010 hatt gleden av å være oppdragsgiver og veileder for en gruppe på 3 studenter fra Høyskolen i Oslo.

Prosjektet har i hovedsak bestått av utforskning og dokumentasjon av ”Cloud Computing” konsepter med utgangspunkt i en webapplikasjon. Utgangspunktet var en løsningsbeskrivelse av applikasjonen og innspill til forskjellige aspekter som burde belyses. Studentene har laget applikasjonen og 3 rapporter; vurdering av ulike leverandører basert på markedsføring/åpen informasjon, erfaringer og vurdering av praktisk utvikling og til slutt en ytelsestest med kommentarer, som vurderer praktisk bruk av den ferdige applikasjonen.

Harald Kleppe, Hans Løvland og Karl Gustav Røksund har alle utvist stor stå-på vilje under prosjektet. De har jobbet med relativt ny teknologi for markedet, som Cloud Computing er. I tillegg har de fleste verktøyene og rammeverkene som er benyttet vært nytt for studentene. En fellesnevner er derfor at dette ikke har vært noen enkelt prosjekt der man kan hvile på tidligere prestasjoner og gammel rutine.

Gruppen har klart å organisere og styre prosjektet godt og har underveis kommunisert utfordringer og status på en fornuftig måte. De har også klart å tilpasse seg dynamikken i et realistisk prosjekt der uforutsette problemstillinger dukker opp, og man må skyve om på den opprinnelige planen. Gjennomføringen har vært preget av fleksible og pragmatiske gruppemedlemmer som ser løsinger og alternativer fremfor å gi opp, eller forvente at oppdragsgiver/veileder ”ordner opp”.

Studentene har levert det ønskede produktet og jeg ser på det som nyttig for bedriften. Det vil forholdsvis kort tid etter at denne oppgaven er levert bli startet et nytt prosjekt som benytter kompetansen som nå er opparbeidet som utgangspunkt for en effektiv oppstart.

__________________________Ole HansenSenior Systems Analyst, Accenture



7.2 Special thanks toEva Hadler Vihovde for providing feedback and guidance on documentation and progress of the project throughout the period. Evas experiences in working with this type of guidance from previous years have proved to be very useful for our implementation of the project.

Ole B. Hansen for being our technical advisor at Accenture. Oles experience both as developer and application architect have been invaluable for our project. His interest and constructive critisism have driven our work forward in a healthy and effective way.

Lars M. Klavenes for creating project logo and giving us layout tips.

Printing office at Accenture for printing our project and its reports.

Commissioning party for giving us the opportunity to dig into cloud computing and its technology.

7.3 ConclusionWe believe both AWS and GAE are good platforms, but we also believe we have uncovered many potential pitfalls for those who are going ahead and utilizing these platforms. Running Java within Windows Azure on the other hand is not ready for a production environment from our point of view.

In a hindsight we do believe that we could have found even more valuable results in Part 3 if the thesis was structured with less focus on the application and more on actually testing platforms. We believe that the results of the tests would have been equally relevant with a simpler application that would allow more time to be spent on testing.

7.4 Final thoughtsWorking on this project has been very educational for us. Both in terms of the size of the project and not least the fact that we have been able to work with exciting technology in a segment that is as fashionable as cloud computing is these days. We have obtained knowledge about both specific cloud computing vendors and cloud computing in general.

This is knowledge we certainly will carry with us to further studies and into future employments.





Documents

Summary - HiOAstudent.cs.hioa.no/hovedprosjekter/data/2010/11/prosjek… · Web viewOle also has experience from both a developer and application architect perspective at ... Web-based