We illustrated Idelma’s case study in the last article. This article continues from where we left off, looking at how a partner, Ovissia, would provide a recommended solution. Just as a reminder, Idelma had some specific requirements for migration including: cost-effectiveness, no functional changes for the user, and the proprietary CRM system stays on-premise.
Having analyzed the challenges Idelma faces and the requirements it mentioned, Ovissia’s presales architect Brandon gets back to Idelma with the answers. In fact, some of the migration techniques are referenced from the first post in this series.
Figure 1 – TicketOnline Cloud Architecture
Above is the recommended cloud architecture diagram when moving TicketOnline to the cloud. As can be seen from the figure, some portions of the system will remain similar to the on-premise architecture, while others shift towards the cloud-centric architecture.
Let’s take a look at each component in more detail.
SQL Azure is cloud-based database service built on SQL Server technologies. In fact, at the moment,the most similar version of SQL Azure is SQL Server 2008.
Figure 2 – SQL Server Management Studio 2008 R2 (Generate Scripts Wizard)
Another option is to use third party tool such as SQL Azure Migration Wizard.
After the database has been successfully migrated to SQL Azure,connecting to it from the application is as straightforward as changing the connection string.
One of Idelma’s requirements states that the CRM web service must remain on-premise and also must be consumed securely. To satisfy this, Ovissia recommends using Windows Azure Service Bus which provides messaging and relay capability across multiple network hierarchies. With the relay capability and secured by Access Control Service, it enables the hybrid model scenario such that the TicketOnline web application is able to securely connect back to the on-premise CRM Service.
Despite its powerful capability, Service Bus requires WCF Service instead of asmx web service. Thus, the current asmx web service should be converted to WCF Service. MSDN library provides a walkthrough on migrating ASMX Web Service to WCF.
Windows Azure Web Role is used to host web applications running on Windows Azure. Therefore, it is an ideal component to host the TicketOnline web application. Hosting on Windows Azure Web Role requires an ASP.NET web application, not an ASP.NET website. Please refer to this documentation for the difference between the two. The MSDN library also provides a detailed walkthrough on how to convert a web site to web application in Visual Studio.
When the website has been converted to a web application project, it is one step closer to the Web Role. In fact, there are only three differences between the two as can be seen on the following figures.
Figure 3 – Differences between Web Role VS ASP.NET Web Application (Windows Azure Platform Training Kit – BuildingASPNETApps.pptx, slide 7)
Running Windows Service on Windows Azure can be pretty challenging. In fact, Windows Service is not available out-of-the-box on Windows Azure. The recommended approach is to convert the Windows Service to a Windows Azure Worker Role. You may refer to section 3 of the first article in this series for further explanation.
Idelma uses a conventional file server to store documents and images. When moving the application to Windows Azure, the ideal option is to store them in Windows Azure Storage, particularly Blob Storage. Not only is it cost-effective, but Windows Azure Storage also provides highly available and scalable storage services.
However, migrating from a conventional file system to Blob storage requires some effort:
Today, many applications (including TicketOnline) store settings such as application configuration and connection string in .config files (app.config / web.config). We know that the .config file is stored in an individual virtual machine (VM), but storing those settings in a .config file has a drawback. If you need to apply any changes to the settings, a re-deployment is required.
In the cloud, the recommended solution is to store the settings in an accessible and centralized medium such as a database. But if we just need to store the key-value pair setting, ServiceConfiguration.cscfg is actually a good choice. Changing settings in ServiceConfiguration.cscfg does not require a re-deployment and each VM will always get the latest updated settings.
There’s effort little bit of work to do when changing the setting from .config to ServiceConfiguration.cscfg. The following snippet shows the difference between the two.
string settingFromConfigFiles = ConfigurationManager.AppSettings["name"].ToString(); //getting setting from .config files string settingFromAzureConfig = RoleEnvironment.GetConfigurationSettingValue("name").ToString(); //getting setting from ServiceConfiguration.cscfg
The current architecture shows that email is sent through on-premise SMTP. If there is a requirement to continue using on-premise SMTP to send email, we could either propose to use a similar relay technique using Service Bus or use Windows Azure Connect to group cloud VMs and on-premise SMTP together.
Another option is to use a third-party SMTP provider. Recently, Microsoft has partnered withSendGrid to provide a special offer to Windows Azure subscribers for 25,000 free emails per month. This serves as a value-added service by Windows Azure without any extra charges.
Currently, TicketOnline stores the logs in a database. Although this works well with a SQL Azure database, it may not be the most cost-effective option as SQL Azure chargesapproximately $ 10 per GB per month. Over the time, the log will grow more and more, and might result in high running costs for the customer.
Remember, a workable solution is not enough; the solution should be cost-effective as well.
Windows Azure Storage is another option to store diagnostic data and logs. In fact, Windows Azure Diagnostic makes Windows Azure Storage the best option to store logs and diagnostic information. More details on Windows Azure Diagnostic can be found in section 4 of the first article in this series.
To conclude, this article provides a recommended solution to answer the challenges that Idelma face. You can see the difference between the on-premise and cloud architecture. This article also explains various components of the proposed solution.
Of course, this is not the only available solution as there may be other variations. There is no one-size-fits-all solution and there are always trade-offs among solutions. Finally, I hope this series on Moving Applications to the Cloud brings you some insight, especially for those who are considering moving applications to the cloud.
This post was also published at A Cloud Place blog.
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.
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:
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.
Now, let’s take a look of the current architecture of TicketOnline.
Figure 3 – TicketOnline Current Architecture
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.
Unstructured files such as images and documents are stored separately in a file server.
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.
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.
On-premise SMTP Server will be used to send email, initiated either from the batch job engine or the web application.
The application should be migrated to the cloud with the following requirements:
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:
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.
Windows Azure provides many remarkable services that benefit its customers. Assuming that you’ve already decided to hop on Windows Azure, some questions you might be asking include: What are the key considerations when moving applications to the cloud? How do you move an application to the cloud?
The goal of this article is to discuss several common considerations (including any changes that might apply) when moving your application to Windows Azure. Though there are also significant concerns from business perspective, this article will focus on the technical aspects.
The first and probably the most significant consideration is the architecture. Your current architecture may or may not work perfectly on the cloud. Some applications may be moved easily and without many changes, while others may require a certain degree of alignment to fit a cloud-centric architecture.
Designing architecture that fits into the cloud model sometime is not enough.
More important is designing the architecture that brings optimal results. For instance: faster response time, elastically scalable system, and cost effective solution.
If your current application is deployed on multiple instances (a.k.a. a web farm), you are one step closer to a cloud-centric architecture. I would recommend you to check out this post on the web farm concept to see where the differences are compared to single-instance deployment. The web farm architecture is naturally very similar to Windows Azure multiple-instance deployment.
Even though you can have a single instance for your Windows Azure deployment, it’s recommended to have at least two instances per role to meet the 99.95% SLA. The instances sitting behind Windows Azure load-balancer will be load-balanced in round-robin.
In web farm architecture, storing information in each individual instance will not work when the information should be shared across instances. The information could refer to session state, any relational data, or any unstructured files. Thus, a central repository is required to ensure that each request from the client will be consistently handled. Figure 1 illustrates how the multiple-instances are deployed in Windows Azure.
Figure 1: Multi-instance architecture
Pertaining to central repository, the following summarizes various options that best suit shared information.
The second aspect that should be taken into account is application-level security. This will eventually lead to the question: How do you manage your user account and profile? Many applications use database or Active Directory to keep their user profile. There are also some that rely on third-party identity providers.
Below describes how each method will be reformed when moving the application to Windows Azure.
Storing user accounts inside the database is perhaps the simplest method. As long as the database you are using is compatible with SQL Server 2008, to migrate it to SQL Azure shouldn’t be too much trouble. The user account tables should be migrated along with the other tables in your database.
If you are using ASP.NET Membership Provider, migrating to SQL Azure is even easier with the availability of ASP.NET Universal Provider Nuget Package.
Active Directory is popular choice, especially for corporate applications. This avoids having one person (with a single user ID) manage different accounts across many applications. With the release of ADFS (Active Directory Federation Service) 2.0, third party applications, regardless of whether they’re residing on-premise or in the cloud, can authenticate to corporate Active Directory account using claim-based authentication.
Nowadays, many applications, especially public facing websites, rely on third-party identity providers (such as Google ID, Live ID, Facebook, etc.) to perform authentication. Fortunately, Windows Azure offers Access Control Service which simplifies the authentication process with multiple identity providers.
Even though cloud solutions provide a wide-range of services, there are also some limitations. To know what’s available and what isn’t is the responsibility of cloud architects when designing a cloud solution for their customers. For the features that are unavailable, the architects should provide alternate solutions that meet the requirements.
The following discusses an example of a potential limitation in Windows Azure and how it could be overcome.
Logging and monitoring are important as they could be used to tracing exceptions, monitoring performance, and planning for capacity.
Although configuring them is normally not difficult, there are some differences between performing these tasks on-premise or in the cloud. For one thing, you might have many instances in a cloud environment, the cloud instances aren’t persistent and, they might have a massive amount of data.
Now, the goal is to store the diagnostic information persistently, accessibly, and cost-effectively so that the diagnostic information can be viewed and monitored easily.
Windows Azure Diagnostic (WAD) enables you to collect diagnostic information from your Windows Azure application. WAD transfers the diagnostic information to Windows Azure Storage to ensure its persistency. The transfer can happen either on a schedule or on-demand. As we know that Windows Azure Storage is a highly-accessible service that’s competitively priced, so that goal can be accomplished.
Data transferred to Windows Azure Storage can be accessed either with tools or API. Some tools (such as Cerebrata’s Azure Diagnostic Manager) enable us to view and monitor the diagnostic information easily through GUI (Graphical User Interface) as is shown in Figure 2. With that, we are able to take appropriate actions.
Figure 2 Cerebrata Azure Diagnostic Manager
I haven’t discussed everything that needs to be taken into account, but the four points discussed above are the some of the key considerations when moving your applications to Windows Azure. Although some changes might apply, the changes are normally around the architecture and design. You don’t have to change the business logic.
In the next article, I will elaborate in more detail with a case study on moving an application to the cloud: starting from the current scenario, challenges that customer faced, architectural changes, and the final outcome.
This post was also published at A Cloud Place blog.