AGENCY FOR STATE TECHNOLOGY DATA CENTER OPERATIONAL STRATEGY. Data Center Operational Strategy

Transcription

1 AGENCY FOR STATE TECHNOLOGY DATA CENTER OPERATIONAL STRATEGY Data Center Operational Strategy Eric M. Larson Agency for State Technology 1/13/2015

2 Table of Contents Executive Summary History/ Issues in the past Data Center Planning Purpose Timeline for Cloud Strategy Implementation Application Rationalization (1/2015-7/2017) LBR for DCC equipment Refresh, Private/Hybrid Cloud Prerequisites (7/2015) Installation of LBR Funded Equipment (7/2015-1/2016) Install and Provision Data Center Interconnect (7/2015-1/2016) Complete Consolidation into SDC Compute (1/2016-1/2017) Data Center Interconnect engineering and testing (1/2016-7/2016) LBR for Hybrid Cloud Engineering and Staff Augmentation (7/2016) Hybrid Cloud Engineering, Testing and Pilot (7/2016-7/2017) Migrate Standards compliant workloads to consolidated SDC facility (7/2016-7/2018) LBR for Cloud Services based on RFI, RFQ, and results of Hybrid Cloud Testing and Pilot (7/2017) Migrate Rationalized Workloads to Cloud (7/2017-7/2020) Move all remaining equipment into consolidated SDC facility (7/2018-7/2019) Data Center Planning, including FY LBRs Migrate Legacy Hardware into SDC Enterprise Compute (Virtualization) Expand Backup and Storage capacity of SDC Consolidate the Operations of the SDC Remediate Power Infrastructure at Southwood SDC Facility Transform SDC Enterprise Environment Into Hybrid Cloud Cloud Services What is Cloud? Cloud Service adoption considerations Cloud Service Types Software as a service (SaaS): January 13, 2015 Page 1

3 4.3.2 Platform as a service (PaaS): Infrastructure as a service (IaaS): Cloud services and AST: Application Rationalization Application architecture Data Equipment Security Licensing Other Major Benefits of Application Rationalization Application rationalization and AST January 13, 2015 Page 2

4 Executive Summary The State Data Center (SDC) functions with hardware and software that was transferred from state agencies over the past six years during data center consolidation. When consolidated into the data centers, these hardware and software platforms quickly became outdated and in some cases duplicative. There are mature solutions available to allow platform management to be standardized and managed in a more cost-effective manner. In addition to the cost efficiencies, these solutions also allow the easy movement of workloads between different locations. The Agency for State Technology (AST) herein presents a plan to build a unified SDC architecture that can integrate existing platforms and leverage other service options, including interoperability with third party cloud infrastructure service providers. In an effort to enable the SDC to improve the efficiency and effectiveness of operations as well as prepare to strategically leverage commoditized infrastructure services, the AST proposes several financial and engineering investments into the infrastructure and architecture of SDC services. These investments and corresponding engineering efforts establish a unified architecture that will enable the SDC to reduce costs and increase service levels by ensuring that there are stable, scalable service platforms as well as appropriate tiers of service and pricing for the different usage scenarios found within the SDC. The detailed timelines for these efforts are contained herein. Building the unified architecture is the primary challenge the AST faces. This requires unifying two existing data centers into a single, logical operational entity with a common service catalog as well as establishing a supportable, standardized and unified approach for the core compute, storage, backup, network and database platform service offerings. This also requires that both data centers share a common licensing, systems management and security strategy. Once complete, the next step is to remove the disparate equipment and service approaches acquired from agencies for the past six years during data center consolidation. This will occur as agency workloads are migrated into the unified SDC architecture. These tasks will require a significant level of effort as well as coordination between SDC staff and agency resources to minimize interruption of business functions. The goal of the unified SDC architecture is to provide an environment in which data and workloads become independent of the underlying physical infrastructure. This approach will allow the SDC to migrate standards compliant workloads between SDC facilities without interrupting services provided to agency customers. To do so, a Data Center Interconnect will be established between the SDC facilities allowing the data centers to function as a single, logical data center. Once the SDC facilities network and service platforms have been fully January 13, 2015 Page 3

5 integrated, the stage is set to non-disruptively enable workload migrations amongst SDC facilities as well as third party infrastructure service providers. As third party infrastructure services are maturing and becoming less expensive, the SDC will be able to securely leverage these services with low risk to agencies of service disruptions. This will allow the SDC to establish lower cost service tiers and will ensure that the SDC can scale up to meet the future growth needs of agency workloads without having to construct additional data center facilities to handle growth. This scalability is necessary considering all SDC services are expected to continually become more efficient and effective while minimizing the state s exposure to capital expenditures. The integration of the SDC Private Cloud platforms with commoditized third party Public Cloud service offerings is commonly referred to as a Hybrid Cloud approach. For new applications and application rewrites identified through the Schedule IV-B and Legislative Budget Request processes, the AST will carefully review requests and strongly suggest that agencies look first towards cloud based Software as a Service (SaaS) and Platform as a Service (PaaS) service offerings to see if they can meet their requirements. This will ensure that no opportunities are missed to potentially minimize capital expenditures, reduce development time and provide a more predictable outcome by leveraging cloud based service offerings. This document includes Fiscal Year Legislative Budget Request anticipated funding to complete data center consolidation and also establishes a strategy for the future of the state data center system. January 13, 2015 Page 4

