A Reference Architecture for Building Highly Available and Scalable Cloud Application

A Reference Architecture for Building Highly Available and Scalable Cloud Application Hassan Jamous International Master in Service Engineering (IMSE) University of Crete, University of Stuttgart and Tilburg University Tilburg, Netherlands hassan.jamous@gmail.com Abstract— Building a highly available and scalable web application is not an easy process. Developers should design the system to handle both expected and unexpected failures. Furthermore, the system should be scalable to meet the extra load that might happen. Building such an application using traditional web hosting is very costly, that is why entrepreneurs with new web application ideas start to build their applications on the cloud. This paper introduces a reference architecture and best practices to build highly available and scalable web applications on Amazon Cloud. A case study is used to validate the architecture and to illustrate how the best practices are implemented. Keywords—Amazon Cloud, Scalability, Availability I. INTRODUCTION In the last few years the world has seen many successful web application ideas, some of these applications, like Facebook and Twitter, have hundreds of millions of users all around the world. These success stories make entrepreneurs who have a new web application idea think about high scalability and availability when they want to build their applications in order to handle the large number of users and huge amount of data that might happen in the case that the idea achieves such levels of success. Entrepreneurs face a lot of challenges when they want to implement highly available and scalable web applications; some of these challenges are financial constraints and the lack of proper IT infrastructure [31]. However, with the birth of cloud computing and the payas-you-go concept entrepreneurs have more chances to build successful, highly available and scalable web applications at low cost [3]. This paper aims to help in building highly available and scalable web applications on cloud, it provides a reference architecture and best practices to take into consideration during the build of such an application. The paper starts by a brief Technical Background in section 2. The Research Methodology is detailed in section 3. Sections 4 and 5 are designated for the Qualitative Research. Sections 6 and 7 include an introduction to Amazon Cloud and introduce our reference architecture and best implementation practices. Section 8 includes the Experimental Study. Finally, we conclude and summarize Future Work in sections 9 and 10. II. TECHNICAL BACKGROUND “Cloud Computing refers to both the applications delivered as services over the Internet and the hardware and systems software in the datacenters that provide these services” [3]. The services are called Software as a Service (SaaS). The cloud is the name that is given to the hardware and software installed in the datacenter. The public cloud is available to users under the pay-as-you-go concept. The service that is being sold is called Utility Computing. The term Cloud Computing is given to the sum of SaaS and Utility Computing [3]. Service delivery in Cloud Computing comprises three different service models [4]: 1- Software-as-a-Service (SaaS) which provides fully fledged applications to a cloud„s end user and are mainly accessed through a web portal and service-oriented architecture based on web service technologies. 2- Platform-as-a-Service (PaaS) which provides the environment for developing and provisioning cloud applications. 3- Infrastructure-as-a-Service (IaaS) where the cloud provider supplies the resources (virtual machines, storage, firewalls, load balancers, etc.) to the customers for deploying the applications, the cloud users should install operating system images and maintain it themselves. The three service models are completed by an end user layer that encapsulates the end user perspective on cloud services. III. RESEARCH METHODOLOGY The paper raises the following question: How can a highly available and scalable web application be architected on Amazon Cloud? The paper starts by proofing the following hypothesis: building a highly available and scalable web application in the cloud follows the same architecture of building such an application using traditional web hosting or traditional machine-based infrastructure. To proof the hypothesis a qualitative study has been conducted to check the current successful highly available and scalable web applications on the cloud and comparing the current cloud architecture with the patterns that are used to build highly available and scalable architecture using traditional machinebased infrastructure. Based on that proof the paper introduces a reference architecture to build highly available and scalable web applications on Amazon Cloud, and suggests some best practices for building such an application. Proofing the reference architecture has been done by following the experimental method; the paper introduces a new web application idea that is implemented using the reference architecture and followed the suggested best practices. Performance tests were performed on the application to proof its ability to scale and being available in different circumstances. infrastructure is too complex and expensive. Servers have to be provisioned to the peak capacity, which leads to high upfront costs [3][33]. Cloud hosting companies provide a number of services which are ideal for entrepreneurs. Some of these services are: providing infinite resources on demand, no upfront commitment, clients can pay for resources on a short-term basis (e.g. processor by hour); Just-in-time Infrastructure, Auto-scaling, Disaster Recovery and Business Continuity [11]. With these services, building a new application becomes much easier, faster and cheaper. The next sections show how a highly available and scalable application can be implemented on the cloud. V. Fig. 1. Machine-based highly available and scalable web application IV. TRADITIONAL WEB HOSTING HIGHLY AVAILABLE AND SCALABLE ARCHITECTURE Many researchers have been working on different ways for building highly available and scalable applications [5][27]. “Fig.1,” depicts a highly available and scalable web application architecture that is widely used by multiple companies like Twitter [24], LinkedIn[19], eBay[19] and others [5][25][30]. “Fig. 1,” shows a typical three tier web application architecture, where the presentation tier is responsible for generating web pages, data validation, transforming data into the form that is acceptable by the application tier. The application tier is responsible for doing all calculations and validations. The data-tier is responsible for storing and managing data [6]. “Fig. 1,” also shows that the application is distributed among 2 regions; a DNS load balancer is used to distribute the load between regions. Caching servers, which can be considered as another tier, are used for improving performance [14][18]. Also, the use of a content delivery network CDN, such as Akamai and Limelight Networks, has potential benefits for delivering static content [1]. A cluster of load balancers is used between the presentation tier and application tier. Some architectures suggest using a single highly available load balancer but others emphasize having more than one load balancer to prevent a single point of failure [15]. “Fig. 1,” assumes that the data tier is designed as a Master-Slave and has an asynchronous replication among regions and synchronous replication among zones. In case of using a NoSql data store the data tier architecture will be different as there is no need for the synchronous replication any more [30]. Failures in this architecture are usually due to the hardware or operating system. High availability is achieved by redundancy where new servers should be added and database replication should be done. Scalability in this architecture can be achieved on each layer by adding additional host [25]. Implementing the architecture in “Fig. 1,” using traditional web hosting companies or traditional machine-based HIGHLY AVAILABLE AND SCALABLE WEB APPLICATION ON THE CLOUD Netflix, an on-demand streaming media over the internet company, uses Amazon cloud services; the architecture follows the three tier pattern [16]. Siddharth Anand, Cloud Architect at Netflix, focuses on the importance of setting up the application on multiple availability zones, the use of multiple regions for decreasing network latency and the use of CDN for static content and caching for reducing database requests [16]. In [26], Pinterest, an online web application which provides visual discovery tools where users can save and categorize their images, shows how Amazon Cloud is used to ensure availability and scalability. Pinterest has three tier architecture and uses multiple availability zones and regions. Rightscale, a professional company in the field of cloud management, shows in a number of white papers the reference architecture that they follow to build highly available and scalable cloud-based web applications for their customers. Rightscale uses two tier architecture (application and data), with installation in multiple areas in order to perform failover in case of an outage in one area. Rightscale indicates that a presentation layer can be added based on the customer case. Rightscale encourages the use of caching and CDN for improving performance [18]. In [32], IBM introduces a cloud reference architecture which also follows the architecture shown in “Fig. 1,”. Based on the mentioned cases and other cases (Ericsson, Expedia, Unilever, Sunpower, Outsmart [7]), we can conclude that a highly available and scalable web application on the cloud uses the same architecture that is used in traditional web hosting or machine-based infrastructure which proofs our hypothesis. Based on this proof the next section introduces a reference architecture for building highly available and scalable applications for Amazon Cloud. VI. BUILDING HIGHLY AVAILABLE AND SCALABLE WEB APPLICATION ON AMAZON CLOUD A. Introduction to Amazon Cloud Amazon Cloud or Amazon Web Services (AWS) provides a number of online services for web applications that are accessible over HTTP. All these services are billed on the payas-you-go concept. Amazon claims that it can provide large infrastructure faster and cheaper than the traditional hosting companies. AWS is located in multiple geographical “Regions”; each region has multiple "Availability Zones". Availability zones are located in different places in a region. Failure in one availability zone does not affect other zones. Amazon AWS provides more than 40 services; this paper covers the essential services for building highly available and scalable web applications. These services are [12]: 1- Amazon EC2 “Elastic Computing Cloud”: a web service that gives a resizable virtual machine in the cloud. EC2 users have control over the computing resources, they can scale the resource capacity up and down depending on their needs. 2- Amazon EBS “Elastic Block Store”: data on EC2 instances is not persistent when the instance is powered off and on (no problem with rebooting), EBS service provides a networked backed storage volume whose lifetime is independent from the EC2 instance it is attached to. The EBS storage can easily be detached from one instance to another in case of failure . 3- Amazon Route 53 *: a web service that is used for DNS resolution . 4- Amazon ELB “Elastic Load Balancing” *: a service used for load distribution across multiple Amazon EC2 instances. It automatically detects unhealthy instances and passes requests to the healthy ones. 5- Amazon S3 “Simple Storage Service” *: a service for storing and fetching any amount of data. With S3 there is no need for capacity planning, users can dump data at any time. 6- Amazon RDS “Relational Database Service”: a service which provides a managed relational database in the cloud. RDS provides an easy and cost effective way to operate and scale a relational database. 7- Amazon RDS Multi-AZ: with multi availability zone mode, RDS provisions the database across two availability zones, a master database in one zone and a slave replica in another zone. A synchronous replication will be done between the master and the slave. 8- Amazon DynamoDB *: high performance, fully managed, NoSql database service, which has low latency where the average read is less than 5ms, and the average write is less than 10 ms. 9- Amazon CloudWatch *: a monitoring service for AWS resources like EC2 and RDS. CloudWatch gives metrics like CPU utilization, disk utilization, network utilization. It generates input metrics for another service called Auto Scaling. 10- Amazon Auto Scaling *: a service for scaling capacity up and down in an easy way, users can define scaling conditions or let Auto Scaling takes inputs from CloudWatch. 11- Amazon SQS “Simple Queue Service” *: this service is essential for designing loosely coupled components, it gives a highly scalable and available fault tolerant queue, which is used to tie different pieces of distributed systems together . 12- Amazon CloudFront *: a content delivery service for content distribution in low latency and high transfer speed. 13- Amazon ElastiCache *: this service is used to cache information in-memory to be fetched without database access Services marked with * are inherently highly available and fault tolerant, there is no need to worry about managing either the infrastructures or the services to make it highly available, scalable or fault tolerant. The non-marked services provide tools and features that enable the customer to choose the right mix between fault tolerance and cost. In case the customer needs to build a low cost application and does not care about scalability or vice versa, these services provide the required tools to setup such an application [28]. B. Reference Architecture for Highly Available and Scalable Web Application on Amazon Cloud “Fig. 2,” depicts the architecture of highly available and scalable web applications on Amazon cloud. The architecture is based on the one shown in “Fig. 1,”. “Fig. 2,” shows the web application installed in 2 regions, in region 1 the application is installed in 2 availability zones. Amazon Route 53 is used to balance the load between the regions. Amazon CloudFront is used for content caching to decrease fetching content latency. Amazon ELB is used to distribute the load between availability zones. The presentation tier in each region is a cluster of EC2 servers with auto scaling service to scale up and down. Amazon ELB is used to balance the load that comes from the presentation tier to the application tier. The application tier is also a cluster of EC2 servers with auto scaling service. Amazon RDS service is used for Relational Database. The RDS is under the Availability zone mode which makes a master database in one zone and a slave one in another zone with synchronous replication. Amazon CloudWatch service is used for monitoring EC2 servers and RDS database. Amazon ElasticCache service is used for caching to reduce the number of database requests. Amazon S3 is used to store static contents and to save scheduled database backups. The RDS slave replica in region 2 periodically gets the latest backup in S3 to serve in case of region failover. The architecture shown in “Fig. 2,” is a reference architecture for building a highly scalable and available web application. VII. BEST PRACTICES FOR BUILDING HIGHLY AVAILABLE AND SCALABLE CLOUD BASED WEB APPLICATION ON AMAZON CLOUD 1) Start with single region and multiple zones For start-up projects, entrepreneurs can consider building their application in one Region, but they should always ensure to do the installation in multiple availability zones. Many companies like Netflix stopped working because of an outage in an availability zone [16][22][25]. 2) Amazon RDS & DynamoDB multiple regions installations RDS Multi-AZ service allows having a master/slave architecture where the data is synchronously copied to the slave. This service is available in the multi availability zone within one region and cannot be configured for multi regions. Lately, Amazon has provided a new service for MySql RDS, which is Read Replica; this service allows the customer to have up to 5 regions read replicas of MySql RDS master database. These replicas are updated asynchronously. With Read Replica service, the application which is installed in multiple regions can perform read operations on a local database and redirect the write operation to the master database. In the case of having multiple regions intensive read applications it is advisable to enable Read Replicas on these regions [12]. In the case of facing a problem in multi regions intensive write application, multi master database solution should be considered. Stateless services are services that do not keep any memory about what happens between requests [9]. Managing the application state is the key for having a reliable and scalable system [13]. Stateless services allow the routing of the request to any available running one, which allow easy scalability by adding extra machines with running services. Atomic services are services with fine granularity, Atomic service functionality cannot be logically split into other services [9][25]. Idempotent services are services that can be called multiple times without affecting the outcome [10][25]. Atomic and idempotent services are keys for handling fault tolerance and scalability, they allow the client to safely call them multiple times until achieving the right results [10][25]. Fig . 2. Highly Available and Scalable Web Application Architecture on Amazon Cloud Developers can use third party software for that, like tungsten. As with the DynamoDB service, the current service allows the installation of DynamoDB nodes in multiple availability zones within a region but not multiple regions [12]. One solution recommended by Amazon is to use the Data Pipeline service to periodically move data between DynamoDB tables across regions in order to achieve read replicas. This solution is good for read intensive applications. In the case of slow write operations, developers should develop their own solutions. 3) Divide the application tier’s EC2 servers into multiple types One of the good practices is to divide the application tier EC2 servers into multiple types. For example, Type 1 responsible for providing services 1,2,3 and Type 2 for service 4,5,6 and so on. This will allow customizing EC2 instances, for example, powerful machines for intensive processing services and ordinary machines for normal services (This advice has been taken from multiple cloud architects). ELB service does not allow to write routing logic, in the case of dividing the application tier to multiple types, a load balancer should be dedicated for each type [12]. Alternatively, a third party load balancer can be considered, like Haproxy and Nginx. In the case of having ELB for each type of service, the routing logic should be in the presentation tier, using other load balancers like Haproxy allows moving of the routing logic from the presentation tier to the load balancer itself as it is a Layer 7 load balancer [2]. We do recommend moving this logic of routing from the presentation tier. 4) Use the service if it is available, don't build your own solution If Amazon provides a service that meets your needs, it is better to use this service and not build your own solution. This best practice is one of the benefits of cloud computing which allows moving the risk of administering and managing infrastructure to the cloud provider [3]. 5) Stateless, Atomic and Idempotent services are keys for scalability 6) Divide the application tier into 2 levels, atomic and aggregator. Usually the web application needs to call multiple Atomic services in order to get a response, dividing the application tier into 2 levels, one that provides atomic services and another for aggregating these services to get a composite response is one of good practices [13], also it is very important for the aggregating service to be stateless to ensure scalability. Amazon SWS (simple workflow service) can help in building aggregating services. 7) Asynchronous messaging Asynchronous messaging is a key to ensure loose coupling [9].The highly distributed structure of cloud applications makes using asynchronous messaging essential to design independent components [9][25]. Consider using Asynchronous messaging for services that need a long time to be executed, Amazon SQS is a good choice when it comes to Asynchronous messaging. 8) Keep dynamic data closer to the compute and static data closer to the end-user [33] It is a good practice to use CDN to store static data that does not change a lot; this leads to reducing users‟ access latency. Also, it is better to import data that needs processing to the cloud, this will reduce the processing time and cost because cloud providers charge for the used bandwidth. VIII. CASE STUDY This section introduces Did You Know Encyclopedia “DYKE” as a case study which is a cloud based web application that is implemented based on the introduced reference architecture and best practices. DYKE is an easy and direct way to find verified facts. An example of a fact written in DYKE is: Did you know that: #IMSE is an international master program that takes place in #Stuttgart_University, #Tilburg_University and #University_of_Crete. Pressing on the IMSE hash tag for example gives the user more facts about IMSE. Normal users can vote for each fact, they can emphasize whether the fact is true or not. DYKE also provides special user accounts for organizations, universities, companies etc. With this account they can confirm fact written about them. DYKE is implemented on Amazon cloud. As the budget is limited, the start will be with building the application in one region and 2 availability zones ( best practice 1). DYKE will use two data stores, the first one for handling users‟ information (Amazon MySql RDS database with Multiple Availability Zones mode). Another datastore is required to part. Each test was repeated 10 times and the average results were introduced. Tests were run on one availability zone and US-EAST-1C Region. Fig. 3. DYKE Architecture store all facts; a NoSql database is chosen to store the facts as a dramatic increase is expected in the number of the written facts and the number of the site visitors. Based on best practice 4, Amazon DynamoDB is chosen to store the facts. Based on best practice 3, the application tier is divided into three types: Type 1 provides services related to users; it includes all services that need to interact with the MySql RDS datastore ( Login, Change Information, Verify User etc. ). Type 2 provides services that are related to facts, it includes all services that need to interact with the DynamoDB datastore (Read fact, Edit fact, Vote for fact, etc. ). Type 3 provides services that need intensive processing; an example could be a service that provides all facts based on input (all facts about animals). Also based on best practice 3, Haproxy will be used to route requests between the presentation tier and the application tier. All the services are stateless, atomic and idempotent (best practice 5) this will allow the application to scale easily. For now best practice 6 is not implemented; the current design of stateless and atomic services will allow adding this layer later. Best practice 7 will be taken into consideration; part of the DYKE content will be imported from different places (books, web, current encyclopedias, etc.) all these data will be imported to the cloud for processing. Using CDN has been taken into consideration but not implemented in the current version of DYKE as it is a little bit expensive. For the Type 3 services asynchronous messaging is used (best practice 7), this will allow handling the request when the server is not busy. Processing results will be stored in Amazon S3. “Fig. 3,” Shows DYKE architecture. A. Testing DYKE Availability and Scalability A number of test cases were designed and ran on DYKE. These test cases were launched against the related application 1) Unhealthy Machine Detection Test The test starts with one ELB, 2 EC2 instances and 10 requests per second. During the test one of the EC2 machines will be turned off. The test checks how much time it takes to route all requests to the healthy machine. the test runs on the EC2 cluster Type A and uses Micro EC2 instances. Test results in “Fig. 4.a,” shows that between second 40 and 50 EC2 machine2 is turned off, and between second 50 and 70 the number of requests to the first machine starts increasing, so ELB detects the failed instance in an interval of 20 seconds. 2) EC2 Servers Auto Scaling Test The test starts with a few requests per minute, and then this number increases to make the CPU usage of the server more than 80%. The test checks how much time it takes to start new EC2 server. The test runs on the EC2 cluster Type A and uses Micro EC2 instances. The Database size is fixed with 100 million records. CloudWatch is set to trigger after 5 minutes of 80% CPU usage. “Fig. 4.b,” depicts the CPU consumption every 30 seconds. The first red circle indicates the time when the EC2 instance CPU becomes more than 80%, the second circle indicate the time when another EC2 instance starts. This test shows that the required time to launch a new instance is about 11 minutes, this includes 5 minutes for CloudWatch to trigger. Also the test shows how Auto Scale functionality of EC2 servers makes the application highly available and scalable. 3) MySql RDS Scalability and Availability Test. This test checks how much time it takes for MySql RDS to scale up. The test pings the database every second to check if it is up or not. During the test the RDS instance will be scaled from a small machine to a bigger one. MySQL RDS with Multi-AZ mode with 100 million records is used for this test. The scale will be from the small instance category to the large one. “Fig. 4.c,” shows the test results; the line shows if there is a response from the RDS database or not, where the value 1 means there is a response and 0 no response. The figure plots the value every 10 seconds. As it is shown from second 40 to 100 there is no response from the RDS database. According to [12] this is not the scale time, this is the failover time from the master to slave instance. When a user scales an RDS instance, Amazon firstly scales the Slave, then it does the failover (the downtime), and finally it scales the master. More advanced RDS benchmarking have been done by researchers, which shows the scalability of RDS [20]. 4) Other Tests Testing other parts of the DYNK was not easy to be performed in order to get accurate results, this is due to the cost related to these tests. Other researchers have done similar tests that support the availability and scalability of our architecture and Amazon Cloud in general. For example, SQS benchmark [21][23], Amazon S3[23], Amazon EC2 [17][21], RDS [20][21], DynamoDB [8] and ELB scalability [21][29] IX. CONCLUSION The results of our qualitative study indicates that the Fig. 4. Test Results architecture of an application on cloud is similar to the one implemented on machine based infrastructure. The case study and the test cases shows the scalability and availability of the reference architecture and Amazon cloud. The reference architecture can be used not only on Amazon Cloud but on all other cloud providers like Microsoft Azure. A limitation in resources prevented us from developing a full test suite to cover all aspects of scalability and availability. We believe that the designed test cases and the referenced research study which show detailed performance test cases are good indicators of the scalability and availability of our reference architecture. X. FUTURE WORK This paper does not address the security aspect in the reference architecture and the cloud in general, which is a huge topic that we will work on in our future study. Validating the reference architecture with more case studies is also part of our future work in order to give more value to the architecture, as well as designing more intensive and detailed test cases. REFERENCES A.Vakali, and G.Pallis, “Content delivery networks: status and trends,” IEEE Internet Computing, pp. 68-74, November-December 2003. [2] J. Elson and J. Howell, “Handling flash crowds from your garage,” In USENIX 2008 Annual Technical Conference (ATC ‟08), pages 171– 184, Berkeley, CA, USA, USENIX Association , 2008. [3] M. Armbrust, A. Fox, R. Griffith, A. Joseph, R. Katz, A. Konwinski, G. Lee, D. Patterson, A. Rabkin, I. Stoica, M. Zaharia, “Above the clouds: a berkeley view of cloud computing,” University of California at Berkley, USA , Feb 2009. [4] X. Xu, “From cloud computing to cloud manufacturing,” Robotics and computer integrated manufacturing, 28(1), 75-86 , 2012. [5] C. Henderson, “Building scalable web Sites,” Sebastopol, CA: O'Reilly, 2006. Print. [6] M. Papazoglou, and P. Ribbers, “E-business: organizational and technical foundations,” Chichester, England: John Wiley, 2006. [7] Amazon case studies http://aws.amazon.com/solutions/case-studies [8] S. Müller, D. Bermbach, S. Tai, and F. Pallas, “Benchmarking the performance impact of transport layer security in cloud database systems,” IEEE International Conference on Cloud Engineering, 2014. [9] M. Papazoglou, “Web services: principles and technology,” Harlow, England: Pearson/Prentice Hall, 2008. Print. [10] G. Ramalingam and K. Vaswani, “Fault tolerance via idempotence,” In Proceedings of the 40th annual ACM SIGPLAN-SIGACT symposium on Principles of programming languages, POPL ‟13, pages 249–262, New York, NY, USA, 2013. [11] J. Gray, "Distributed computing economics," ACM Queue, vol. 6, pp. 63-68, 2008. [12] Amazon AWS http://aws.amazon.com/ [1] [13] G. Decandia, D. Hastorun, M. Jampani, G. Kakulapati, A. Lakshman, A. Pilchin, S. Sivasubramanian, P. Vosshall and W. Vogels, “Dynamo: Amazon‟s highly available key-value store,” In Proceedings of twentyfirst ACM SIGOPS symposium on Operating systems principles (2007), ACM Press New York, NY, USA, pp. 205–220. [14] Q. Luo , S. Krishnamurthy , C. Mohan , H. Pirahesh , H. Woo , B. Lindsay , and J. Naughton, “Middle-tier database caching for ebusiness,” Proceedings of the 2002 ACM SIGMOD international conference on Management of data , Madison, Wisconsin, June 2002. [15] H. Jiang, A. Iyengar, E. Nahum, W. Segmuller, A. Tantawi, and C. Wright, “Design, implementation, and performance of a load balancer for SIP server clusters,” Huazhong University of Science and Technology, IBM T.J. Watson Research Center. [16] S. Anand, “Netflix‟s cloud data architecture,” QCon, 2011. [17] P. Coffey, J. Beliveau, N. Mogre, A. Harner, “Benchmarking the Amazon Elastic Compute Cloud (EC2),” Worcester Polytechnic Institute ( March 2011). [18] B. Adler, “Building scalable applications in the cloud: architectural best practices,” RIGHT SCALE, White paper, February 2013. [19] S. Anand, “Building modern web sites: a story of scalability and availability,” QCon, 2013. [20] G. Burke, “Benchmarking Amazon web services relational database service,” MSc research paper, Galway Institute of Technology, 2012. [21] B. Uddin, B. He, R.Sion, S. Sanghrajka, N. Mahajan, “Cloud performance Benchmark series,” Cloud Computing Center, Stony Brook University, 2012. [22] A. Cockcroft, “Architectural patterns for high availability” QCon, 2013 [23] H. Yoon, A. Gavrilovska, K. Schwan and J. Donahue, “Interactive use of cloud services:Amazon SQS and S3,” 12th IEEE ACM International Symposium on Cluster, Cloud and Grid Computing, 2012. [24] J. Cloud, “Decomposing witter: adventures in Service-Oriented Architecture,” QConm 2013. [25] B. Jimerson, “Software architecture for high availability in the cloud”, Oracle Technology Network , June 2012. [26] Y. Nelapati, M. Weiner, “Scaling Pinterest,” QCon, 2013. [27] S. Gribble, E. Brewer, J. Hellerstein, and D. Culler, “Scalable, distributed data structures for Internet service construction,” In Proceedings of the Fourth Symposium on Operating Systems Design and Implementation, October 2000. [28] A. Narin , “Architecting for high availability,” QCon, 2013. [29] T. Eicken, “Benchmarking load balancers in the cloud,” RIGHT SCALE, White paper, April 2010. [30] “Building high availability applications on Google Compute Engine,” Google Article. [31] S. Rajan, “Why cloud is a boon for entrepreneurs”. Silicon India Cloud City. [32] T. Ganesh, “Designing a scalable architecture for the cloud,” IBM, June 2012. [33] J. Varia, “Architecting for the cloud: best practices,” Amazon white paper, January 2010.