© 2009 VMware Inc. All rights reserved

Confidential

Migrating Java Applications from Weblogic to vFabric Cloud Application Platform “Start your Journey to PaaS”

CAP2194 - An end to end case study

Thirumalesh Reddy, VMware

Rama Kanneganti, HCL

2 Confidential

Migrating from Weblogic to vFabric - Opening Remarks

Cloud Application Platform – Start your journey to PaaS

Migration has real business benefits

• Increased agility and reliability

• Reduced deployment downtimes

• Scales to future growth

• Reduced Cap-Ex and Op-Ex costs

• Reduced Hardware Footprint

• Highly adaptive to business and customer needs

3 Confidential

Migrating Java Applications from Weblogic to vFabric

Agenda• Rationale for migration

• Steps in migration

• Taking advantage of the new platform

• Concluding Remarks

4 Confidential

Problem Context

Enterprise custom Java applications are expensive and complex to build, deploy, scale and manage

Typical problems:

• Development

• Obsolete toolkits and no clear choice of toolkit (Struts, anyone?)

• No fully integrated stack resulting in lack of control and risk

• Operational

• Lack of support for developer-friendly tools

• Lack of industry and community

• Industry

• Shortage of skill sets

• Fragmented market space leading to uncertainty.

VMware problem: Higher % of downtime leading to poor customer satisfaction; and high cost of development and operations

5 Confidential

More details on the VMware problem

VMware IT

Business expects agility, reliability and lower costs…

… but I have performance, instability, manageability monitoring and analyzing issues with current platform!

We used to own the servers running our apps. Now we don’t know if the apps can get the resources they need to run well.

We’ve spent a fortune on monitoring tools. Why are our end users still the first to know about performance problems and why do they take so long to solve?

… what is needed is a scalable, robust, and manageable platform that is built on modern tools and technologies!

faster service execution at lower cost…

6 Confidential

Why migrate?

General solution to our problem: Migrate to a new platform.

Constraints:

• Retain functionality

• Address perceived issues

Creating a business case

• Due to platform issues there is a high cost for

• downtimes

• ad-hoc fixing of problems

• not having the right monitoring tools

• development with a disparate technology stack.

• hardware costs to scale with complex resources intensive application servers

• Migration Costs

• new platform creation

• code migration

• cost of testing

7 Confidential

Sample Business case template

Migration of technology stacks is an IT ask• Challenge: Creating a business case with quantitative and qualitative benefits/outcomes

with supporting data and a cost model with the projected cost savings.

Core value proposition: Increase the availability and resiliency and reduce development and operational costs.

Our Business case:• Quantitative:

• Reduce ongoing development and operational costs by 15%• Reduce hardware costs by 30%• Reduce downtime support requests by 25%• Reduce software costs by 40%

• Qualitative:• Improve reliability, availability and scale of customer-facing portals • Standardize technology stack with a full fledged integrated platform• Increase agility, productivity and reusability• Embrace open source with abundant skill-set availability

• Strategic:• Cloud Application Platform – Start the journey to the PaaS

8 Confidential

Steps in migration

Defining the scope

Defining the new target platform

Defining a development platform

Steps in porting the application

• Pattern translations

• Compatibility library creation

• Testing the application

• Creating standard deployment

• Run books, training of Ops resources

Enhancing the platform

• Operational enhancements

• Embark the PaaS journey

9 Confidential

Defining the scope of migration

Factors to consider

• Changes in architecture?

• Functionality changes?

• Code refactoring?

• Elimination of dead code, general clean up

• Modularization to support future code changes

• Code changes to follow the new patterns for the new platform

• Fixing known bugs & metrics for code quality

Typical choices:

• Migrate the code as is: minimal changes

• As part of migration make changes that address current issues

• Guideline: Use business case to create a migration strategy

Define phases and success criteria

• Guided by business case and visibility requirements

10 Confidential

Our scope

• Architectural pattern changes in middleware

• Support for Inversion of control: Code refactoring

• Design patterns to incorporate fault tolerant caching

Solution robustness

• Reduced dependency on the back-end: offline mode.

• Increased performance through selective code refactoring

• Fault tolerant application server architecture

High availability

• Addition of monitoring tools to the deployment and manageability

• Automated provisioning of platform instances.

Operational enhancements

Summary: We had to change the architecture to support the business case, and the code to support those architecture changes; and code changes to Spring paradigm such as IoC. No new functionality.