6 1. History/ Issues in the past The State Data Center consists of two primary data center locations, one on the northwest side of Tallahassee within the Northwood Centre (previously known as the Northwood Mall) and the other on the south side of Tallahassee in Southwood. A third primary data center, the Northwest Regional Data Center (NWRDC), is also maintained by the state; however, this data center mainly functions and is supported by educational entities and is out of scope for this plan document. The Legislature, in 2008, established the state data center system and intended for all agency data centers and computing facilities to be consolidated into a primary data center by The Legislature initiated the first phase of data center consolidations in 2009 with proviso included in the FY General Appropriations Act. This was followed by the Agency for Enterprise Information Technology (AEIT) submitting its Recommendation of Non-primary Data Centers for Consolidation into Primary Data Centers by 2019 report in December 2010 which provided recommendations for the consolidation of all remaining agency data centers. In 2011, AEIT s recommendations were codified in statute and it was a Legislative directive for AEIT to provide to the Governor and Legislature any recommended changes to the schedule each year. Through the consolidation of data centers and computer facilities, cost savings have been realized. This is due to a decrease in agency personnel and a decrease in the agency data center footprint in those facilities. During consolidation, agency computer equipment was physically transported to the primary data centers. Most of this transferred equipment, including the software, had already been in operation for years within the agencies and the same equipment continues to be in operation in the SDC. Due to the age of equipment transferred from the agencies, the risk of equipment failure and loss of data stored on the machines increases every year. January 13, 2015 Page 5

7 2. Data Center Planning 2.1. Purpose In order to improve the efficiency of operations and strategically leverage cloud based infrastructure services in the State Data Center (SDC), the Agency for State Technology (AST) is proposing several financial and engineering investments into the infrastructure and architecture of the SDC services. These investments and corresponding engineering efforts in the SDC are essential to reduce costs and increase service levels by ensuring that there are stable, scalable service platforms as well as appropriate tiers of service and pricing for the different usage scenarios found within the SDC. The primary challenge AST faces is unifying the two existing data centers into a single, logical operational entity with a common service catalog as well as establishing a supportable, standardized and unified SDC architecture for the core compute, storage, backup, network and database platform service offerings. It is necessary that both data centers share a common licensing, systems management and security strategy prior to the convergence of the data center operations. The goal of the unified architecture is to provide an environment in which data and workloads become independent of the underlying physical infrastructure. This approach will enable the SDC to migrate workloads between any SDC facility. The unified architecture also meets the technical prerequisites to migrate workloads to cloud based infrastructure services in the future, where appropriate. As cloud infrastructure services mature and become less expensive, it will become necessary for the state to be able to securely leverage these services. This will not only allow the SDC to establish lower cost service tiers, it will allow the SDC to meet the future growth needs of agency workloads without having to construct additional data center facilities to handle growth. Again, the scalability provided by the unified architecture is necessary for the SDC to offer services with higher service levels while continuously driving down cost. January 13, 2015 Page 6

8 2.2. Timeline for Cloud Strategy Implementation Figure 1 The timeline for implementation of the SDC Cloud Strategy is composed of interdependent projects that encompass the evolution of the existing SDC services into a hybrid cloud enabled SDC. This includes the incorporation of Fiscal Year Legislative Budget Requests (LBR) that completes data center consolidation (DCC) and commences the future cloud strategy. 1. Application Rationalization (1/2015-7/2017) The details of this project have been outlined in the Application Rationalization (section 5) of this document. In the context of the timeline, application rationalization is a prerequisite to migrating workload from the current SDC operation into a cloud Infrastructure as a Service (IaaS) and will govern the pace at which the migration occurs. Once complete, the task of Migrate Rationalized workloads to Cloud can begin. 2. LBR for DCC equipment Refresh, Private/Hybrid Cloud Prerequisites (7/2015) As stated previously, the scope of purchases for these LBRs complete the legislative direction to consolidate legacy equipment into SDC standard platforms as well as provide uniformity to the tools and equipment within the merged SDC operations. Once the funding has been received, the implementation of Installation of LBR funded equipment can immediately begin July January 13, 2015 Page 7

