Implementation and Usage Aspects of a Private JEE Cloud

Transcription

1 Implementation and Usage Aspects of a Private JEE Cloud SI-SE 2013 Peter Schnorf, Platform Service Architecture January, 2013

2 Content CS Platform Concepts Cloud Context Design Work for a Private JEE PaaS Proof of Concept Some Design Details Peter Schnorf, Platform Service Architecture January, 2013 slide 2

3 CS Platforms 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, Platform Service Architecture January, 2013 slide 3

4 CS Platforms Benefits Benefits of standardization and upfront investment in infrastructure stack/processes Objectives Design, build and test standard infrastructure stack (including middleware) once Sharing the stack : Amortize over many applications Standardize interfaces between applications and infrastructure Design well-defined, highly automated processes using standardized ecosystems Strict release and whole platform lifecycle management (all components/processes at once) Global availability Benefits Lower cost Reduced development, maintenance, and support cost for applications and infrastructure Better quality Increased infrastructure and application stability Lower risk No end-of-life technologies and components in data center Increased application security Reduced development risk Enhanced capability Shorter time-to-market Global deployment of applications Peter Schnorf, Platform Service Architecture January, 2013 slide 4

5 Cloud Computing at Credit Suisse - Deliver in Platform Offerings Software as a Service (SaaS) Platform as a Service (PaaS) Infrastructure as a Service (IaaS) Applications Application Platform Database DB Hosting Hosting Platform Platform Compute Hosting Platform Hardware JAP * Java EE WebLogic SharePoint Microsoft DWH * Oracle DHP * Oracle, SQLServer, Sybase CHP * CSV ESX Hypervisor DAP *.NET Mainframe * IBM Linux (RedHat) Windows * CS Platforms Peter Schnorf, Platform Service Architecture January, 2013 slide 5

6 General Cloud 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 by Amazon, Google, Microsoft, etc. * NIST: High Scalability, Rapid Elasticity, Sharing and Multi- Tenancy, Measured Usage, Self-Service On-Demand Peter Schnorf, Platform Service Architecture January, 2013 slide 6

7 Sum of Peaks vs. Peak of Sums Example: JAP Requests on a Typical Day Number of HTTP requests in current JAP (prod in CH) sum of peaks: ~fixed allocated capacity today peak of sums: ~dynamically allocated potential capacity peak in JAP Cloud sum of peaks peak of sums perfect distribution (all requests divided by number of time intervals) Peter Schnorf, Platform Service Architecture January, 2013 slide 7

8 Importance of Standardization Peter Schnorf, Platform Service Architecture January, 2013 slide 8

9 JAP Cloud Design Phase Goals: provide conceptual basis for next major release establish mind set and agree on vision and use cases develop concepts and proof of concepts trial migrations of applications look at market, including vendor contacts Working group Broad participation: Operation System Engineering IT Architecture Application Development PoC Test bed for: trying out of engineering and operation concepts/ideas first application migration studies Web services and GUI protoype Some Principles and Guidelines Standardization enable efficient implementation/operation while supporting needed features for application delivery Very fast provisioning enable elasticity in production and agile development for faster time to market and less cost Use case oriented pursue low hanging fruit along requirements Radical simplicity avoid complexity, do not try to optimize the last 10-20% in the beginning Independence local decisions at deploy time, i.e. avoid dependencies on central infrastructures for speed and reliability Automation and self-service reduce manual operation and pass some control to developers for speed and reliability, Service APIs design infrastructure services (WS) for clean structure, separation of concerns, and programmatic automation Reproducibility support fully reproducible orders for automated grow/shrink in production and prescribed releasing of development infrastructure during periods of inactivity ('elasticity in the large') Peter Schnorf, Platform Service Architecture January, 2013 slide 9

10 Use Cases Order Capacity in Dev/Test Case: Order capacity in dev/test self-service order entire blueprints along JAP reference architecture incl. presentation, business, and data tier interactively or programmatically specify elasticity requirements simplified specification choices only very fast order fulfillment (seconds/minutes) blueprint specifications can be stored/reloaded sizing to be established interactively by client (non trivial) but help for that process is offered result: number of virtual servers running order compliant JEE or DB stack ready for application component deployment Consequences need pre-provisioning of servers for very fast self-service and elasticity tests need pre-assembly and pre-provisioning of VMs with full infra stack or template cloning need capacity planning for optimized preprovisioning need automated capacity and placement management at provisioning time for self-service and elasticity with affinity constraints need automated inventory for automated capacity/placement management and storage of blueprint specifications need simplified client choices to enable simplified management algorithms/processes need technical sizing support (tbd.) Peter Schnorf, Platform Service Architecture January, 2013 slide 10

11 PoC Demo Order/Provision JAP Blueprint Peter Schnorf, Platform Service Architecture January, 2013 slide 11