11 Confidential

Defining the new target platform

General framework

• Which components of vFabric to use?

• Which third party (legacy components) to integrate?

• Other improvement choices

• Caching (Gemfire)

• Monitoring and Metrics (Hyperic)

• Operational improvements: vCloud director, vCO

What we did:

• Full fledged vFabric stack to unlock the full potential

• Spring WS for the back-end service Integrations

• Spring Security for securing the apps

• Optimized application performance using Gemfire

• Stability and availability with fault-tolerant cluster deployment on light-weight tc Servers

• Proactive monitoring, complete diagnostics and mgmt using Hyperic

• Application workloads provisioning and mgmt using vCloud Director and vCO

12 Confidential

New Target platform

Target Custom Web Applications Platform

Presentation – AJAX, CSS, JQuery

Spring tc App Server

Apache Web Server Hyperic

Fra

mew

ork

s &

To

ols

Pla

tfo

rm

Ser

vice

s

Portals/Widgets – Spring Web MVC, Spring Web Flow, Spring Framework 3.0

Common Application Services

Persistence – HibernateAudit/Logging - Apache

Web Service Integration – Spring WS

Alert Mgmt - Custom

Security – Spring SecurityLDAP – Spring LDAPCaching – Gemfire

GemFire

Cloud Infrastructure and Management

Cloud Application Platform – Start journey to PaaS

13 Confidential

Defining a development platform

Using a virtualized dev env

• STS and other tools

• Local installations of vFabric tc Server, Gemfire, Hyperic

• Processes for setting up and self-provisioning the virtual environments

What we did:

• Used primarily STS as the development IDE, Maven build manager, Bamboo build server

• Sonar as the development quality management platform

• Automated self-provisioning of fully configured Dev IDE (STS) and deployment environments (vFabric tc Server, Gemfire, Hyperic) using vCloud Director and vCenter Orchestrator.

14 Confidential

Architectural changes

Middleware changes:

• RMI -> SOAP for fault tolerance and better load balancing.

• Offline mode to address back-end downtimes.

• Service Virtualization to abstract versioning and changes to services.

Portal changes

• Spring WS for lazy loading of WSDLs; Portal starts up even if the middleware is down.

• Spring WS interceptor to capture, translate and handle SOAP Faults

Caching changes

• Gemfire dedicated cache for application level, user level and hibernate level 2

• Gemfire dedicated cache with vFabric tc Server for session failover.

Monitoring changes

• Comprehensive monitoring of vFabric tc Servers, Gemfire with Hyperic

• Generate Logging at Portal and Middleware layers and analyze with Splunk

15 Confidential

Porting the application

What we found…

• Weblogic specific code:

• Weblogic modified Beehive was being used for MVC layer.

• Weblogic netuix tag libraries were used on the portal

• Weblogic Personalization was being used for AuthN and AuthZ

• Non-scalable practices:

• RMI was used for Integration Layer

• Multiple Logging frameworks were used for application Logging.

What we did…

• Porting the WL-specific code through:

• Configuration changes to move to vFabric tc Server – Cloud App Platform

• WL portal code changed to Spring MVC

• Security code (Authentication and Authz) changed to Spring Security

• Pattern based refactoring

• Migration of the code to configuration (eg: Spring Security)

• Inversion of control paradigm to modularize the code – mostly addressing the low hanging fruit.

16 Confidential

Pattern examples

Use of Spring WS Interceptor

Usage of “Member-Variables” in Controllers - vFabric: Convert to Session variables in Spring MVC

Persisting Application Logging to Database

JSON Support - leveraging Spring-Jackson JSON Libraries

Controller Annotations

• Beehive Pageflow Annotations converted to Spring MVC RequestMappings

• Netuix tag libraries converted to MVC and JSTL Tag libraries.

Authorization – Spring security; configuration driven

Exception and Error Handling

17 Confidential

Testing

Functional testing:

• Re-used the existing automated functional tests: 90% of tests are these.

• Modification to support new front end enhancements (Middleware offline mode is new, tc Server session fail-over is new)

Operational testing

• New performance test cases needed to be added.

• New test cases to test

• offline mode

• vFabric fault-tolerance capability.

• the Gemfire caching

• the instance provisioning predictability

18 Confidential

Deployment Process

Pain point addressed: Long downtime for upgrades