9 3. Installation of LBR Funded Equipment (7/2015-1/2016) This project includes the ordering, installation and provisioning of the software and hardware procured with the Fiscal Year LBR funds. Once complete, the hardware and software will be available for use within the SDC and the Complete consolidation into SDC Compute (explained below) can begin. 4. Install and Provision Data Center Interconnect (7/2015-1/2016) This project includes the physical installation of fiber optic circuits and related equipment to meet the necessary prerequisites of engineering the convergence of the networks that exist currently at the existing SDC locations. Once installation is complete, Data Center Interconnect engineering and testing (explained below) can begin. 5. Complete Consolidation into SDC Compute (1/2016-1/2017) This project consists of the migration effort required to migrate the workloads currently hosted on legacy hardware into the SDC enterprise compute environment as outlined in section 3.1 of this document. The completion of this effort will not only allow the workloads on legacy hardware to participate in the cloud migration, it will also remove the diversity of equipment that increases the overhead of the day to day SDC operations. This project is on the critical path for the consolidation of data center facilities, migration of workloads into cloud infrastructure and the merging of the operations of the SDC operations. As a result, this project is the highest priority goal of the SDC. As the project progresses, workloads will be able to participate in the Migrate Standards compliant workloads to consolidated SDC facility (explained below). 6. Data Center Interconnect engineering and testing (1/2016-7/2016) This project includes the engineering and testing required to merge the network, enterprise compute, storage and backup platforms of the SDC locations. Once complete, the SDC will be able to operate as a single operational entity as opposed to two autonomous environments. This project will also meet the technical prerequisites to migrate workloads between the data center facilities without interrupting operations of the workloads. Once complete, the Migrate Standards compliant workloads to consolidated SDC facility can begin. 7. LBR for Hybrid Cloud Engineering and Staff Augmentation (7/2016) This LBR will request funding to meet the projected timelines for Completing Consolidation into the SDC compute, begin the engineering effort to integrate the SDC data center with cloud based infrastructure services within the Hybrid Cloud Engineering, Testing and Pilot project and complete the process development for Migrate standards compliant workloads to consolidated SDC Facility. January 13, 2015 Page 8

10 8. Hybrid Cloud Engineering, Testing and Pilot (7/2016-7/2017) This project will build the integration necessary between the current SDC enterprise compute environment and the Cloud based IaaS services available from several competing service providers. This will also create a tested migration path for workloads that are to be migrated into the cloud based IaaS services as well as train the SDC staff on the management and operations of the newly engineered Hybrid cloud environment. This process also includes the prerequisite research, Request for Information (RFI), Request for Quote (RFQ) and proof of concept testing tasks that will be the prerequisite for the Fiscal Year LBR for Cloud Services procurement as well as the Migrate Rationalized workloads to cloud project. 9. Migrate Standards compliant workloads to consolidated SDC facility (7/2016-7/2018) This project represents the migration of workloads amongst SDC facilities. All migrations will be conducted without interrupting operations, as the workloads will be migrating within the single enterprise compute environment that was merged in the Data Center Interconnect engineering and testing project. This project will also provide necessary operational experience necessary for SDC staff to begin the Migrate Rationalized Workloads to cloud (explained below) project. 10. LBR for Cloud Services based on RFI, RFQ, and results of Hybrid Cloud Testing and Pilot (7/2017) The experience gained during the Hybrid Cloud Engineering, Testing and Pilot project will produce a technical recommendation for procurement of Cloud services to be integrated into the SDC service catalog and made available to Agency customers. This LBR sets the stage for the Migrate Rationalized workloads to cloud project. A return on investment is to be realized for engineering the integration of the SDC into cloud infrastructure services. 11. Migrate Rationalized Workloads to Cloud (7/2017-7/2020) This project includes the migration and testing process for moving a logical group of applications from on-premises infrastructure into a cloud base IaaS. This process allows all eligible workloads the ability to securely leverage the lower cost and increased flexibility that cloud infrastructure services have to offer. 12. Move all remaining equipment into consolidated SDC facility (7/2018-7/2019) For incompatible workloads that cannot be integrated into the enterprise compute environment, a traditional move approach will be scoped, scheduled and conducted that will complete the migration of workloads into the consolidated SDC facility. Funding for this effort will be included in the 7/2018 LBR request. January 13, 2015 Page 9

11 The Refresh equipment purchased in 7/2015 item was added to the end of the timeline to show that the planned five year service life of that equipment will be reached in 7/2020. This provides adequate time to execute the SDC strategic plan prior to the refresh and results in an additional return on investment by resizing the refresh that occurs to support only those workloads that remain in the SDC and does not include the workloads that have been migrated into cloud based services. January 13, 2015 Page 10