12 PoC: Order/Provision Blueprint What is Happening? Internal Applications Order: 2 presentation tier nodes (not on same HW) 2 business tier nodes (not on same HW) 1 Oracle DB in RAC (with HA on RAC) Strong Authentication * Client Tier Presentation Tier Intranet HTML Servlets WLS/ RHEL HW/ESXi HW/ESXi HW/ESXi... HW/ESXi Business Tier Test Zone Enterprise Beans HW/ESXi HW/ESXi HW/ESXi Data and Service Tier ServiceBus synchronous, asynchronous, bulk services DHP Databases HW/ESXi HW/ESXi DB Oracle RAC node Peter Schnorf, Platform Service Architecture January, 2013 slide 12

13 PoC Setup CHP node Test Client Eclipse Web Browser idesktop HTTPS HTTPS Load Balancer VM HTTPS HTTPS Presentation JAP WLS WLS on on RedHat CHP Linux Linux VM VM JAP WLS WLS on on WS RedHat CHP Linux Linux VM VM Business/ Service JAP WLS WLS on on RedHat CHP Linux Linux VM VM JAP WLS WLS on on RedHat CHP Linux Linux VM VM Data Oracle Oracle RAC RAC on on RedHat CHP Linux Linux VM VM SSH SCP etc. JDBC WS VMwarev Center Server VM Data Center Test Zone JAP Cloud VMs Oracle on RedHat Linux VM ESXi servers Peter Schnorf, Platform Service Architecture January, 2013 slide 13

14 PoC Demo Deploy App to Blueprint Peter Schnorf, Platform Service Architecture January, 2013 slide 14

15 Design Details Layering PaaS IaaS PaaS (e.g. JAP) manage entire blueprints rely on IaaS for capacity mgt provide planning input to IaaS horz. elasticity per application capacity range as hint to IaaS HA in middleware IT DR in middleware manage single, unrelated VMs capacity mgt of large server park support different classes of reqs horz. elasticity within server park minimize free pool HA on HW, hypervisor or OS level IT DR in hypervisor and storage JAP components & blueprints example WS: JAP order single JAP VM fixed-size memory server anti-affinities DC affinities no HA no IT DR PaaS CMDB monitoring & logging for PaaS components monitoring & logging for IaaS components (hypervisor, OS,...) Web services events high-level measurements # requests, E2E manage PaaS CMDB items blueprints & PaaS specific components low-level measurements CPU, memory, I/O manage IaaS CMDB items VMs & IaaS specific components CHP components & VMs IaaS (e.g. CHP) IaaS CMDB Peter Schnorf, Platform Service Architecture January, 2013 slide 15

16 Design Details Automation Characteristics Typically a workflow calling a series of coarse-grain steps (which call more fine-grain steps,...) Very limited possibility to react to individual step failures The more involved infrastructure parts the higher the risk of failures Individual steps may take a long time Inventory must adequately reflect actions taken Stability and well defined results are vital Must sustain high load Possible Consequences Use orchestration tool or programmatic logic calling well defined infrastructure services (typically Web Services) Use design guidelines/governance/repository for layering/syntax/semantics of infra services (SOA) Deliver services as part of Platform releases (following Platform life cycle) Use asynchronous calls (with persistence) wherever possible Design for step outcomes like: 'finished ok', 'cancelled and cleaned up', 'will finish eventually' Use design to avoid need for atomicity (there cannot be transaction guarantees) Avoid serialization of long running steps, design for parallelism Provide 'undo' action of workflows (and individual steps if possible) for worst case scenarios Provide reporting, notification, and control services for actions that will 'eventually finish' Peter Schnorf, Platform Service Architecture January, 2013 slide 16

17 Cloud is More than Virtualization! Impact for Application Development Cloud Aspect Resource abstraction towards clients (compute, storage, and network resources) Paradigm Shift for AD Order capacity instead of HW Choose from simple, standard options Make no assumptions about placement (e.g. host names) Rapid provisioning with self-service Test early, test often, explore Test individually in entire application context Rapid prototyping early business feedback Reproducible provisioning, configuration & deployment (persistent specifications with infrastructure service APIs) fully automatable test cycles (provision & build test env, run tests, decommission test env) quickly reproduce production problems in UAT exploit horz. elasticity in production Rental model (pay as you go) Significantly lower entry cost (start small and quick) Order and pay only what you need Return what you currently do not need anymore Elasticity (grow and shrink capacity on demand) Horizontal scalability Statelessness Fast startup, graceful shutdown of components Peter Schnorf, Platform Service Architecture January, 2013 slide 17

18 Summary (Internal Cloud) 'Cloud' is much more than technology: design, processes, guidelines, governance Benefits vary from IaaS to PaaS but are always in the big picture, i.e. for large parts of the company and not for single, individual projects alone No Cloud without standardization, restriction, simplification, automation, size and overall design fit applications to cloud and support them with novel services Biggest obstacle: inertia in organization traditional mind set ('we always did it like that') not invented here ('we know ourselves what is best') open or implicit resistance ('I do not help to optimize my job away') Use external references as benchmark, use external help if necessary to overcome internal inertia Have a strategy based on top-down design and main use cases Peter Schnorf, Platform Service Architecture January, 2013 slide 18

19 Q & A Peter Schnorf, Platform Service Architecture January, 2013 slide 19