WIXLIB

Migrating to the Cloud: A Case Study1.0 EXECUTIVE SUMMARYCloud computing has lately gained a lot ofinterest for the advantages it delivers from a priceto performance ratio based on the principles ofmulti-tenancy,, distribution and scalability thatforms the core principles of cloud computingSpecifically, companies such as Amazon andothers have made cloud computing accessible toa large community of developers by exposingrdweb services APIs that allow 3 party companiesto host their applications on the Amazon cloudand take advantage of the robustness of theirlarger network insteadtead of having to incur the costof maintaining one’s own data center.There is not only a strong commercial aspectsupporting migration of applicationss to Cloud butalso valid technicals reasons to do so.so Cloudbased architecturesctures allow applications to scale tomassive levels dynamically with little tuning whileleveraging the capabilities of the underlyinginfrastructure.Table of Contents1.0EXECUTIVE SUMMARY12.02.1THE CUSTOMER PAIN POINTSPOEXISTING ARCHITECTUREARCHITECTUR123.03.13.23.33.43.5THE CLOUD BASED SOLUTIONSOLUMULTI-DIMENSIONALNAL DATA LAYERMULTI-FEATUREFEATURE SERVERSDISTRIBUTION BASED ONO GEOGRAPHYLOAD BALANCING & SCALINGSCAHIGH AVAILABILITY3344444.0SOLUTION KEY WINS65.0REFERENCES6HSC was recently charted to execute atransformationprojectforanexistingcollaboration platform to a cloud based platform.In this paper we have captured the strategy,which was adopted for re-engineeringengineering the existingapplication from a shared hosting platform to apopular cloud, based infrastructure anddatabase platform.2.0 THE CUSTOMER PAIN POINTSThe customer sells a web based hostedconferencing solution. The solution combinescollaboration/communication tools in a friendlyfront-endend for easy use by enterprise customers .With the increased acceptance of the platform itthe customer felt that the current architecturewas limited with respect to scaling. Thecustomer had an option to upgrade to a muchlarger data-centercenter and high availability solution,but the initial investment (inin addition to reengineering cost)) for the the upgrade meant the1HSC PROPRIETARY

customer would have to put up a lot of money upfront without assured returns. Instead, the customer wanteda ‘scale as you grow’ solution that kept the company spending controlled.Cloud based ‘pay as you go’ approach was the ideal solution for this customer. The cloud solution that wasrecommended by HSC was to use the Amazon cloud infrastructure. In addition to cost savings, the reliabilityof the amazon cloud was of significant benefit to the customer as well.2.1 Existing ArchitectureFigure 1-1: Original network deployment architecture of my web conference.comThe original collaboration application was architected as an n-tiern tier solution, which builds on top of variousSaaS platforms and supports multi-tenancymulti tenancy in its northbound interface. The only scalability it achievedwas through classical load balancing techniques available today. Down time during failovers or plannedupgrades was another challenge the development and support team was continuously facing. Theirpremium customers were looking at SLAs which would allow hot upgrades (upgrade while the system islive) and carrier gradeade availability.availability. AsAs partpart ofof thisthis project,, HSC was additionally tasked at proposing asolution strategy, which could be employed to take care of availability issues and reduce overall downtimeunder different circumstances. The figure below captures the original architecture for the website.2HSC PROPRIETARY

Figure 1-2: Solution Architecture3.0 THE CLOUD BASED SOLUTIONAfter studying the existing architecture and the business requirements HSC proposed a cloud -basedarchitecture which leverages the Amazon’s Elastic Compute Cloud (EC2) and other associated services tointroduce dynamic scalability in the platform and at the same time ta kes care of issues related to availabilityduring failovers and upgrades.Key aspects of the proposed solution:1. Minimum changes to the corecore code. Only the data layer was changed and a new module for systemmonitoring and scaling was introduced.2. Multi-dimensionalensional data layer (support for dedicated and multi-tenancymultihosting)3. Multi-FeatureFeature servers (dedicated and shared hosting instances of the application servers)4. Distribution across regionegion based infrastructure for geography context sensitive load balancing andbetter throughput and turn-aroundaround timetime forfor customerscustomers5. Software based load monitoring and dynamic solution scaling6. Use of Amazon’s Elasticlastic IP infrastructure and Availability zones for high -availabilityavailability duringduring failoversfailoversand upgradesThe subsequent sections of the document explain the key architectural changes that HSC made to thesolution and how they were deployingploying on the Amazon cloud infrastructure.3.1 Multi-dimensional datata layerThe data layer of the original solution was monolithic and had a complex architecture to support multi tenancy. While the solution served the requirements, it featured a lot of complex overhead code for thebusiness logic. Additionally, there were limitationslimitations inin thethe systemsystem forfor itit toto bebe deployeddeployed inin aa dedicateddedicated modemode forforcustomers who were heavy users,, while maintaining acceptable performance for other users of the service.HSC proposed a multi-dimensionaldimensional data architecture, which could support both dedicated and a multi-tenancymultimode.1. The new architecture had each dedicated server instance complemented with a private MySQLdatabase instance.3HSC PROPRIETARY