12 3. Data Center Planning, including FY LBRs 3.1. Migrate Legacy Hardware into SDC Enterprise Compute (Virtualization) Figure 2 Much of the equipment currently hosted within the SDC is equipment that was relocated from agency data centers during the multi-year DCC project. This equipment represents a wide variety of hardware and software that does not meet the standards set by the SDC and is often duplicative. This variety also increases the management overhead of the equipment and software. Gartner, LPP, refers to the overhead of non-standard legacy hardware and software as Technology Debt. In order to increase the efficiency of data center operations and eliminate the service disruption risk of aging, isolated legacy hardware, it is necessary to migrate all compatible data and application workloads currently running on legacy hardware into the enterprise compute environment. Unfortunately, the storage and processing capacity that exists within the legacy hardware cannot be leveraged within the enterprise compute environment as most of the hardware is too old, unique or incompatible with the standards of the SDC. As a result, it will be necessary to expand the capacity of the storage and add additional servers and virtualization licenses to accommodate the migration. The expansion of the enterprise compute environment is represented by the items within the AST LBR #1 as outlined in Figure 2.These tasks will require an investment of SDC staff as well as coordination with agency customer resources to minimize interruption of business functions. These tasks are expected to occur between 1/2016 and 1/2017. January 13, 2015 Page 11

13 3.2. Expand Backup and Storage capacity of SDC Figure 3 Critical components of the Enterprise Computing environment include a single approach for backup and a scalable storage environment. The AST is requesting funding in LBR issue #2.1 to complete the enterprise backup initiative, which eliminates 13 different backup products, including 8 different versions of those products and over 50 different media servers that were moved into the SDC through the data center consolidation. In addition, additional storage capacity to accommodate the routine data growth of the agency data is represented by LBR issues #2.3 and 2.4. LBR issue #2.2 is to refresh the aging Storage Area Network (SAN) fabric equipment within the SDC and LBR issue #2.5 is to implement additionally needed SAN monitoring for the refreshed equipment. January 13, 2015 Page 12

14 3.3. Consolidate the Operations of the SDC Figure 4 The LBR issues that support the unification of the two existing data centers are represented in Figure 4 above. LBR Issues #3.1 and 3.3 fund the expansion of the management, monitoring and security software so that both of the SDC facilities share the same uniform approach. LBR issue #7 addresses the licensing needs of the SDC, including the necessary licenses to support the converged virtualization necessary to merge the operations of the SDC. Unifying SDC facilities will allow the SDC to migrate standards-compliant workloads between SDC facilities without interrupting services provided to agency customers. To do so, a Data Center Interconnect (DCI) is being requested in LBR issue #3.3 that will bridge the network of the SDC s two physical locations. The circuit required will be installed between 7/2015 and 1/2016, and the engineering and testing to merge the isolated networks into a single unified network will occur between 1/2016 and 7/2016. Once the networks and service platforms have been fully integrated, the stage will have been set to non-disruptively migrate workloads between the SDC facilities. Initial migrations will be SDC staff intensive and although these migrations are expected to be non-disruptive, it will still be necessary to schedule them to occur after hours and to coordinate with agency staff to test once migrations are complete. January 13, 2015 Page 13

15 3.4. Remediate Power Infrastructure at Southwood SDC Facility Figure 5 The Southwood location of the SDC will serve as the long term consolidation target for workloads that must remain in a state facility even after the integration of the SDC into Cloud based services. As a result, LBR issue #4 represents the only requested investment into a data center facility. This LBR will replace the transfer switch used to transfer power from the city power feed to generator power, should the city power feed fail. The uninterruptible power supply (UPS) equipment shown in Figure 5 and represented by LBR issue #4.3 will be refreshed in the Southwood SDC facility and is necessary to maintain power to the equipment during short term power interruptions or during the period between the failure of city power and time it takes the generator to start and stabilize the power output. The remainder of the LBR request is to replace circuit breakers that have had failures within the power distribution panels (LBR issue #4.4) as well as add metered power strips (LBR issue #4.1) that will allow granular power metering and power monitoring throughout the Southwood SDC facility. January 13, 2015 Page 14

16 3.5. Transform SDC Enterprise Environment Into Hybrid Cloud Figure 6 The integration of the SDC Enterprise platforms with commoditized third party service offerings is commonly referred to as a Hybrid Cloud approach. The establishment of the hybrid cloud architecture, which includes the engineering, testing and pilot of the hybrid cloud services is expected to occur between 7/2016 and 6/2017. The identification and rationalization of agency workloads that are eligible to migrate to these lower cost service tiers will be an effort that is expected to occur between 1/2015 and 6/2017 and is described further in Section 5 below. Once the Hybrid Cloud is built and eligible workloads have been identified and rationalized, the migration of the eligible workloads to lower cost service tiers can begin. The majority of these migrations are expected to occur between 7/2017 and early 2019 and will provide significant returns on the state s investments into the consolidated State Data Center system. The migrations of standardized, rationalized platforms between SDC facilities is expected to occur between 7/2016 and 6/2018. Once all planned migrations are complete, any remaining non-compliant workloads that require physically moving equipment, along with the corresponding service disruptions, will occur after 7/2016 and will conclude no later than early January 13, 2015 Page 15