• WL Server deployment times were 20 minutes per node.

• WL Server startup times were 20 minutes per node.

• This lead to at-least 40 min added downtime if all portals were to be handled in parallel.

Upgraded to Maven 2

• Easier management of components

• Simplified build process

New deployment scripts written

• Ant and Shell scripts for file movement and management

• Bamboo plugins for release management

19 Confidential

Deployment Architecture

Earlier pain points:

• 14 portals on 42 VMs. 28 managed nodes and 14 admin nodes

• Unequal load – rarely used apps also consumed a VM.

• Lack of proactive Monitoring of Application Server Resources

• No centralized management; Maintenance and support troubles

New deployment architecture

• Cloud Ready Application Platform – Journey to the PaaS

• Consolidated to 14 VMs from 42 VMs

• Critical apps: 4 nodes; rest 2 nodes each + 2 admin/Hyperic nodes + 2 nodes Gemfire

• App Clusters by SLA, Usage

• Customer facing critical; Customer facing non-critical; Non web apps; Internal apps

20 Confidential

Deployment Architecture

21 Confidential

Deployment Architecture

• Easier maintainability

• Hyperic reduced the need for admin nodes

• One Admin Cluster used to manage multiple Application Clusters

• Proactive Monitoring and Alerting

• Connection Pools, Threads, Thread-Locks, Heap are monitored constantly.

• Optimized Performance

• GemFire in-memory data grid improved performance

• Optimized the JVM heap usage on tc Servers using Gemfire client – server caching

• Provided tc server session failover

• Provided a high performance, scalable, and fault tolerant cache solution

• Provide application level, user level caching

22 Confidential

Lessons learned

Lockdown the scope and avoid functionality scope creek.

Be prepared to re-factor code as there is no one-to-one pattern translations for all the patterns

Lockdown the target platform components and avoid introducing new components.

Define usage patterns of new frameworks, components for faster on-ramp and code quality.

Define the criteria and the scope of different caching levels usage for optimal performance.

Allocate large amount of time for performance tests as tuning of new platform is an iterative process.

Minimize business UAT test time as no functionality change involved and compliment with automated regression testing.

23 Confidential

Benefits, Outcome

Weblogic Application Servers

vFabric tc Servers Reduction of Footprint

# Number of App Servers (incl. admin nodes)

42 App Servers VMs – 14 portals

14 App Server VMs – 14 Portals

# Number of App Server Clusters

14 Clusters – 2 App Servers/Cluster

4 Clusters – 2 App Servers/Cluster (Clusters by functionality/volume/ criticality)

=~ 66% App Server VMs=~ 71% App Server Clusters

• Reduced hardware footprint by =~ 66%

• Reduced OPEX costs by at-least 15%

• Savings of $300k+/year with the retirement of Oracle WebLogic licenses

Pre Migration Environment Post Migration Environment

App Cluster2App Cluster1 App Cluster3

App Cluster13App Cluster12 App Cluster14

App Cluster1 App Cluster2

(Weblogic App Server Clusters) (Spring tc App Server Clusters)

App Cluster3 App Cluster4

App Cluster5

Operational Consolidation & Reduced Hardware footprint

24 Confidential

Benefits, Outcome

Weblogic Server(before)

vFabric tc Server(After)

Improvement

Avg. Deployment time (minutes)

20mins / cluster 5 mins / cluster 4 times

Avg. Shutdown/Restart time(minutes)

20mins / Application(10 mins / node)

2min / node 5 times

Over-all Downtime of Web applications(minutes)

30mins / Application 6mins / application 5 times

* Data sampled over 3 month averages before and after deployment

Improved Deployment Agility and Efficiency

Reduced downtimes by 5 times

Improved performance of key transactions by using Gemfire

Improved Security using Spring security and Spring LDAP

25 Confidential

Concluding Remarks

Cloud Application Platform ready – Start the journey to PaaS

Migration to new platform need not be an IT exercise – it has real business benefits. We presented the aspects of the business case.

The ROI can substantially be increased by addressing the non-functional aspects of the application supported by the new platform. We showed how we used increased virtualization, modified deployment

architecture, monitoring to reduce the costs and increase the reliability.

More business impact can be made by adding flexibility to the application provided by vFabric platform. We shared some architecture patterns we used to make the application more

flexible – JSON support, Spring WS etc.

Thank You!

26 Confidential

Q & A