Implementation and Usage Aspects of a Private JEE Cloud · JEE PaaS Proof of Concept Some Design...

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 Proof of Concept Some Design Details

January, 2013 Peter Schnorf, Platform Service Architecture slide 2

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


Standardize Build once Automate Reuse

CS Platform Set of integrated technical components, processes, and guidelines for application development and operation

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)

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


Cloud Computing at Credit Suisse - Deliver in Platform Offerings


SharePoint Microsoft

JAP* Java EE WebLogic

DWH* Oracle

DAP* .NET

Mainframe* IBM DHP*

Oracle, SQLServer, Sybase CHP*

Linux (RedHat) Windows CSV

ESX Hypervisor

Software as a Service

(SaaS)

Applications Applications

Platform as a Service

(PaaS) Application Platform

Database Hosting Platform

Application Platform

DB Hosting Platform

Infrastructure as a Service

(IaaS)

Compute Hosting Platform

Hardware

Compute Hosting Platform

Hardware

* CS Platforms

General Cloud Characteristics*


• self-service • rent/return capacity • pay as you go

• process automation • sharing/virtualization • standardized machines & stacks

• rapid provisioning • elasticity for applications • measured usage

Data Center

Services

Clients

* NIST: High Scalability, Rapid Elasticity, Sharing and Multi-Tenancy, Measured Usage, Self-Service On-Demand

by Amazon, Google, Microsoft, etc.

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

perfect distribution (all requests divided by number of time intervals)

peak of sums

Importance of Standardization


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')

Use Cases – Order Capacity in Dev/Test

Case: Order capacity in dev/test Consequences

• 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

• 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 pre-provisioning

• 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 siz ing support (tbd.)


PoC Demo – Order/Provision JAP Blueprint


HW/ESXi

HW/ESXi

... HW/ESXi

HW/ESXi

HW/ESXi

HW/ESXi

HW/ESXi

HW/ESXi HW/ESXi

Oracle RAC node

WLS/ RHEL

DB

PoC: Order/Provision Blueprint – What is Happening?


Presentation Tier

Test Zone

Business Tier

Intranet

Client Tier HTML

Data and Service Tier DHP Databases

ServiceBus synchronous, asynchronous, bulk services

Internal Applications

Strong Authentication *

Enterprise Beans

Servlets

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)

CHP node

PoC Setup


Data Center Test Zone JAP Cloud VMs

Load Balancer

VM

iDesktop

Eclipse

Web Browser

ESXi servers

HTTPS

HTTPS

Test Client HTTPS

JAP WLS on

CHP Linux VM

WLS on RedHat

Linux VM

…

JAP WLS on

CHP Linux VM

WLS on RedHat

Linux VM

…

JAP WLS on

CHP Linux VM

WLS on RedHat

Linux VM

…

Oracle RAC on

CHP Linux VM

Oracle RAC on RedHat

Linux VM …

Presentation Business/ Service

Data

WS JAP

WLS on CHP

Linux VM

WLS on RedHat

Linux VM

…

WS

HTTPS VMwarevCenter Server

VM

Oracle on RedHat

Linux VM

SSH SCP etc.

JDBC

PoC Demo – Deploy App to Blueprint


PaaS IaaS

manage entire blueprints manage single, unrelated VMs

rely on IaaS for capacity mgt → provide planning input to IaaS

capacity mgt of large server park → support different classes of reqs

horz. elasticity per application → capacity range as hint to IaaS

horz. elasticity within server park → minimize free pool

HA in middleware

HA on HW, hypervisor or OS level

IT DR in middleware IT DR in hypervisor and storage

monitoring & logging for PaaS components

monitoring & logging for IaaS components (hypervisor, OS, ...)

high-level measurements → # requests, E2E

low-level measurements → CPU, memory, I/O

manage PaaS CMDB items → blueprints & PaaS specific components

manage IaaS CMDB items → VMs & IaaS specific components

Design Details – Layering


events

JAP components & blueprints

CHP components & VMs

Web services

PaaS (e.g. JAP)

IaaS (e.g. CHP)

IaaS CMDB

PaaS CMDB

example WS: JAP order • single JAP VM • fixed-size memory • server anti-affinities • DC affinities • no HA • no IT DR

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'


Cloud is More than Virtualization! Impact for Application Development


Cloud Aspect Paradigm Shift for AD

Resource abstraction towards clients (compute, storage, and network resources)

– 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

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


Q & A


Implementation and Usage Aspects of a Private JEE Cloud · JEE PaaS Proof of Concept Some Design...

Documents

Transcript of Implementation and Usage Aspects of a Private JEE Cloud · JEE PaaS Proof of Concept Some Design...