17 4. Cloud Services 4.1 What is Cloud? The National Institute of Standards and Technologies (NIST) Definition of Cloud Computing: Cloud computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. This cloud model is composed of five essential characteristics, three service models, and four deployment models. Essential Characteristics: On-demand self-service. A consumer can unilaterally provision computing capabilities, such as server time and network storage, as needed automatically without requiring human interaction with each service provider. Broad network access. Capabilities are available over the network and accessed through standard mechanisms that promote use by heterogeneous thin or thick client platforms (e.g.,mobile phones, tablets, laptops, and workstations). Resource pooling. The provider s computing resources are pooled to serve multiple consumers using a multi-tenant model, with different physical and virtual resources dynamically assigned and reassigned according to consumer demand. There is a sense of location independence in that the customer generally has no control or knowledge over the exact location of the provided resources but may be able to specify location at a higher level of abstraction (e.g., country, state, or datacenter). Examples of resources include storage, processing, memory, and network bandwidth. Rapid elasticity. Capabilities can be elastically provisioned and released, in some cases automatically, to scale rapidly outward and inward commensurate with demand. To the consumer, the capabilities available for provisioning often appear to be unlimited and can be appropriated in any quantity at any time. Measured service. Cloud systems automatically control and optimize resource use by leveraging a metering capability at some level of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, and active user accounts). Resource usage can be monitored, controlled, and reported, providing transparency for both the provider and consumer of the utilized service. January 13, 2015 Page 16

18 Service Models: Software as a Service (SaaS). The capability provided to the consumer is to use the provider s applications running on a cloud infrastructure. The applications are accessible from various client devices through either a thin client interface, such as a web browser (e.g., web-based ), or a program interface. The consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, storage, or even individual application capabilities, with the possible exception of limited user specific application configuration settings. Platform as a Service (PaaS). The capability provided to the consumer is to deploy onto the cloud infrastructure consumer-created or acquired applications created using programming languages, libraries, services, and tools supported by the provider. The consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, or storage, but has control over the deployed applications and possibly configuration settings for the application-hosting environment. Infrastructure as a Service (IaaS). The capability provided to the consumer is to provision processing, storage, networks, and other fundamental computing resources where the consumer is able to deploy and run arbitrary software, which can include operating systems and applications. The consumer does not manage or control the underlying cloud infrastructure but has control over operating systems, storage, and deployed applications; and possibly limited control of select networking components (e.g., host firewalls). Deployment Models: Private cloud. The cloud infrastructure is provisioned for exclusive use by a single organization comprising multiple consumers (e.g., business units). It may be owned, managed, and operated by the organization, a third party, or some combination of them, and it may exist on or off premises. Community cloud. The cloud infrastructure is provisioned for exclusive use by a specific community of consumers from organizations that have shared concerns (e.g., mission, security requirements, policy, and compliance considerations). It may be owned, managed, and operated by one or more of the organizations in the community, a third party, or some combination of them, and it may exist on or off premises. Public cloud. The cloud infrastructure is provisioned for open use by the general public. It may be owned, managed, and operated by a business, academic, or government organization, or some combination of them. It exists on the premises of the cloud provider. Hybrid cloud. The cloud infrastructure is a composition of two or more distinct cloud infrastructures (private, community, or public) that remain unique entities, but are bound together by standardized or proprietary technology that enables data and application portability (e.g., cloud bursting for load balancing between clouds). January 13, 2015 Page 17

19 4.2 Cloud Service adoption considerations There are many benefits to cloud based services that are widespread across all cloud service delivery models. Cloud services are built on large scale investments made by major service providers, a broad audience of customers that are actively using and recommending improvements and extensive pool of technical resources within the customer, vendor and third party integrator community that improve the security, performance and implementation quality of the services. This scale often results in a mature, high quality service that is predictably stable, high performance and typically offered at a lower cost than a comparable on-premises solution. The pricing model of cloud services is also attractive, as services are billed based on actual utilization and capacity can be increased or decreased quickly without a capital expenditure or having to maintain excess capacity to accommodate future growth. On the other hand, certain limitations are universal across all cloud service models. The first is that cloud based services are delivered over an Internet connection. While offering ubiquitous access from the broadest array of locations, Internet based services are limited in how fast data can be transferred to and from the service. This becomes an issue when it is necessary to move large amounts of data very quickly, such as when backing up or restoring large data sets, downloading or uploading large video files, image data, or when importing large data sets into the service, as occurs when migrating into a service. This becomes an even larger issue when impacted by the second constraint, latency. Latency is a constraint of Internet based services and is introduced whenever data travels over the Internet. Latency is the time it takes for information to travel from the source to the destination service. Typically, latency is measured in milliseconds (1ms=1/1000 second). Local servers (data traveling between servers in the same physical location) can be contacted in under.5 ms (milliseconds). Metropolitan area networks (in the same city) can be accessed in 1-2 ms. Internet based services can typically be accessed in ms. While this may not sound significant, many computer to computer interactions happen thousands of times per second. If you were to increase the communication latency by a factor of 50, then the time it would take for a similar operation to occur would also be slowed down by a factor of 50, which would significantly impact the performance of the application. Obviously, it is possible to access applications over the Internet very quickly; however, the limited bandwidth and increased latency considerations must be included in the original design and implementation of the cloud based services to provide a positive outcome. Simply moving existing applications designed with local latency considerations to the cloud could immediately make the response time for those applications untenable. One final consideration of leveraging third party cloud services is the necessity to fully understand any security and privacy compliance requirements of the data that is to be hosted January 13, 2015 Page 18