2. The shared servers on the other hand used a shared database instance, which used MySQL andAmazon Simple DB in complementary fashion.3. Simple DB was primarily used for storing and fast retrieval of LOBs (Large Objects)3.2 Multi-Feature ServersThe customer had different user profiles with different usage requirements and accompanied SLAs.During our technical evaluation of the system, it was felt that the existing multi-tenantedtenanted architectureimposed an uncalled for overhead on the platform which in turn lead to the underperformance of thesolution even when deployed in a dedicated mode. However, such overheads were un -avoidable forsubscribers who were occasional usersers ofof thethe systemsystem andand hadhad SLAs,SLAs, whichwhich werewere compensatedcompensated byby aacheaper utility-basedbased serviceservice offering.offering.Keeping these aspects in mind, HSC introduced a multi -featurefeature server approach where dedicated serverinstances, without a multi-tenancytenancy framework, couldco uld be deployed dynamically to cater for subscribers withhigher service usage and stringent SLA requirements.These servers could either be instantiated dynamically or could be provisioned statically using a webbased control panel, which consumesumesumes APIsAPIs exposedexposed byby AmazonAmazon ElasticElastic computecompute cloudcloud infrastructure.infrastructure.The web based control panel itself was built on top of HSC’s reusable components for EMS/NMSdevelopment.3.3 Distribution based on GeographyTo reduce the turnaround time and introduce distribution,ibution, thethe solutionsolution waswas deployeddeployed acrossacross variousvarious datacenters of Amazon with location selection, instance count being a function of customers and associatedSLAs in those regions. This approach to distribution also introduced the much needed red undancy whichwould prevent the system from a complete failure, and hence if the servers in one -region were notreachable or loaded, the system would still be able to re-route and serve requests from other regions.Furthermore allll data servers were replicated automaticallyautomaticall at pre-determineddetermined time intervals or manuallywhen instructed by the operator across the regions.3.4 Load Balancing & ScalingDistribution based on geography and solution scaling was built into the system using Amazon’s Loadbalancing and Auto scaling APIs.3.5 High AvailabilityHigh availability was one of key concerns addressed by the cloud-basedcloud based architecture. As is evident from thesolution description high-availabilityavailabilityavailability hashas beenbeen introducedintroduced inin thethe systemsystem atat multiplemultiple layers.layers. TheThe keykey strategystrategy forforintroduction of redundancy was based on utilization of Amazon’s infrastructure and isolating server instancesfrom total infrastructure failure.ailure. This was achieved in the proposed solution through: 1. Redundant deployment across availability zones in the same geographical region2. Deployment of a shared standby instance which can take over either as a dedicated or sharedserver3. Instance monitoringing andand rere-deployment4. Load balancing and auto scalingThe figure below describes the network layout architecture of the new cloud hosted solution developed byHSC.4HSC PROPRIETARY

Figure 1-3: Network deployment architect ure of HSC’s proposed solutionFigure 1-4: SolutionSolution ArchitectureArchitecture ofof thethe CloudCloud hostedhosted solutionsolution5HSC PROPRIETARY

Figure 1-4,4,4, showcasesshowcases thethe solutionsolution architecturearchitecture ofof thethe pilotpilot solution,solution, whichwhich waswas deployeddeployed forfor the customer.4.0 SOLUTION KEY WINSThe key wins of the solution were:1.2.3.4.A dynamically scalable solution with small operational overheadsSolution scalable across geographiesSolution supports scaling as a dedicated hosted server platform and a shared server platformLeverages the proven Amazon’s infrastructure and builds around available solutions thereby reducinginvestment and maintenanceintenance costs.5.0 REFERENCESa. Amazon Elastic Compute Cloud, User SEC2/latest/UserGuide/ )b. Amazon Cloud Watch, Developer ervices.com/AmazonCloudWatch/latest/DeveloperGuide )c.Auto Scaling, Developer es.com/AutoScaling/latest/DeveloperGuide )d. Load balancing, Developer dhttp://docs.amazonwebservices.com/ElasticLoad eveloperGuidee. Amazon SimpleDB, Getting Started edGuide/ )PROPRIETARY NOTICEAll rights reserved. This publication and its contents are proprietary to Hughes Systique Corporation. No partof this publication may be reproduced in any form or by any means without the written permission of HughesSystique Corporation, 15245 Shady Grove Road, Suite 330 , Rockville , MD 20850.Copyright 2009 Hughes Systique CorporationCONTACT INFORMATION:Phone: 1.301.527.1629 1.301.527.1629fax: 1.301.527.1690email: whitepaper@hsc.comWeb: www.hsc.com6HSC PROPRIETARY