Cloud Tech Solution at T-Systems International Cloud Integration Center Executive Overview In 2009 T-Systems identified that in order for the organizational processes/products/services incorporating use of their cloud to remain effective, the technology underpinning them needed review and updating to modern standards. This included the need for providing capability to both the internal organization of T-Systems, and its partners and clients. Some of the challenges identified in the use of our virtualized environments and cloud platforms at the time included: Low Velocity: An excessive amount of internal time required from initiating a request for a new system or a change to an existing system, until it was implemented. Unpredictable Quality: High complexity of the paperwork and authorization processes attached to that. Slow Responses: The actual technical deployment was based on a custom design each and every time. Low Efficiency: Routed via multiple sequential different IT sub-organizations, each requiring time and completion by the previous organization. Low Flexibility: In addition, each consumer (internal and external) always wants custom interfaces and processes, and this caused significantly increased costs and maintenance, and resulting non-standard services. A solution was identified based on the creation and deployment of a single automated cloud interface, which enables individual views and interfaces per consuming organization and business unit (internal and external). In addition, it operates off a single central catalog, promoting selected standardized features and options to be configured into base services by the ordering organization or unit. This document provides a brief description of the solution, and how the ODCA Usage Models and Requirements were used to help foster that solution.
Table of Contents Executive Overview... 1 Objective... 4 Solution Summary... 4 Solution Overview... 6 Implementation... 6 Conceptual Architecture... 7 Technical Architecture:... 8 Important Considerations... 10 Conclusion:... 10
LEGAL NOTICE [2015] Open Data Center Alliance, Inc. ALL RIGHTS RESERVED. This Cloud Tech Solution at T-Systems International-Cloud Integration Center document (this document ) is proprietary to the Open Data Center Alliance (the Alliance ) and/or its successors and assigns. NOTICE TO USERS WHO ARE NOT OPEN DATA CENTER ALLIANCE PARTICIPANTS: Non-Alliance Participants are only granted the right to review, and make reference to or cite this document. Any such references or citations to this document must give the Alliance full attribution and must acknowledge the Alliance s copyright in this document. The proper copyright notice is as follows: [2015] Open Data Center Alliance, Inc. ALL RIGHTS RESERVED. Such users are not permitted to revise, alter, modify, make any derivatives of, or otherwise amend this document in any way without the prior express written permission of the Alliance. NOTICE TO USERS WHO ARE OPEN DATA CENTER ALLIANCE PARTICIPANTS: Use of this document by Alliance Participants is subject to the Alliance s bylaws and its other policies and procedures. NOTICE TO USERS GENERALLY: Users of this document should not reference any initial or recommended methodology, metric, requirements, criteria, or other content that may be contained in this document or in any other document distributed by the Alliance ( Initial Models ) in any way that implies the user and/or its products or services are in compliance with, or have undergone any testing or certification to demonstrate compliance with, any of these Initial Models. The contents of this document are intended for informational purposes only. Any proposals, recommendations or other content contained in this document, including, without limitation, the scope or content of any methodology, metric, requirements, or other criteria disclosed in this document (collectively, Criteria ), does not constitute an endorsement or recommendation by Alliance of such Criteria and does not mean that the Alliance will in the future develop any certification or compliance or testing programs to verify any future implementation or compliance with any of the Criteria. LEGAL DISCLAIMER: THIS DOCUMENT AND THE INFORMATION CONTAINED HEREIN IS PROVIDED ON AN AS IS BASIS. TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, THE ALLIANCE (ALONG WITH THE CONTRIBUTORS TO THIS DOCUMENT) HEREBY DISCLAIM ALL REPRESENTATIONS, WARRANTIES AND/OR COVENANTS, EITHER EXPRESS OR IMPLIED, STATUTORY OR AT COMMON LAW, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE, VALIDITY, AND/OR NONINFRINGEMENT. THE INFORMATION CONTAINED IN THIS DOCUMENT IS FOR INFORMATIONAL PURPOSES ONLY AND THE ALLIANCE MAKES NO REPRESENTATIONS, WARRANTIES AND/OR COVENANTS AS TO THE RESULTS THAT MAY BE OBTAINED FROM THE USE OF, OR RELIANCE ON, ANY INFORMATION SET FORTH IN THIS DOCUMENT, OR AS TO THE ACCURACY OR RELIABILITY OF SUCH INFORMATION. EXCEPT AS OTHERWISE EXPRESSLY SET FORTH HEREIN, NOTHING CONTAINED IN THIS DOCUMENT SHALL BE DEEMED AS GRANTING YOU ANY KIND OF LICENSE IN THE DOCUMENT, OR ANY OF ITS CONTENTS, EITHER EXPRESSLY OR IMPLIEDLY, OR TO ANY INTELLECTUAL PROPERTY OWNED OR CONTROLLED BY THE ALLIANCE, INCLUDING, WITHOUT LIMITATION, ANY TRADEMARKS OF THE ALLIANCE. TRADEMARKS: OPEN CENTER DATA ALLIANCE SM, ODCA SM, and the OPEN DATA CENTER ALLIANCE logo are trade names, trademarks, and/or service marks (collectively Marks ) owned by Open Data Center Alliance, Inc. and all rights are reserved therein. Unauthorized use is strictly prohibited. This document does not grant any user of this document any rights to use any of the ODCA s Marks. All other service marks, trademarks and trade names reference herein are those of their respective owners.
Objective This document describes T-Systems specific cloud adoption challenges, and how they were solved Solution Focus An excessive amount of time and customization effort was required before any deployment could be performed using the virtualized and cloud platforms and solutions available within the company environment. Problems included paperwork and processes for ordering, contracting, and designing each solution and its network and security access, constant customization efforts to existing solutions, and quality problems arising from passing the technical deployment ball between multiple technical specialist teams sequentially. Contributors & Companies The described problem was addressed through the cooperation of a number of parties including: T-Systems Hewlett Packard VMWare Various consuming units and customers internal and external to T- Systems Solution Summary Technical Problem Statement The specific technical problems to be addressed included: 1. Conversion of contracts into electronic policy based deployments with aligned service catalogs 2. Automation of sequential processes for cloud service deployment 3. Design of pre-defined solutions and services into deployments, each with additional features and options to select from 4. Design of customizable interfaces per contracted consumer, presenting a pre-selected range of options from the centrally defined service catalog, for the consumer to select and deploy 5. Automated activation of people based services and administration to match the requested service deployments, with matching costing 6. Integrate Private and Public cloud offerings and offer them via one interface to customers/ users, with centralized orchestration and triggering
7. Integration with the consumers IT landscape Priority of Topic with regards to T- Systems Cloud Adoption High this problem impacted costs of operation, management and deployment, as well as creating high dissatisfaction with service deployment times. Current ODCA Material Addressing this Topic Which ODCA content helped address the problem (if any): Master Usage Models: o Service Orchestration o Compute Infrastructure as a Service o Commercial Framework Usage Model o Cloud Service Broker o Long Distance Migration o VM Interoperability o Data Security o Provider Assurance o Security Monitoring o Service Catalog o Software Entitlement Management Framework White Paper o Cloud Procurement PoC o VM Interoperability Other (groups / organizations / legislators / SDO s ) o OASIS TOSCA Specification o DMTF Open Virtualization Format (OVF)
Solution Overview T-Systems created a concept called the Cloud Integration Center (CIC). The CIC consists of a framework component of portals and automation tools, and then contents which include the actual services available within and deployable via the CIC. It leverages the concepts from the various ODCA Usage Models mentioned elsewhere in the document as guiding the core solution and process requirements. Many of the specific requirements specifications for the CIC came from the ODCA Service Orchestration Usage Model, the Security Usage Models, the Interoperability Usage Models, the Service Catalog, and the Commercial Framework Usage Model. These provided an initial wireframe of functionality, common processes, and specific requirements, around which the solution itself could be built. Other Usage Models and requirements were then incorporated into the solution as required, such as the data security requirements. The CIC is now defined as the whole framework consisting of processes and IT systems that support the onboarding, ordering, delivery and consumption of cloud services offered by T-Systems and its partners. The focus of the CIC includes: Customer self-managed services that enable customers to deploy virtual machines (VM) for use as IaaS These VM s are based on software images that contain any type of application software (e.g. JBOSS Application Server, Apache Web Server, etc.). The image may be pre-configured by T-Systems, or even provided by the customers themselves. This offers the potential for customer applications to be made available for cloud-like consumption. Managed services, whereby the customer only has to be concerned about use of, and not backend operations, of services These are usually offered as PaaS or SaaS offerings. They include automated monitoring, lifecycle management, operations and administration, and also include features and options such as backup retention periods, software module additions, clustering, high availability, disaster recovery, etc. In general, these services are offered as pre-defined services and ready for immediate use. Proprietary applications can also be migrated into the framework for offering as available standard content offerings to preselected or to general audiences. A network connection is all that is needed for a secure link between the CIC and the customer. The services can be individually scaled according to defined units, and billing is on a pay-as-you-go basis. Implementation It took about 1.5 years of real time to build the solution, and this included two aspects approximately 30 people to build the framework (including project management, etc.), and about 40 people to build the initial content services that were published via the framework. Parallel to the projects are the audits, certifications, testing, and ongoing architecture evolution, etc. 1. Initial Phase: Build the framework, reporting, billing and service desk integration, monitoring and management integration, ITIL processes, and use case-based processes. 2. Platform Phase: Integrate the first resource provider (IaaS provider). 3. Self-Managed App Phase: Design, package and script the initial applications to be deployed as appliances. 4. Managed App Phase: Design the services, algorithms, scripting, rules, and topologies for managed applications. 5. Roadmap Phases: Add additional resource providers, self-managed and managed content services, and additional features and functions.
Conceptual Architecture The CIC framework is constructed of three layers, with specific capabilities delivered by each layer: Consumption Layer: presents services to customers through a catalog. This enables them to have control over deployments according to a governance framework. It enables a standard product to be centrally administered, supplemented by customer specific parameters, aligned to their requirements. Functionalities of this layer include: Customer specific cloud portal interface (and API) to manage service subscriptions by business and IT Ordering and approval workflows Catalog and service management Cloud service designer Authorized roles to publish and manage own services Reporting on deployments The Consumption layer is the only layer to which the customer has access. Some of the functions are restricted to certain T-Systems personnel which align services to the defined processes for service management. Service Delivery Layer: converts service requests into work packages for Orchestration. This helps the T- Systems technical organization to support and administer the service at the infrastructure layer. Access to this layer is restricted to T-Systems administrative personnel. Functionalities in this layer include:
Automated Service Provisioning Orchestration of middleware, web and database services Orchestration of appliances, complex server farms and configurations, and IT landscapes Implementation of cloud service management lifecycle Integration of cloud services into enterprise IT environments (e.g. security, network etc.) Infrastructure Layer: The deployment of systems occurs within the infrastructure layer, simplifying the complexity by automation of orchestration. This layer provides a high level of standardization and automation, and ensures cost effective operations as well as resilient and re-usable cloud assets. As with the Service Delivery layer, access to this layer is restricted to T-Systems administrative personnel. Functionalities in this layer include: Support all underlying cloud platforms Multi-cloud provider support Multi-hypervisor support Operation and management of hybrid cloud services Migration of services between clouds Services are decoupled from the infrastructure at the infrastructure layer. This is addressed by a component called the resource provider, which is an instance specification of the resource offering. A resource offering encapsulates a standardized model to manage one or more categories of resources and exposes a programmatic interface to consume those resources. Resources in this case may be servers, storage, networks or any other resource required in order to fulfill a request model to a business service. Technical Architecture The technical design is described as follows, and includes the use of both T-Systems existing ITIL, CMDB, Monitoring tools, and HP CSA, HP OO and HP SA, amongst others:
Mutli-tenant Deployment: Some of these components are implemented centrally, and others are duplicated per customer. In both cases the backend components are all managed by T-Systems. The customers access is limited to their individual CIC Customer Portal. Centralized components include: HP CSA Controller: software that provides program functions necessary to execute complex lifecycle tasks and to orchestrate the timely delivery of services to customers. It contains the HP CSA lifecycle engine, plus customized flows and sample templates for the service lifecycle. It interacts with the HP OO to execute lifecycle actions by means of OO flows. HP SA Core: a set of core components that co-operate to discover servers on the network, add those servers to a managed server pool, and provision, configure, audit and maintain those servers. HP SA Satellites: consisting of a software repository cache and a satellite gateway to manage servers at a remote facility. The software repository cache contains local copies of software packages to be installed on managed servers in the satellite while the satellite gateway handles communication with the HP SA Core. HP OO Central: includes the flow engine that executes the orchestration flows (linked actions that automate specific IT tasks) and also provides an administrative interface to manage users and flows. HP OO Remote Access Service (RAS): server for access to the management zones in the T-Systems dedicated administration network. Customer specific components include: HP OO RAS: for separated access to each customer network Managed Nodes: includes HP SA Managed Server Agent that is installed on servers to be managed through HP SA. After an agent is installed, it registers with the HP SA Core which can then add that server
to its pool of managed servers. The agent also receives commands from the core and initiates the appropriate action (e.g. software installation and removal, server status reporting). The above elements promote the ability of complete landscapes to be built, based on pre-determined algorithms, directly linked to a few simplified customer selected sliders e.g. number of users, number of data sources etc. As the landscape is built, so the services are compiled into it, and the people resources allocated for administration, operations, etc. Services include full SaaS elements like an Enterprise Search environment, or a Sharepoint environment or similar, which includes database, web, application, infrastructure, network and storage components. Today there are multiple services available in the SaaS, PaaS and IaaS layers. These range from the typical Microsoft products to Open Source and ISV provided services, from big data through service desk, tracking systems, and monitoring solutions. Important Considerations Benefits & Considerations in this solution Detail Advantage 1 Multiple cloud offerings and platforms can be provided to the consumer via one interface, and managed, orchestrated, and secured similarly. Advantage 2 A single cloud catalog is defined, which includes base offering, service options and service extensions, which can then be pre-filtered and even preconfigured for the customer by their IT and risk management teams Disadvantage 1 Every time a cloud provider who is integrated as a resource provider changes their API or offering, the whole catalog has to be updated and all service designs associated with that provider, updated. This includes both technical and commercial dimensions Limitation 1 Cloud offering can only be integrated if they have a defined resource provider interface such as an API in front of them. They must also be standardized and defined to specific units with a range of scalable configurations Conclusion Through the development of the Cloud Integration Center, T-Systems was able to harness and consolidate multiple runaway developments, and place them in front of the customers via a single unified interface. This allowed for coherent billing, contracting, operations, processes, and administration. It also promoted significantly improved cost control behind services, and strategic decision making in context of which key gaps (regarding service content)
exist in the offering available to customers in a large enterprise. This, in turn, promotes focused innovation and development investment looking forward, rather than constantly trying to re-coordinate multiple streams according to corporate requirements in a reactive way. About The Open Data Center Alliance The Open Data Center Alliance, Inc. is an independent consortium of global IT leaders who have come together to provide a unified customer vision for long-term data center requirements. The organization is led by a Board of Directors who are selected from its 15-member Steering Group Participant members, which include representatives from BMW, Capgemini, CenturyLink, China Unicom, Deutsche Telekom/T-Systems, Infosys, Intel, National Australia Bank (NAB), NTT Data, SAP, The Coca-Cola Company, UBS, and Verizon. More information about ODCA publications and membership can be found at the organization s website at www.opendatacenteralliance.org.