Background
Few weeks back, I was part of a Panel discussion in the Chennai Cloud User Group un- conference.
Almost all the members of the group had one question, how do you make your existing web application run in the Cloud Environment? I am sure, all who wants to migrate to the Cloud for the first time, would be asking this question to themselves. Though it is a basic one, I believe there needs to be a systematic approach towards achieving this.
I am sure you all know about Amazon Cloud, but for those who do not know about AWS, please visit http://aws.amazon.com website and create an account using your credit card. You will not be charged for anything upfront. :-)
Some of the useful tools that are available to manage the AWS Cloud are Hybridfox, CloudBuddy Personal, Elasticfox, S3fox...etc. These tools have more features than any of the tools available in the market.
Well, In general to move your applications to the Cloud, you don't really need to do any changes. All you need to know is how the Cloud works. Cloud languages like Machine Image (EBS or S3 based), instance, Security Group, user data, Availability Zones, CloudFront, SQS, RDS..etc This can be easily picked up if you spend about a day or two in AWS website. But, if you want leverage the inherence advantages of Cloud, you need to really have a solid design in place, and that’s what I have described here with our own experience of moving an existing application to the AWS Cloud.
Approach
Examine the Current Application Deployment Architecture
Before moving your apps to Cloud, you must be familiar with your current application deployment architecture and its non functional requirements (NFR's) such as availability, scalability, security, performance...etc. This would enable you to clearly map the Cloud building blocks to your existing application architecture.
Let me show you this via an example,
In my organization, we had a CRM which was serving for about 100 concurrent requests per second, hosted in our own data center. While, we decided to move it to the Cloud, it looked like very simple thing to do. But, while we analyzed, we came up with the following non functional requirements that are needs to be addressed. I have detailed our solution to each of the issues listed below.
1. Application provisioning & configuration
2. Backup of the database required to be automated
3. Caching services using Memcache to be implemented
4. Single Sing On, the server is available in the enterprise data center and we had to authenticate from the Cloud
5. Emailing from the Cloud - Since it is a CRM, the main way of communicating to our customers are via email
6. Shared file system for storing files, images...etc
7. Secured Access using SSL
8. Payment gateway integration
9. SLA for application performance (every request should be served with a response, within 3 Sec of originally receiving it)
10. Auto scaling to support additional spiking need
Solution - Design your Cloud Deployment
Our Cloud Architects have designed the architecture to satisfy the NFR's listed above and they came up with almost completely, a new deployment architecture, due to the nature of AWS Cloud.
Application Provisioning & configuration
An application in the local data center is provisioned & configured once by the administrators. But our Architects proposed a new approach to do the same installation by automating the provisioning & configuration. The reason behind this is, when you want to automatically scale your applications to handle more loads, you may not be able to perform the following steps manually in the Cloud environment. Because doing this manually requires someone to monitor the performance of the Application, based on the load, he may need to decide to launch an another supporting instance to handle to load, when the application server instance boots up, the server engineer may need configure the required parameters such as Database instance IP address, Memcache server IP address, SSL certs deployment, changes in your web application configurations...etc manually. This is a tedious process and the human intervention required to do this can be completely avoided. Secondly, in the AWS Cloud though they have SLA's for the availability of their data centers in various regions, they do not guarantee for the life time of the instance. Which means at any point in time, your instances may fail( very rare) but, we need to accommodate the failure as well. "Design for failure", so that nothing fails, is the key for successful Cloud App. you can also, take a look at Jinesh's presentation on slideshare (http://www.slideshare.net/AmazonWebServices/aws-architectingjvariafinal)
Backup of your database
In general backup's are pointed to a local drive and the backup tools that you use can extract the content and store it in a local hard drive. Now in the AWS Cloud, you may use either S3 (http://aws.amazon.com/s3/) or EBS (http://aws.amazon.com/ebs/). Our architects have chosen to go with S3 due to its new reliability support at the API level. And we used CloudBuddy WEBDEV (you can use s3fuse, if it is a linux) to mount the S3 backup buckets to the EC2 instances running our CRM application database to completely automated the backup.
Memcache for caching information
Memcache is kind of a straight forward setup, but we had to configure each instance running the Memcache. We have decided to use CloudSmart to configure the Memcache instances.
Single Sign On
Single Sign on residing on our local data center premise provides domain verification mechanism and we used that feature to authenticate the caller machine from the Cloud before proceeding to the user authentication process.
Emailing from the Cloud
Emailing from the Cloud is kind of restricted beyond certain number of emails, which requires a special permission from AWS and we obtained the permission from AWS by submitting a form. You need to have a domain name associated with the instance to send emails to the outside world.
Shared file System
Shared file system can be achieved using SAMBA, NFS, network share...etc. Due to the nature of Cloud, it is a best practice to store the files in S3 for reliability, security & availability reasons. We have used CloudBuddy WebDEV to mount S3 bucket as a drive in both Windows & Linux operation systems. Alternatively you can also use S3FUSE to mount buckets as a drive for your linux operation system.
SSL Implementation
SSL was required to be installed in all the front ending machines in Apache, CloudSmart is used to automate the installation at every end point.
Payment Gateway Integration
Payment gateway integration requires Level 1 PCI compliance as per our policy, so we decided to keep the payment processing engine at our data center premise and redirect from the CRM hosted on the Cloud.
Performance of the Cloud Application
The performance of the CRM is measured using our CloudTestGo platform and our Cloud Architect's have come up with the following recommendations to satisfy the 3Secs serving time requirement. This design is expected to serve 100 concurrent hits at any point of given time with a TTL for every request is 3 Secs.
- Use CloudFront to serve the static content such as HTML, images, Javascript...etc
- 3 Medium instances behind the load balancers, to handle SSL transformation to non-SSL requests
- 2 Large instance running IIS with windows 2008 64-bit
- 2 large instance to host the SQL Server database which is clustered
Auto scaling was achieved for all the three layers such as web, application & DB layer.
Web Layer (Apache Servers) - If the web server instance gets more than 70% network utilized, the Auto scaling mechanism of AWS will launch an another instance of the same image. This will allow the installed CloudSmart to do the necessary configuration in the AWS environment such as adding the machine to the Auto Scaling group, copying the new httpd.conf...etc
Application Layer ( IIS) - When the IIS instance gets more than 70% network utilized, the Auto scaling mechanism of AWS will launch an another instance of the same image. This will allow the installed CloudSmart to do the necessary configuration in the AWS environment such as adding the machine to the Auto Scaling group, Copying the ASP.NET application, mounting EBS volume as a drive..etc
DB Layer (MS SQL Server 2008) - All the calls to the database was distributed by the SQL Server Cluster itself and the load on the individual cluster node will automatically launch an instance and create necessary configuration to join the Cluster group.
Conclusion
It is understood that moving apps to Cloud is straight forward but the key factor is to use the advantages of the Cloud, which is nothing but automating every aspects of your application deployment. And that can be very well achieved through the available open source technologies itself.
No comments:
Post a Comment