Goals, Difficulties, and Good Practices when Building an Internal Cloud. Peter Schnorf, Infrastructure Architecture

Size: px

Start display at page:

Download "Goals, Difficulties, and Good Practices when Building an Internal Cloud. Peter Schnorf, Infrastructure Architecture"

Preston Sherman
8 years ago
Views:

1 Goals, Difficulties, and Good Practices when Building an Internal Cloud Peter Schnorf, Infrastructure Architecture

2 No, we do not have an internal cloud! Thank you for your attention! Peter Schnorf, Infrastructure Architecture, Automation & Integration October, 2014 slide 2

3 Credit Suisse IT Standardization and Governance IT Architecture For About 15 Years IT as business partner: CIO reporting to CEO Architecture governance Institutionalized project review (veto power) Strong involvement of Architecture in project steering and control (budgeting, design, purchases) Budget sponsorship for 'change' projects Single, global CTO reporting to single CIO Driven by Architecture: Technology management - one product per function, 2 vendor strategy for commodities Driven by Architecture: CS Platforms - layered standardization of stacks and processes Several mergers: most importantly Private Bank & Retail Bank and later with Investment Bank Peter Schnorf, Infrastructure Architecture, Automation & Integration October, 2014 slide 3

single CIO Driven by Architecture: Technology management - one product per function, 2 vendor strategy for commodities Driven by Architecture: CS Platforms - layered standardization of

4 CS Infrastructure Architecture Strategy (~10 years ago) high-level platforms & services individual components custom building only where cost-effective integrated platforms with processes & services (internal & external) mostly internally standardized components fully commoditized industry standards standard special outsourced standard special Separate out and reduce amount of special engineering Increase amount of commoditization and outsourcing only commit capital where we want to differentiate ourselves Decrease number of components, standardize with minimal redundancies Increase amount of life-cycle managed platforms with processes and services Peter Schnorf, Infrastructure Architecture, Automation & Integration October,

reduce amount of special engineering Increase amount of commoditization and outsourcing only commit capital where we want to differentiate ourselves Decrease number of components,

5 CS Platforms - Overview Standardize, build once, automate and reuse Application Specific Logic GUI, Business Logic, DB Schemas, Configuration, etc. Infrastructure Design/Configuration HW, OS, Middleware, Network System Management setup and processes Operating manual Development tools and processes Security concept and processes Integration concept and processes CS Platform Set of integrated technical components, processes, and guidelines for application development and operation Standardize Build once Automate Reuse Application Platform (AP) Specialized for similar applications, built on hosting platforms (Java EE, DotNET, Data Warehouse, Mainframe PL/1) Hosting Platforms Provide generic services (Computation, Persistence) Peter Schnorf, Infrastructure Architecture, Automation & Integration October, 2014 slide 5

concept and processes CS Platform Set of integrated technical components, processes, and guidelines for application development and operation Standardize Build once Automate Reuse Application

6 The World Listened...!!! Peter Schnorf, Infrastructure Platform Architecture June, 2014 slide 6

7 Tower 4/5 Tower 1/2 Release 5 Release 4.1 Release 4.0 Release 3 Release 2 CS Platforms Strategies, Governance, Features Strategies Everybody must go to CS platforms Mainframe PL/I replacement is JAP Governance (with exception process) Every project is reviewed Architecture consulting Contract between Infra and AppDev divisions Important characteristics Life cycle/release mgt Reference architectures Business case SLAs, toolchains, security, trx processing Applications Infrastructure SW Components Core OS OS Core Version 1 OS Core Version 2 OS Core Version Hardware Application A Release Application 1 A Release Application 2 A Release Component A Version Component 1 A Version Component 2 A Version Application B Release Application 1 B Release Application 2 B Release Component B Version Component 1 B Version Component 2 B Version Application.. Release Application 1.. Release Application 2.. Release Component... Version Component 1... Version Component 2... Version Server Model 1 Server Model 2 Server Model Uncoordinated lifecycles in technical stack Combinatorial explosion of dependencies, support, and maintenance costs Client Tier Entry Tier Platform Release Mgmt. Internal Applications Strong Authentication * Web Pages Applications Platform Infrastructure SW Components Intranet Hosting Core OS Virtualization Hardware Application A Release Application 1 A Release Application 2 A Release CHP Release 1 Component A Version 1 Component B Version 1 Component C Version 1 OS Core Version 1 Server Model 1 Server Model 2 Application B Release Application 1 B Release Application 2 B Release CHP Release 2 Component A Version 2 Component B Version 2 Component C Version 2 OS Core Version 2 Server Model 2 Server Model 3 Application.. Release Application 1.. Release Application 2.. Release CHP Release 3 Component A Version 3 Component B Version 3 Component C Version 3 OS Core Version 3 VM Layer Version 1 VM Layer Version 2 VM Layer Version 3 Server Model 3 Server Model 4 Managed stack No dependency explosion, increased stability, capacity management, less maintenance costs, less support JSF Web Pages Pages JSF Pages Internet facing Applications Customer Strong Authentication Entry Server Public Anonymous Web Pages Internet Entry DMZ Presentation Tier Servlets JSF Servlets Pages DMZ Servlets 200 Business Tier Enterprise Beans Enterprise Beans DMZ Public Data and Service Tier CSXB synchronous, asynchronous, bulk services DHP Databases CH: SeSZ/BaSz RoW: Intranet DHP Databases DMZ Public Data 50 0 Jan-05 Mar May-05 Jul-05 Sep-05 Nov-05 Jan-06 Mar-06 May-06 Jul-06 Sep-06 Nov-06 Jan-07 Mar-07 May-07 Jul-07 Sep-07 Nov-07 Jan-08 Mar-08 May-08 Jul-08 Sep-08 Nov-08 Jan-09 Mar-09 May-09 Jul-09 Sep-09 Nov-09 Jan-10 Peter Schnorf, Infrastructure Architecture, Automation & Integration October, 2014 slide 7

