In my last post, I discussed some of the key considerations when moving an application to the cloud. To provide a better understanding, I’m using a simple scenario-based example to illustrate how an application could be moved to the cloud.
This article will explain the challenges a company might face, the current architecture of the example application, and finally what the company should expect when moving an application to the cloud. My next article will discuss the recommended solution in more detail.
Company name, logo, business, scenario, and incidents either are used fictitiously. Any resemblance to an actual company is entirely coincidental.
Idelma is a ticket selling provider that sells tickets to concerts, sports event, and music gigs. Tickets are sold offline through ticket counters and online through a website called TicketOnline.
Customers visiting TicketOnline can browse list of available shows, find out more information on each show, and finally purchase tickets online. When a ticket is purchased, it’s reserved but will not be processed immediately. Other processes such as generating ticket and sending the generated ticket along with the receipt will be done asynchronously in a few minutes time.
During peak season (typically in July and December), TicketOnline suffered from heavy traffic that caused slow response time. The traffic for off-peak season is normally about 100,000 to 200,000 hits per day, with the average of 8 to 15 on-going shows. In peak season, the traffic may reach five to seven times more than off-peak season.
The following diagram illustrates the web server hits counter of TicketOnline over the last three years.
Figure 1 – TicketOnline web server hits counter for the last three years
Additionally, the current infrastructure setup is not designed to be highly-available. This results in several periods of downtime each year.
The options: on-premise vs cloud
Idelma’s IT Manager Mr. Anthony recognizes the issues and decides to make some improvement to bring better competitive advantages to the company. When reading an article online, he discovered that cloud computing may be a good solution to address the issues. Another option would be to purchase a more powerful set of hardware that could handle the load.
With that, he has done a pros and cons analysis of the two options:
- On-premise hardware investment
There are at least two advantages of investing in more hardware. One, they will have full control over the infrastructure, and can use the server for other purposes when necessary. Second, there might be less or no modification needed on the application at all, depending on how it is architected and designed. If they decide to scale up (vertically), they might not need to make any changes. However, if they decide to scale out (horizontally) to a web farm model, a re-design would be needed.
On the other hand, there are also several disadvantages of on-premise hardware investment. For sure, upfront investment in purchasing hardware and software are considered relatively expensive. Next, they would need to be able to answer the following questions: How much hardware and software should be purchased? What are the hardware specifications? If the capacity planning is not properly done, it may lead to either a waste of capacity or insufficient of capacity. Another concern is, when adding more hardware, more manpower might be needed as well.
For cloud computing, there’s almost no upfront investment required for hardware, and in some cases software doesn’t pose a large upfront cost either. Another advantage is the cloud’s elastic nature fits TicketOnline periodic bursting very much. Remember, they face high load only in June and December. Another advantage would be less responsibility. The administrator can have more time to focus on managing the application since the infrastructure is managed by the provider.
Though there are a number of advantages, there are also some disadvantages when choosing a cloud platform. For one thing, they might have less control over the infrastructure. As discussed in the previous article, there might also be some architectural changes when moving an application to the cloud. However, these can be dealt with in a one-time effort.
The figure below summarizes the considerations between the two options:
Figure 2 – Considerations of an On-premise or Cloud solution
After looking at his analysis, Mr. Anthony believes that the cloud will bring more competitive advantages to the company. Understanding that Windows Azure offers various services for building internet-scale application, and Idelma is also an existing Microsoft customer, Mr. Anthony decided to explore Windows Azure. After evaluating the pricing, he is even more comfortable to step ahead.
Quick preview of the current system
Now, let’s take a look of the current architecture of TicketOnline.
Figure 3 – TicketOnline Current Architecture
- TicketOnline web application
The web application is hosted on a single instance physical server. It is running on Windows Server 2003 R2 as operating system with Internet Information Services (IIS) 6 as the web server and ASP.NET 2.0 as the web application framework.
SQL Server 2005 is used as database engine to store mainly relational data for the application. Additionally, it is also used to store logs such as trace logs, performance-counters logs, and IIS logs.
- File server
Unstructured files such as images and documents are stored separately in a file server.
- Interfacing with another system
The application would need to interface with a proprietary CRM system that runs on a dedicated server to retrieve customer profiles through asmx web service.
- Batch Job
As mentioned previously, receipt and ticket generation will happen asynchronously after purchasing is made. A scheduler-based batch job will perform asynchronous tasks every 10 minutes. The tasks include verifying booking details, generating tickets, and sending the ticket along with the receipt as an email to customer. The intention of an asynchronous process is to minimize concurrent access load as much as possible.
This batch job is implemented as a Windows Service installed in a separated server.
- SMTP Server
On-premise SMTP Server will be used to send email, initiated either from the batch job engine or the web application.
Requirements for migration
The application should be migrated to the cloud with the following requirements:
- The customer expects a cost effective solution in terms of the migration effort as well as the monthly running cost.
- There aren’t any functional changes on the system. Meaning, the user (especially front-end user) should not see any differences in term of functionality.
- As per policy, this propriety CRM system will not be moved to the cloud. The web service consumption should be consumed in secured manner.
Calling for partners
As the in-house IT team does not have competency and experience with Windows Azure, Mr. Anthony contacted Microsoft to suggest a partner who is capable to deliver the migration.
Before a formal request for proposal (RFP) is made, he expects partner to provide the following:
- High-level architecture diagram how the system will look when moving to the cloud.
- Explanation of each component illustrated on the diagram.
- The migration processes, effort required, and potential challenges.
If Microsoft recommends you as the partner, how will you handle this case? What will the architecture look like in your proposed solution?
The most exciting part will come in the next article when I go into more detail on which solution is recommended and how the migration process takes place.
This post was also published at A Cloud Place blog.