20 within the third party environment. Once the compliance requirements of the data are well known, the capabilities of the potential service providers can be evaluated to ensure that migration will adhere to all necessary security and compliance requirements, such as those defined within CJIS (Criminal Justice Information Services), PCI DSS (Payment Card Industry Data Security Standards), HIPAA (Health Insurance Portability and Accountability Act), and FERPA (Family Educational Rights and Privacy Act) security policies. 4.3 Cloud Service Types Software as a service (SaaS): Software as a service is one of the most familiar cloud based service models. It can be described as renting a fully functioning application. Services such as web based , social networking sites, online forums and pre-configured websites are well known and widely adopted. In the enterprise environment, many well-known service providers offer convenient methods to displace existing applications, traditionally hosted within an onsite infrastructure. One of the most significant benefits of a SaaS service is that there is no capital expenditure required to build the service. Instead, adoption costs are isolated to the planning, migration and training logistics found in any migration to a new application. Generally, the logistics of adopting a SaaS application requires abandoning existing on-premises software and migrating all data and functionality into the hosted application. SaaS is an attractive option when evaluating the replacement of existing Commercial off-the-shelf (COTS) software. The first thing to consider when looking at a SaaS service option is the migration path and service continuity. Typically, there is an incumbent application that must have its data migrated from the existing service into the new service. Depending on the size of the data and due to the fact that all data must be migrated across an Internet connection, the migration can take weeks or even months, as seen during recent large scale agency service migrations. Migrations also must take into consideration that at any point during the migration, all customers still require full access to services being migrated and that service outages are traumatic to business operations. The second thing to consider when looking at a SaaS service is that, as with any complete migration from an existing application into a new application, the scope, training and migration issues must be well planned, adequately funded and sufficient human resources assigned to the task to ensure success. All migrations include a risk component; however, SaaS migrations typically follow a well-defined migration path that, when coupled with a mature service offering, reduces the risk of service migration. January 13, 2015 Page 19

21 The third and most constraining consideration is that customization of a SaaS application is limited to the options provided by the software vendor. While SaaS applications can be reconfigured and customized to an extent, there are typically limitations on the customization options available to modify the application to meet a specific need. Adopting an existing SaaS application may even require substantial modifications of business processes to accommodate limitations of the hosted application. As a result, the evaluation of SaaS service offerings requires an investment in extensive testing and review and potentially significant organizational change management implications must be evaluated and included in the timeline of the implementation. In a SaaS service, there is only one application that is shared among every customer, instead of the traditional approach of having a local implementation that can be broadly modified to comply with existing business processes and needs. This limitation actually has some significant benefits. Adopting a SaaS application, including the customization constraints, will ensure that future application upgrades can be provided by the vendor with minimal risk of breaking customizations implemented by the customer Platform as a service (PaaS): Platform as a Service can be described as leveraging pre-built programs and services that can be assembled to create custom applications. One well known example of an application built with PaaS services is the Florida has a right to know website. PaaS services offer significantly broader options for customization compared to SaaS service offerings and typically allow for shorter development timeframes and more predictable outcomes compared to a fully custom built application. This rapid development benefit is a result of using programming modules that are well tested, broadly adopted by a large customer base and provide predictable results. As with any custom built application, implementation requires detailed requirements, thorough planning and iterative testing to ensure that the final product will meet the needs of the customer. The typical migration approach from an existing application is to completely abandon the existing software, develop a new application within the hosted PaaS service, and migrate from the old application into the new hosted application. As with SaaS migrations, depending on the size of the data and the necessity that all data be migrated across an Internet connection, the migration can take significant amounts of time. In addition, as with any migration from an existing application into a new application, training and migration issues must be well planned, adequately funded and sufficient human resources assigned to the task to ensure success. January 13, 2015 Page 20

