1 – The Adatum Scenario
.png "patterns & practices Developer Center")
| On this page: | Download: |
|---|---|
| The Adatum Company | Adatum's Challenges | Adatum's Goals and Concerns | Adatum's Strategy | The aExpense Application | The aExpense Architecture | Evaluating Cloud Hosting Opportunities | Evaluating the Runtime Platform - Infrastructure as a Service, Platform as a Service, Software as a Service | Evaluating Data Storage Facilities | Evaluating Security, Monitoring, and Management Capabilities | Evaluating Service Level Agreements | Evaluating Additional Opportunities | Adatum’s Migration Path for the aExpense Application | Choosing Your Own Migration Path | More Information |
.png "Download code samples")
|
.png "Download PDF")
|
This chapter introduces a fictitious company named Adatum. It describes Adatum's current infrastructure, its software portfolio, and why Adatum wants to move some of its applications to Microsoft Azure. As with any company considering this process, there are many issues to take into account and challenges to be met, particularly because Adatum has not used the cloud before. At the end of this chapter you will see how Adatum explored and evaluated the major requirements for moving its applications to the cloud, and an overview of the migration steps that Adatum followed. The chapters that follow this one show in detail how Adatum modified its expense tracking and reimbursement system, aExpense, at each stage for deployment to Azure.
The Adatum Company
Adatum is a manufacturing company of 15,000 employees that mostly uses Microsoft technologies and tools. It also has some legacy systems built on other platforms, such as AS400 and UNIX. As you would expect, Adatum developers are knowledgeable about various Microsoft products, including .NET Framework, ASP.NET, SQL Server, Windows Server, and Visual Studio. Employees in Adatum's IT department are proficient at tasks such as setting up and maintaining Active Directory and using System Center.
.gif "Ff803364.note(en-us,PandP.10).gif") Jana Says: |
|
|---|---|
.png "Jana")
|
|
Adatum uses many different applications. Some are externally facing, while others are used exclusively by its employees. The importance of these applications ranges from “peripheral” to “critical,” with many lying between the two extremes. A significant portion of Adatum's IT budget is allocated to maintaining applications that are either of mid-level or peripheral importance.
Adatum wants to change this allocation. Its aim is to spend more money on the services that differentiate it from its competitors and less on those that don't. Adatum's competitive edge results from assets, such as its efficient supply chain and excellent quality controls, and not from how effectively it handles its internal email. For example, Adatum wants efficient email but is looking for more economical ways to provide this so that it can spend most of its budget on the systems that directly affect its customers. Adatum believes that one way to achieve this optimization is to selectively deploy applications to the cloud.
Adatum's Challenges
Adatum faces several challenges. Currently, deploying new on-premises applications takes too long, considering how quickly its business changes and how efficient its competitors are. The timeframe for acquiring, provisioning, and deploying even a simple application can be at least several weeks. No matter the application's complexity, requirements must be analyzed, procurement processes must be initiated, requests for proposals may need to be sent to vendors, networks must be configured, and so on. Adatum must be able to respond to its customers' demands more rapidly than the current procedures allow.
Another issue is that much of Adatum's infrastructure is used inefficiently. The majority of its servers are underutilized, and it's difficult to deploy new applications with the requisite service-level agreements (SLAs) to the existing hardware. Virtual machines are appropriate in some cases, but they are not appropriate in all cases. This inefficiency means that Adatum's capital is committed to an underutilized infrastructure when it could be better used elsewhere in the business.
A final issue is that less critical applications typically get less attention from the IT staff. It is only when the application fails or cannot keep up with demand that anyone takes notice. By this time, the problem is expensive to fix, both in terms of IT time and in inefficient use of the users' time.
Adatum wants to focus on the applications, and not on the infrastructure. Adatum believes that by deploying some of its applications to a public cloud such as Azure it can take advantage of economies of scale, promote standardization of its applications, and have automated processes for managing them. Most importantly, Adatum believes that this will make it more effective at addressing its customers' needs, a more effective competitor in the market, and a better investment for its shareholders.
Adatum's Goals and Concerns
One of Adatum's goals is to improve the experience of all users of its applications. At a minimum, applications in the cloud should perform as well as their on-premises counterparts. The hope, though, is that they will perform better. Many of its applications are used more at some times than at others. For example, employees use the salary tool once every two weeks but rarely at other times. They would benefit if the applications had increased responsiveness during peak periods. This sensitivity to demand is known as dynamic scalability.
However, on-premises applications that are associated with specific servers don't provide this flexibility. Adatum can't afford to run as many servers as are needed during peak times because this hardware is dormant the rest of the time. If these applications were located in the cloud, it would be easy to scale them depending on the demand.
|
Bharath Says: |
|
|---|---|
.png "Bharath")
|
|
Another goal is to expand the ways that users can access Adatum's applications. Currently, applications are only accessible from the intranet. Applications that are located in the public cloud are, by definition, available over the Internet. However, the public cloud also raises questions about authentication. Many of Adatum's applications use Windows authentication so that users aren't required to enter application-specific credentials. Adatum is concerned that its users would need special credentials for each application in the public cloud.
A third goal is that at least some of Adatum's applications should be portable. Portability means that the application can be moved back and forth between a hosted data center and an on-premises data center without any modifications to the application's code or its operations. If both options are available, the risks that Adatum incurs if it does use the cloud are reduced.
In addition to its concerns about security, Adatum has two other issues. First, it would like to avoid a massive retraining program for its IT staff. Second, very few of Adatum's applications are truly isolated from other systems. Most have various dependencies. Adatum has put a great of deal effort into integrating its systems, even if not all of them operate on the same platform. It is unsure how these dependencies affect operations if some systems are moved to the public cloud.
Adatum's Strategy
Adatum is an innovative company and open to new technologies, but it takes carefully considered steps when it implements them. Adatum's plan is to evaluate the viability of moving to the cloud by starting with some of its simpler applications. It hopes to gain some initial experience, and then expand on what it has learned. This strategy can be described as “try, learn, fail fast, and then optimize.” Adatum has decided to start with its aExpense application.
The aExpense Application
The aExpense application allows Adatum's employees to submit, track, and process business expenses. Everyone in Adatum uses this application to request reimbursements. Although aExpense is not a critical application, it is important. Employees can tolerate occasional hours of downtime, but prolonged unavailability isn't acceptable.
Adatum's policy is that employees must submit their expenses before the end of each month. The majority of employees don't submit their expenses until the last two business days. This causes relatively high demands during a short time period. The infrastructure that supports the aExpense application is scaled for average use across the month instead of for this peak demand. As a result, when the majority of employees try to submit their expenses during the last two business days, the system is slow and the employees complain.
The application is deployed in Adatum's data center and is available to users on the intranet. While traveling, employees access it through a VPN. There have been requests for publishing aExpense directly to the Internet, but it's never happened.
The application stores a great deal of information because most expense receipts must be scanned and then stored for seven years. For this reason, the data stores used by aExpense are frequently backed up.
The application is representative of many other applications in Adatum's portfolio so it's a good test case for using the cloud. Moving the aExpense application to Azure will expose many of the challenges Adatum is likely to encounter as it expands the number of applications that it relocates to the cloud.
The aExpense Architecture
Figure 1 illustrates the aExpense architecture.
.png "Figure 1 - aExpense architecture")
Figure 1
aExpense architecture
The architecture is straightforward and one that many other applications use. aExpense is an ASP.NET application and employees use a browser to interact with it. The application uses Windows authentication for security. To store user preferences, it relies on ASP.NET membership and profile providers. Exceptions and logs are implemented with Enterprise Library's Exception Handling Application Block and Logging Application Block. The website uses Directory Services APIs to query for employee data stored in Active Directory, such as the employee's manager. The manager is the person who can approve the expenses.
|
Jana Says: |
|
|---|---|
|
|
|
The aExpense application implements the trusted subsystem to connect to SQL Server. It authenticates with a Windows domain account. The SQL database uses SQL Server authentication mode. The aExpense application stores its information on SQL Server. Scans of receipts are stored on a file share.
There are two background services, both implemented as Windows services. One periodically runs and generates thumbprints of the scanned receipts. It also compresses large images for increased storage efficiency. The other background service periodically queries the database for expenses that need to be reimbursed. It then generates a flat file that the payment system can process. This service also imports the payment results and sends them back to aExpense after the payments are made.
Evaluating Cloud Hosting Opportunities
Before initiating a full technical case study for migration of the aExpense application to Azure, the designers and developers at Adatum evaluated the capabilities offered by cloud hosting partner solutions such as Microsoft’s Azure. For example, they needed to:
- Identify which type of service offered by the hosting providers best suits Adatum's requirements.
- Determine whether a cloud solution can provide the necessary secure and reliable runtime platform and storage facilities.
- Identify how Adatum can monitor and manage the application
- Determine whether the service level agreements (SLAs) are sufficient to meet Adatum’s business requirements.
Evaluating the Runtime Platform
Currently, Adatum runs the aExpense application on its own in-house IT infrastructure. The servers, networks, internal and external connectivity, and associated systems such as power supply and cooling are all the responsibility of Adatum. Together they provide the underlying mechanisms for running applications such as aExpense. As part of the initial evaluation, Adatum investigated the ways that it could move the aExpense application to an external hosting partner.
Infrastructure as a Service
Adatum first considered whether it could simply move the application to an external partner by renting the required infrastructure, complete with all of the associated systems, and run the application unchanged. Renting infrastructure from an external partner is known as Infrastructure as a Service (IaaS). Adatum would be responsible for providing and installing the operating system and software, and maintaining it (such as installing operating system and services updates, and upgrading to new versions). The partner company would provide the hardware (the server) and the associated infrastructure and connectivity.
Cloud providers can typically offer very high levels of infrastructure reliability and availability that are beyond the capabilities of many organizations’ own datacenters. For example, most incorporate robust disaster recovery processes, and offer the ability to deploy in more than one geographical location.
Adopting an IaaS approach will provide some cost saving through a reduction in overall requirements for in-house infrastructure, but it is not easy (or, in some cases, possible) to quantify the in-house cost of running a specific application. In Adatum’s case, the cost of the on-premises infrastructure is effectively shared between all the applications Adatum uses.
|
Bharath Says: |
|
|---|---|
|
|
|
In addition, while this approach is attractive, Adatum must take into account the cost of management and maintenance required to keep the hosted operating system running correctly, and the costs of operating system licenses. However, IaaS is generally less expensive than other ways of hosting applications at remote locations. It can also reduce development cost because applications do not need to be refactored to run in specific types of cloud service roles.
Infrastructure now becomes a running cost rather than a capital investment.
Platform as a Service
Secondly, Adatum considered adapting the aExpense application to run as a hosted application on a platform and operating system provided by an external partner. As the application currently runs on Windows Server and uses the .NET Framework, the external partner would need to offer this platform to avoid the costs of porting the application to a different operating system.
Renting a ready-to-use platform from an external partner is known as Platform as a Service (PaaS). Adatum would be responsible only for providing and installing its aExpense application, and maintaining it (such as fixing bugs and upgrading to a new version). The partner company would provide the operating system pre-installed on appropriate hardware, with the associated infrastructure and connectivity.
|
Bharath Says: |
|
|---|---|
|
|
|
The PaaS approach is attractive to Adatum because it reduces the cost of management and maintenance (the partner is responsible for keeping the operating system running correctly and applying updates), and there is no requirement to pay for operating system licenses. In some cases PaaS hosting charges may be higher than for IaaS, though this is not necessarily the case; and the cost savings in licensing, management, and maintenance can often outweigh any difference. Adatum considered the amount of work involved in refactoring the application to run in cloud-hosted roles and the corresponding development cost, and considered both to be acceptable.
Software as a Service
The third option Adatum considered was to abandon their own aExpense application and rent the use of an expenses application provided by another company. Renting use of third party applications is an example of Software as a Service (SaaS). Many companies have applications specially designed to handle business expense collation and reporting tasks.
However, Adatum must ensure that the third party application can fully meet its specific requirements; hosted third party applications must typically offer a more generic features set to satisfy a wide range of customers. As well as exploring the overall capabilities of the software, Adatum will need to evaluate its security, configurability, performance, and usability. Changing over may incur costs such as user education, as well as the cost of migrating data and users; and perhaps maintaining the old application for a period until changeover is complete.
Evaluating Data Storage Facilities
Most business applications use data, and so before making any decision about hosting the aExpense application externally Adatum needed to evaluate the data storage and retrieval facilities offered by external partners. On-premises and in-house applications typically use a relational database system based on Structured Query Language (SQL), and Adatum’s aExpense application is no exception. Therefore, the external partner must be able to offer the equivalent hosted capability.
|
Bharath Says: |
|
|---|---|
|
|
|
However, other storage formats are common. Some applications require storage for disk files or for unstructured data. The aExpense application stores unstructured data in the form of receipt images on a file share, and it also generates disk files for use by other in-house systems. Therefore, the chosen cloud hosting mechanism must be able to provide support for storing unstructured data; this may be in a format other than disk files so long as the application can be easily adapted to use it.
Between them, these mechanisms should be able to provide the data storage and retrieval features that Adatum requires; albeit with some changes to the application code to use the available storage models. By using an appropriate relational database system, or any other type of repository that can be installed on a hosted sever, Adatum can avoid changes to the application code.
Evaluating Security, Monitoring, and Management Capabilities
Moving applications to outside of the corporate network prompts several questions not directly related to the hosting platform mechanisms. Adatum must be convinced that the hosting providers’ network and infrastructure is secure, and that the hosted application will be protected from malicious attacks and from data exposure in case of systems failure. For example, the hosting network should be resilient to Denial of Service (DoS) and network flooding attacks, and the hosting platform should be able to reliably and safely reinitialize the application after a hardware failure.
In addition, Adatum must evaluate whether hosting in a remote datacenter will meet any legal or regulatory requirements, such as a limitation on the geographical location for data storage and processing. Many cloud hosting providers, including Azure, have datacenters located around the world and allow users to specify the location of the servers and data storage facilities. Azure allows users to specify whether storage replication for backup and resiliency will take place across multiple datacenters in order to satisfy regulatory limitations.
In addition, Adatum must ensure that the chosen hosting provider and deployment mechanism allows administrators to monitor and manage the application and the data stores remotely. Azure includes a range of capabilities that closely match the remote access capabilities for on-premises server, database, and application management. For example, it supports a range of logging facilities, remote desktop access to servers and hosted services, remote configuration, and management of applications and data stores through a web-based portal and APIs that supports REST calls and scripting.
Finally, Adatum must consider if the remote applications must be integrated with other services, both in the cloud and on-premises, to access data, communicate messages, and for monitoring and management. For example, Adatum uses Microsoft System Center Operation Manager for monitoring applications, and it should therefore be also to integrate the remote application and services with this. Additionally, Adatum relies on domain-level authentication through Active Directory and so it will be necessary to join the remote machines to the on-premises domain or adopt an alternative solution that provides equivalent functionality.
Evaluating Service Level Agreements
Adatum recognized that, although the aExpense application is used only by company employees, it must be readily available (in other words, only very rarely offline) and responsive to a reasonable degree. There is no formal SLA for the application, but it should of necessity be available to employees whenever they need to submit expense claims. Of course, for other types of applications, especially publicly visible or business-crucial applications, there will need to be a more formal SLA defined.
SLAs should define not only availability of an application, but also maximum response times. In addition, where other services are required (such as caching or access control), the SLAs should also cover these services. Finally, SLAs should include any information required to define security risks and to meet regulatory or legal requirements (such as the geographical location for data storage).
Azure provides formal SLAs for the IaaS, PaaS, and related services that it offers. However, these do not and cannot cover the customer’s hosted application, as this is outside of Microsoft’s control. Instead, the SLAs are defined in terms of connectivity and role execution; for example, the SLA for Cloud Services guarantees that a role instance will expose full connectivity for 99.95% of the time and that failed role instances will be detected and restarted 99.9% of the time.
|
Jana Says: |
|
|---|---|
|
|
|
Evaluating Additional Opportunities
In addition to the fundamental choices of the hosting model and the deployment approach, the designers and developers at Adatum considered if they could benefit from using the many ancillary services and features available in Azure.
|
Jana Says: |
|
|---|---|
|
|
|
For example, they considered whether the application would benefit from the use of Azure Caching to maximize performance when retrieving data; or for caching output, session state, and profile information.
Other features that Adatum realized would be useful for the aExpense application included Azure Active Directory for authentication and the Content Delivery Network (CDN) for delivering images and other non-authenticated content. These features and Adatum’s decisions regarding their use are explained in more detail in the following chapters of this guide.
Adatum also considered whether the application needed to communicate with the on-premises applications using messaging, or access services exposed by on-premises applications. Azure Service Bus provides many features that would be useful in this scenario, but Adatum decided that these were not required for the current version of aExpense.
To learn more about Azure Service Bus see “Service Bus.” The guide “Building Hybrid Applications in the Cloud” describes the scenarios for and usage of Service Bus in detail.
Adatum’s Migration Path for the aExpense Application
Every company will inevitably make different decisions on the migration path they adopt for moving to the cloud. The range of contributing factors is vast, and each company will have specific goals and limitations that affect the final choices. Typically, companies will begin, as Adatum did, by understanding the concepts of cloud hosting; and then exploring the platforms, services, and options available from cloud hosting providers. From that comes the decision on which cloud provider to use, and the hosting approach that will best match all the requirements.
This guide shows how you can make the appropriate choices when using Azure. However, to help you make those choices, this guide shows several of the hosting approaches. As you will see, the path that Adatum chose for migrating the aExpense application to the cloud included several stages. Adatum began by choosing the option that required the least modification to the aExpense application and then, at each subsequent stage, considered whether moving to another hosting approach would provide additional benefits.
While the multi-step approach Adatum chose for migrating their application may not be realistic in every real-world scenario, it allows the guide to demonstrate several options that are available for hosting applications in Azure. The discussion of the advantages and limitations at each stage will help you to better understand the options available to you when migrating your own applications.
The migration steps that Adatum took for the aExpense application are shown in the following table. The table shows the chapter that discusses each step, a high-level overview of the options chosen, and the Azure technologies that Adatum used. This will help you to follow the flow of the guide and explore the different approaches taken at each stage.
Chapter |
Migration step |
Justification |
Technologies |
|---|---|---|---|
2 – “Getting to the Cloud” |
Infrastructure as a Service (IaaS). |
Minimal code changes to the application and familiarity with the platform. A quick and easy way to explore the benefits of cloud hosting, such as increased reliability and reduced costs of managing the on-premises infrastructure. |
Azure Virtual Machines, Virtual Networks, and Connect. |
Platform as a Service (PaaS). |
No operating system maintenance, easy scalability and elasticity, more granular control of resource usage, and the opportunity for auto scaling. |
Azure Web Sites, Cloud Services web role, and Caching. Windows Identity Framework. |
|
Platform as a Service (PaaS) for database |
Lower cost although some limitations on feature availability. No software maintenance. |
Azure SQL Database. Transient Fault Handling Application Block. |
|
Maximizing efficiency and adding additional tasks. |
Better scalability and performance, better user experience, improved efficiency, and load leveling across role instances. |
Azure Cloud Services worker role, queues, and blob storage. |
|
Revisiting initial cost estimations. |
Confirm initial estimates of cost and look for additional savings. |
Azure Pricing Calculator. |
|
Switching away from relational database storage. |
Lower cost, greater storage volume, opportunity for increased performance, and scalability. |
Azure table storage. |
Some of the technologies described in this guide and used in the examples are preview versions, and the subsequent release versions may differ from the information provided in this guide. This includes Azure Web Sites, Azure Virtual Machines, and Azure Virtual Networks.
Choosing Your Own Migration Path
Just because Adatum has chosen the path described in this chapter, it doesn’t mean that you must follow the same path. Some companies may decide which combination of hosting approach, data store, and services they will use and go directly to this in single migration step. Others may follow a more gradual migration by adopting, for example, Cloud Services as the hosting approach for the application code, but use SQL Server hosted in a Virtual Machine before moving to Azure SQL Database. Meanwhile, some companies may choose the IaaS path so that they have full control over the operating system, but decide to take advantage of the cost savings and vast storage capabilities of Azure table and blob storage instead of using a relational database.
.png "Figure 2 - Choosing your own migration path")
Figure 2
Choosing your own migration path
This is one of the major advantages with Azure – you choose which of the wide range of services it offers are most suitable for your own scenario and requirements. No two applications are the same. Throughout this guide you will see more details of the capabilities and limitations of each hosting option, and how to make the right choice for your applications.
More Information
For an overview of the data storage options available in Azure, "Data Storage Offerings on the Azure Platform."
Introducing Azure includes a list of features.
Azure Service Level Agreements.
"Azure Websites, Cloud Services, and VMs: When to use which?"
The guide “Developing Applications for the Cloud” explores techniques for building new applications specifically designed for run in Azure.
The guide “Building Hybrid Applications in the Cloud” describes the scenarios for and usage of many Azure features.