reviewed Architecture consulting Contract between Infra and AppDev divisions Important characteristics Life cycle/release mgt Reference architectures Business case SLAs, toolchains, security, trx

8 Cloud Overview Characteristics * Clients self-service rent/return capacity pay as you go Services rapid provisioning elasticity for applications measured usage Data Center process automation sharing/virtualization standardized machines & stacks * NIST: High Scalability, Rapid Elasticity, Sharing and Multi- Tenancy, Measured Usage, Self-Service On-Demand Peter Schnorf, Infrastructure Architecture, Automation & Integration October, 2014 slide 8

standardized machines & stacks * NIST: High Scalability, Rapid Elasticity, Sharing and Multi- Tenancy, Measured

9 Importance of Standardization Peter Schnorf, Infrastructure Architecture, Automation & Integration October, 2014 slide 9

10 Small, Medium, Large Peter Schnorf, Infrastructure Architecture, Automation & Integration October, 2014 slide 10

11 No Cloud, 'just' Virtualization Examples (illustrative purposes only: some date back years, happened only once, were just ideas, etc.) 'Short-term' test VMs are provisioned quickly and deleted automatically after 4 weeks operational in hours but usable only after 3 weeks Institutionalized process to move an application from 'Production Test & Acceptance' stage to 'Production' stage contains an explicit step to 'wait 2 weeks' Institutionalized provisioning process contains a final step of 1-2 days to have humans check the delivered VM for correctness Self-service to order a fully standard Linux VM takes ~10 weeks, costs ~3000 CHF out of project budget, and involves ~12 teams doing manual work 'Developer sandpit': decent self-service for test VMs order your own HW servers, do your own capacity mgt, no SLAs Central inventory for installed HW and SW does not contain reliable info about which applications run on a server VMware hypervisor clusters HA VMs are offered but this 'only' means that if a VM goes down due to a HW failure it gets started with initial state on a different server partitioning the DC into clusters of a few machines defeats the 'economy of scale', no capacity mgt per cluster, no HA guarantees Peter Schnorf, Infrastructure Architecture, Automation & Integration October, 2014 slide 11

'Production Test & Acceptance' stage to 'Production' stage contains an explicit step to 'wait 2 weeks' Institutionalized provisioning process contains a final step of 1-2 days to have humans check

12 CS Internal +/- + Powerful IT governance over years Powerful CIO reporting directly to CEO Single, global CTO reporting directly to CIO Strong involvement of Architecture in project steering and control (budgeting, design, purchases) + Recognized importance of Standardization and of Processes early on + Very successful, highly standardized product (Application Platforms) envy of the industry & guidance for product vendors + Successful virtualization and standardization of basic compute stack + Partially successful technology management - Mergers (most importantly PB and IB) - Weakened IT governance today 3 divisions (2 Application Development, 1 Infrastructure) each with its own CIO CIOs reporting to CFO (cost control as major focus) 3 CTOs (one per division) - Never resolved common operation model Fundamentally diverse process landscape - Never resolved common technology governance Many products sneak in without control Applications do not migrate, old products are not phased out Peter Schnorf, Infrastructure Architecture, Automation & Integration October, 2014 slide 12

industry & guidance for product vendors + Successful virtualization and standardization of basic compute stack + Partially successful technology management - Mergers (most importantly PB and IB) -

13 And Now? Automation is key Complexity is not automatable Enablers: standardization & simplification Obstacles: inertia of organization & huge weight of legacy/diversity Create new, isolated IaaS environment in parallel Minimal, fully automated, enterprise features Strong governance for sustainable top-down design Strong governance for implementation Reuse/adaption of tools & process abstractions Strong incentives to migrate grow in size & features (in a very controlled way) Peter Schnorf, Infrastructure Architecture, Automation & Integration October, 2014 slide 13

legacy/diversity Create new, isolated IaaS environment in parallel Minimal, fully automated, enterprise features Strong governance for

14 Yes, we will have an internal cloud! (eventually) Thank you for your attention! Peter Schnorf, Infrastructure Architecture, Automation & Integration October, 2014 slide 14

Implementation and Usage Aspects of a Private JEE Cloud

Implementation and Usage Aspects of a Private JEE Cloud SI-SE 2013 Peter Schnorf, Platform Service Architecture January, 2013 Content CS Platform Concepts Cloud Context Design Work for a Private JEE PaaS