22 4.3.3 Infrastructure as a service (IaaS): Cloud based infrastructure as a service can be generally described as renting compute, storage, specific network services and software such as Operating Systems from a third party service provider. This service model most closely resembles the services currently provided by the SDC to the agencies. This service model also is the most compatible with the applications that exist within the state today, preserving the significant investments made in custom applications and COTS implementations. Migrating on-premises applications into a cloud based IaaS service offers additional layers of complexity not introduced during consolidations within local data centers. There are several important constraints that complicate such migrations. As with the aforementioned cloud based service offerings, the first constraint is that all migrations must occur over an Internet connection. Any and all workload that is to be migrated into a cloud IaaS service must first be virtualized and cannot be tied to a physical piece of hardware. Meeting the prerequisites of virtualization is an ongoing project of the SDC as we continue to migrate workloads from legacy hardware inherited from the agencies into the enterprise computing platforms. AST s number one priority legislative budget request addresses this necessary prerequisite. It must be noted that not all existing on-premises workload can be migrated into an IaaS service offering. Within the SDC there are numerous examples of applications that utilize hardware that is either not compatible with IaaS services or Mainframe applications that require dedicated hardware. Additionally there are applications which depend on custom appliances or components in their hardware stacks not offered by IaaS providers. Perhaps the most important constraint is that in order to migrate workloads into an IaaS service it becomes absolutely necessary to understand the interdependencies of the various applications that exist within the SDC. Due to the limited bandwidth and increased latency of an Internet connection, interdependent application components must be migrated as a single logical unit. For example, if an application dependent upon a Mainframe is migrated into an IaaS service it will now be accessing its Mainframe dependency over a network connection with a 50 fold decrease in throughput and a 50 fold increase in latency, which will significantly impact performance. These dependencies represent substantial risks requiring a significant investment into application rationalization through discovery and documentation to ensure that all related components are migrated as a single, logical unit and that anything migrated into an IaaS service does not negatively impact the performance of the application. January 13, 2015 Page 21

23 4.4 Cloud services and AST: The SDC is positioning itself to leverage cloud services in an effort to manage growth, reduce costs and expand the portfolio of services available to agencies. As the incumbent infrastructure service provider for agencies, it is in a unique position to facilitate the migration of the existing workloads into cloud based services, as deemed appropriate by the agencies through their application rationalization process. The key component to be completed by the SDC to prepare for this migration is to complete the consolidation of the existing infrastructure into a converged enterprise platform by virtualizing the workloads currently hosted on legacy hardware. Without meeting this technical prerequisite by eliminating the operational overhead and risk that this legacy equipment represents, it will be impossible to realize the benefits that a Hybrid cloud infrastructure offers. These virtualization efforts are also required as a prerequisite to migrating workload between the data centers without disrupting services which is necessary to consolidate workload into a single data center facility. For existing applications and services, it is necessary for agencies to immediately begin the application rationalization process by evaluating the business prerequisites of an IaaS cloud migration. Agencies must document their understanding of the security risk, data compliance requirements and application integration interfaces as well as the dependencies of all existing applications that are hosted within the SDC. The AST and SDC can support only some of these efforts, as the applications are owned and managed by the agencies. Once accumulated, this information can also be used to improve decisions on standardization and application refresh priority. For new applications and application rewrites, AST will carefully review requests and strongly suggest that agencies look first towards cloud based SaaS and PaaS service offerings to see if they can meet their requirements. This will ensure that no opportunities are missed to potentially minimize capital expenditures, reduce development time and provide a more predictable outcome by leveraging cloud based service offerings. 5. Application Rationalization Application Rationalization is a process. It requires the analysis of technical and functional qualities of applications within the context of a target environment, such as a cloud based Infrastructure as a Service, to determine the feasibility of migrating them into the new environment. This rationalization includes an analysis of the application architecture, data, equipment, security and licensing to ensure that the performance, security and regulatory January 13, 2015 Page 22

24 compliance is retained once the application infrastructure is migrated into the cloud. These considerations are discussed below. 5.1 Application architecture Nearly all business applications are composed of several layers of dependent components, called tiers. These tiers include client side programs, web servers, reporting servers, database servers, file servers as well as other application servers and dedicated appliances. A major component of application rationalization is mapping the dependencies between the various tiers of an application as well as understanding how they communicate with each other. Applications in a local data center (or an internal SDC cloud) are constructed to leverage owned equipment on local, high bandwidth and low latency network connections. For applications running in an external cloud, there must be a determination if the application tiers can tolerate high latency, limited bandwidth network connections. For example: 1. An application installed on an end user PC accessing a database directly over the network using a database client. In this scenario, moving the database into a cloud service would cause the application installed on the end users PC to perform extremely poorly, because the protocol used by the database client is not designed to traverse the high latency Internet connection. 2. An application accessed by an end user using a web browser. This type of application would consist of a web browser installed on an end user PC, a web server where the application is installed and a database server which holds the data used by the application. This architecture offers more flexibility to move components into an external cloud service. In this scenario, the web client will have fewer potential performance issues connecting to the web server over an Internet connection as the http protocol is designed to accommodate higher latency; however, the web server must remain very close to the database server as the protocol used by the database client is not designed to traverse an Internet connection, and performance will suffer dramatically if the latency of an Internet connection were introduced. In the second example the web server and database server become one logical group of dependent servers that could be migrated into a cloud based service without significantly impacting the performance of the application, as viewed through a web browser being used by the end user. Importantly, database servers frequently host more than one application. In this scenario, several databases serving different applications being accessed concurrently are hosted on the same shared database server. If the shared database server is moved into the cloud, all of the dependent applications must be moved as well. If any of those applications are constructed similarly to the first example above, then they can either be segregated from the shared January 13, 2015 Page 23

25 database server and left behind in the local data center, or they must be rewritten to use a protocol that can traverse the latency and limited bandwidth of an Internet connection without impacting performance. Further, although more bandwidth can always be purchased, latency can only be mitigated by reducing the distance between the endpoints. Obviously, this is not an option when hosting services in the cloud. The only options are to retain the application in the local data center or modify the application architecture (reprogram) to tolerate the additional latency. A critical component of rationalizing applications for a cloud migration is to test the application thoroughly prior to migrating the production application to the cloud. This testing may be done by temporarily duplicating an existing production environment into cloud infrastructure and undertaking end-to-end IT and end-user testing, or by artificially simulating the restricted bandwidth and increased latency within a controlled environment prior to migrating. 5.2 Data The data that flows into, out of, or is stored within an application must also be considered when migrating an application into the cloud. Part of the application rationalization process is to understand the type, source and volume of data that the application is dependent upon. Many applications import and/or export extremely large data sets on a regular basis from other related applications and data sources. Understanding the volume of data transferred into or out of an application, the time allocated for the transfers, as well as the source and destination of the data transfers will provide enough information to determine if limiting the bandwidth between the source and destination data sources will impact the operation of the application. The size of the existing data set also impacts migration timelines. Migration analysis requires careful consideration by the application architects and testing the time it will take to initially seed the cloud infrastructure with the existing data set. Extended data loading times could necessitate an outage during the migration. 5.3 Equipment Many applications are dependent upon or require close proximity to other physical pieces of hardware in order to function correctly. These hardware components can include load balancers, encryption appliances, license dongles, or even physical devices such as security panels, cameras or specific physical network interfaces. Even servers that have not yet been virtualized are still dependent upon a physical piece of hardware to function. Servers and applications that have these types of dependencies on physical devices must either be remediated or excluded from migration into cloud infrastructure. January 13, 2015 Page 24

26 5.4 Security The data that is stored and communicated between application tiers is often confidential or has specific formal compliance requirements. When applications are migrated into infrastructure that is owned and managed by a third party, it is necessary to ensure that the service provider can meet the often stringent security requirements imposed upon the custodian of the data. Compensating controls such as data encryption can be used to minimize the requirements on the service provider; however, many applications were not designed with this in mind so additional programming or engineering will be necessary to implement these measures. 5.5 Licensing Many applications are licensed based on the physical constraints of a device or server. This can include processor socket or core based licensing, physical server based licensing or even site based licensing. Introducing these license models into cloud based infrastructure often requires renegotiating the licensing models to ensure that the AST will remain in compliance with the software licenses of each application vendor. 5.6 Other Major Benefits of Application Rationalization The process of rationalizing applications is a worthwhile and necessary effort as it will provide significant benefits in addition to qualifying specific applications for use within an external cloud infrastructure. These benefits include: Completing an inventory of all application components (this does not currently exist, even within agencies) o Inventory data used to populate a configuration management database (CMDB) enabling the management of application environment baselines o Inventory data used to meet the prerequisites of implementing software asset management tools Identifying high risk application components that have: o Significant security risks o Have limited or no support from the vendor o Negligible or non-existent support for future cloud infrastructure initiatives Identifying duplicate applications or application components o What shared application components could be offered to produce the greatest benefit to the enterprise o What applications or application components would benefit most from migrating to cloud services such as PaaS and SaaS Provide information that can be used in the prioritization of application rewrites based on comparative objective criteria January 13, 2015 Page 25

27 5.7 Application rationalization and AST Most of the information necessary to undertake an application rationalization effort is application specific. Although the AST will work collaboratively with agency staff to collect the data, the effort is primarily dependent upon agency architectural resources to discover and produce the information required. These agency architects are frequently among the most indemand and time constrained resources in the agencies. In addition, much of the testing effort for applications that are migration candidates will be performed by agency staff with business knowledge of the functionality and baseline performance of the application that is being migrated. Again, these staff resources are typically heavily engaged in day-to-day work operations. As a result, in order to facilitate the application rationalization process described above in any widespread and systemic manner, third party applications and contracted staff will be necessary. January 13, 2015 Page 26