CAP2194 - An end to end case studyMigrating Java Applications from Weblogic to vFabric Cloud Application Platform “Start your Journey to PaaS”Thirumalesh Reddy, VMwareRama Kanneganti, HCL
Migrating from Weblogic to vFabric - Opening RemarksCloud Application Platform – Start your journey to PaaSMigration has real business benefitsIncreased agility and reliabilityReduced deployment downtimesScales to future growthReduced Cap-Ex and Op-Ex costsReduced Hardware FootprintHighly adaptive to business and customer needs
Migrating Java Applications from Weblogic to vFabric AgendaRationale for migrationSteps in migrationTaking advantage of the new platformConcluding Remarks
Problem ContextEnterprise custom Java applications are expensive and complex to build, deploy, scale and manageTypical problems:DevelopmentObsolete toolkits and no clear choice of toolkit (Struts, anyone?)No fully integrated stack resulting in lack of control and risk OperationalLack of support for developer-friendly toolsLack of industry and communityIndustryShortage of skill setsFragmented market space leading to uncertainty.VMware problem: Higher % of downtime leading to poor customer satisfaction; and high cost of development and operations
More details on the VMware problemBusiness 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?VMware IT… what is needed is a scalable, robust, and manageable platform that is built on modern tools and technologies!faster service execution at lower cost…
Why migrate?General solution to our problem: Migrate to a new platform.Constraints: Retain functionalityAddress perceived issuesCreating a business caseDue to platform issues there is a high cost for downtimes ad-hoc fixing of problems not having the right monitoring toolsdevelopment with a disparate technology stack. hardware costs to scale with complex resources intensive application serversMigration Costsnew platform creationcode migrationcost of testing
Sample Business case templateMigration of technology stacks is an IT askChallenge: 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 platformIncrease agility, productivity and reusabilityEmbrace open source with abundant skill-set availabilityStrategic:Cloud Application Platform – Start the journey to the PaaS
Steps in migrationDefining the scopeDefining the new target platformDefining a development platformSteps in porting the applicationPattern translationsCompatibility library creationTesting the applicationCreating standard deploymentRun books, training of Ops resourcesEnhancing the platformOperational enhancementsEmbark the PaaS journey
Defining the scope of migrationFactors to considerChanges in architecture?Functionality changes?Code refactoring?Elimination of dead code, general clean upModularization to support future code changesCode changes to follow the new patterns for the new platformFixing known bugs & metrics for code qualityTypical choices:Migrate the code as is: minimal changesAs part of migration make changes that address current issuesGuideline: Use business case to create a migration strategy Define phases and success criteria Guided by business case and visibility requirements
Our scopeSummary: 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.
Defining the new target platformGeneral frameworkWhich components of vFabric to use?Which third party (legacy components) to integrate?Other improvement choicesCaching (Gemfire)Monitoring and Metrics (Hyperic)Operational improvements: vCloud director, vCOWhat we did:Full fledged vFabric stack to unlock the full potentialSpring WS for the back-end service IntegrationsSpring Security for securing the appsOptimized application performance using GemfireStability and availability with fault-tolerant cluster deployment on light-weight tc ServersProactive monitoring, complete diagnostics and mgmt using HypericApplication workloads provisioning and mgmt using vCloud Director and vCO
New Target platformTarget Custom Web Applications PlatformPresentation – AJAX, CSS, JQueryFrameworks & ToolsPortals/Widgets – Spring Web MVC, Spring Web Flow, Spring Framework 3.0Web Service Integration – Spring WSSecurity – Spring SecurityPersistence – HibernateAudit/Logging - ApacheLDAP – Spring LDAPCaching – GemfireAlert Mgmt - CustomCommon Application ServicesPlatform ServicesGemFireApache Web ServerSpring tc App ServerHypericCloud Infrastructure and ManagementCloud Application Platform – Start journey to PaaS
Defining a development platformUsing a virtualized devenvSTS and other toolsLocal installations of vFabric tc Server, Gemfire, Hyperic Processes for setting up and self-provisioning the virtual environmentsWhat we did:Used primarily STS as the development IDE, Maven build manager, Bamboo build serverSonar as the development quality management platformAutomated self-provisioning of fully configured Dev IDE (STS) and deployment environments (vFabric tc Server, Gemfire, Hyperic) using vCloud Director and vCenter Orchestrator.
Architectural changes
Porting the applicationWhat we did…Porting the WL-specific code through:
Configuration changes to move to vFabrictc 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.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

Cap2194 migration from weblogic to v fabric - cloud application platform

  • 1.
    CAP2194 - Anend to end case studyMigrating Java Applications from Weblogic to vFabric Cloud Application Platform “Start your Journey to PaaS”Thirumalesh Reddy, VMwareRama Kanneganti, HCL
  • 2.
    Migrating from Weblogicto vFabric - Opening RemarksCloud Application Platform – Start your journey to PaaSMigration has real business benefitsIncreased agility and reliabilityReduced deployment downtimesScales to future growthReduced Cap-Ex and Op-Ex costsReduced Hardware FootprintHighly adaptive to business and customer needs
  • 3.
    Migrating Java Applicationsfrom Weblogic to vFabric AgendaRationale for migrationSteps in migrationTaking advantage of the new platformConcluding Remarks
  • 4.
    Problem ContextEnterprise customJava applications are expensive and complex to build, deploy, scale and manageTypical problems:DevelopmentObsolete toolkits and no clear choice of toolkit (Struts, anyone?)No fully integrated stack resulting in lack of control and risk OperationalLack of support for developer-friendly toolsLack of industry and communityIndustryShortage of skill setsFragmented market space leading to uncertainty.VMware problem: Higher % of downtime leading to poor customer satisfaction; and high cost of development and operations
  • 5.
    More details onthe VMware problemBusiness 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?VMware IT… 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.
    Why migrate?General solutionto our problem: Migrate to a new platform.Constraints: Retain functionalityAddress perceived issuesCreating a business caseDue to platform issues there is a high cost for downtimes ad-hoc fixing of problems not having the right monitoring toolsdevelopment with a disparate technology stack. hardware costs to scale with complex resources intensive application serversMigration Costsnew platform creationcode migrationcost of testing
  • 7.
    Sample Business casetemplateMigration of technology stacks is an IT askChallenge: 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 platformIncrease agility, productivity and reusabilityEmbrace open source with abundant skill-set availabilityStrategic:Cloud Application Platform – Start the journey to the PaaS
  • 8.
    Steps in migrationDefiningthe scopeDefining the new target platformDefining a development platformSteps in porting the applicationPattern translationsCompatibility library creationTesting the applicationCreating standard deploymentRun books, training of Ops resourcesEnhancing the platformOperational enhancementsEmbark the PaaS journey
  • 9.
    Defining the scopeof migrationFactors to considerChanges in architecture?Functionality changes?Code refactoring?Elimination of dead code, general clean upModularization to support future code changesCode changes to follow the new patterns for the new platformFixing known bugs & metrics for code qualityTypical choices:Migrate the code as is: minimal changesAs part of migration make changes that address current issuesGuideline: Use business case to create a migration strategy Define phases and success criteria Guided by business case and visibility requirements
  • 10.
    Our scopeSummary: Wehad 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.
    Defining the newtarget platformGeneral frameworkWhich components of vFabric to use?Which third party (legacy components) to integrate?Other improvement choicesCaching (Gemfire)Monitoring and Metrics (Hyperic)Operational improvements: vCloud director, vCOWhat we did:Full fledged vFabric stack to unlock the full potentialSpring WS for the back-end service IntegrationsSpring Security for securing the appsOptimized application performance using GemfireStability and availability with fault-tolerant cluster deployment on light-weight tc ServersProactive monitoring, complete diagnostics and mgmt using HypericApplication workloads provisioning and mgmt using vCloud Director and vCO
  • 12.
    New Target platformTargetCustom Web Applications PlatformPresentation – AJAX, CSS, JQueryFrameworks & ToolsPortals/Widgets – Spring Web MVC, Spring Web Flow, Spring Framework 3.0Web Service Integration – Spring WSSecurity – Spring SecurityPersistence – HibernateAudit/Logging - ApacheLDAP – Spring LDAPCaching – GemfireAlert Mgmt - CustomCommon Application ServicesPlatform ServicesGemFireApache Web ServerSpring tc App ServerHypericCloud Infrastructure and ManagementCloud Application Platform – Start journey to PaaS
  • 13.
    Defining a developmentplatformUsing a virtualized devenvSTS and other toolsLocal installations of vFabric tc Server, Gemfire, Hyperic Processes for setting up and self-provisioning the virtual environmentsWhat we did:Used primarily STS as the development IDE, Maven build manager, Bamboo build serverSonar as the development quality management platformAutomated self-provisioning of fully configured Dev IDE (STS) and deployment environments (vFabric tc Server, Gemfire, Hyperic) using vCloud Director and vCenter Orchestrator.
  • 14.
  • 15.
    Porting the applicationWhatwe did…Porting the WL-specific code through:
  • 16.
    Configuration changes tomove to vFabrictc Server – Cloud App Platform
  • 17.
    WL portal codechanged to Spring MVC
  • 18.
    Security code (Authenticationand Authz) changed to Spring Security
  • 19.
  • 20.
    Migration of thecode to configuration (eg: Spring Security)
  • 21.
    Inversion of controlparadigm to modularize the code – mostly addressing the low hanging fruit.What we found…Weblogic specific code:
  • 22.
    Weblogic modified Beehivewas being used for MVC layer.
  • 23.
    Weblogic netuix taglibraries were used on the portal
  • 24.
    Weblogic Personalization wasbeing used for AuthN and AuthZ
  • 25.
  • 26.
    RMI was usedfor Integration Layer
  • 27.
    Multiple Logging frameworkswere used for application Logging.Pattern examplesUse of Spring WS InterceptorUsage of “Member-Variables” in Controllers - vFabric: Convert to Session variables in Spring MVCPersisting Application Logging to DatabaseJSON Support - leveraging Spring-Jackson JSON LibrariesController AnnotationsBeehive Pageflow Annotations converted to Spring MVC RequestMappingsNetuix tag libraries converted to MVC and JSTL Tag libraries.Authorization – Spring security; configuration drivenException and Error Handling
  • 28.
    TestingFunctional testing:Re-used theexisting 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 testingNew performance test cases needed to be added.New test cases to test offline modevFabric fault-tolerance capability.the Gemfire cachingthe instance provisioning predictability
  • 29.
    Deployment ProcessPain pointaddressed: 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 2Easier management of componentsSimplified build processNew deployment scripts writtenAnt and Shell scripts for file movement and managementBamboo plugins for release management
  • 30.
    Deployment ArchitectureEarlier painpoints:14 portals on 42 VMs. 28 managed nodes and 14 admin nodesUnequal load – rarely used apps also consumed a VM.Lack of proactive Monitoring of Application Server ResourcesNo centralized management; Maintenance and support troublesNew deployment architectureCloud Ready Application Platform – Journey to the PaaS Consolidated to 14 VMs from 42 VMsCritical apps: 4 nodes; rest 2 nodes each + 2 admin/Hyperic nodes + 2 nodes GemfireApp Clusters by SLA, UsageCustomer facing critical; Customer facing non-critical; Non web apps; Internal apps
  • 31.
  • 32.
    Deployment ArchitectureEasier maintainabilityHypericreduced the need for admin nodesOne Admin Cluster used to manage multiple Application ClustersProactive Monitoring and AlertingConnection Pools, Threads, Thread-Locks, Heap are monitored constantly.Optimized PerformanceGemFire in-memory data grid improved performanceOptimized the JVM heap usage on tc Servers using Gemfire client – server cachingProvided tc server session failoverProvided a high performance, scalable, and fault tolerant cache solutionProvide application level, user level caching
  • 33.
    Lessons learnedLockdown thescope and avoid functionality scope creek.Be prepared to re-factor code as there is no one-to-one pattern translations for all the patternsLockdown 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.
  • 34.
    Benefits, OutcomeOperational Consolidation& Reduced Hardware footprintPre Migration EnvironmentPost Migration Environment(Weblogic App Server Clusters)(Spring tc App Server Clusters)App Cluster1App Cluster2App Cluster3App Cluster2App Cluster1App Cluster4App Cluster3App Cluster12App Cluster13App Cluster14App Cluster5Reduced hardware footprint by =~ 66%
  • 35.
    Reduced OPEX costsby at-least 15%
  • 36.
    Savings of $300k+/yearwith the retirement of Oracle WebLogic licenses=~ 66% App Server VMs=~ 71% App Server Clusters
  • 37.
    Benefits, Outcome Improved Deployment Agility and Efficiency
  • 38.
  • 39.
    Improved performanceof key transactions by using Gemfire
  • 40.
    Improved Securityusing Spring security and Spring LDAP* Data sampled over 3 month averages before and after deployment
  • 41.
    Concluding RemarksCloud ApplicationPlatform ready – Start the journey to PaaSMigration 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.ThankYou!
  • 42.

Editor's Notes

  • #3 Most people do not migrate because they see it only as IT optimization. But, with proper business case, they can incorporate aspects that will deliver business benefits as well.
  • #4 This is the story of how VMware successfully migrated its portals used in customer purchases and support to Springsource stack addressing the technical issues while responding to the needs of business.
  • #5 Any enterprise that built a complex piece of machinery to support their applications must be feeling the same way. They invested a lot in making a complex setup work, but it cannot keep with the times. The trend is now how organizations are focusing on what brings value to them. It means, cloud and PAAS to address the technical needs, while IT focuses on delivering what is needed for the business.
  • #6 Original applications - Weblogic portal (Beehive) with local enhancementsIssuesPerformance: was not scaling with increasing number users and amount of data.Difficulty of managing: Adding a feature took long time to add; cleanup; un-deploy and deploy resulting in longer downtime.Application instability : Frequent reboots were requiredDifficulty of analysis: No built in application monitoring; external monitoring did not provide internal details or proactive alerts. What was needed:A scalable, robust, and manageable platform that is built on modern tools and technologies.
  • #7 There was a debate on functionality improvement. We resolved it by saying: We want to enable resilient architecture – even if the components went down the users should be able to conduct their business.Whatever we need to change from functionality perspective to achieve the above goal, we will do.Any cleanup that is easy and supports the IT goals (HA, maintainability etc), we will do.Other functionality changes will be entertained only on the need basis (In general, no changes).
  • #8 The business case template includes:ROI realization: When, what will change and how much it will save.Assumptions: What the current assumptions about the cost of downtime etc.Eventually, it provides a framework for us to create a plan and a time table.
  • #9 These are standard steps. The main interesting part is lot of enhancements we can bring to operations, once we moved to the platform.
  • #10 One major Constraint / requirement was, all of the user bookmarked URLs should work after migration with out any change. For example: On Weblogic, Login page was www.vmware.com/mysupport/login.portalThe same URL should work on Spring TcServer as well.
  • #12 We went with the standard reference platform of spring source. It was easy; it was proven; and it supported our needs.
  • #15 The details are in the slide itself. Why we did these changes:Moving to standardization and modern technologies: RMI is tough to debug and support.Reducing the tight coupling: Even if some components (some of those are not in our hands – they have different downtimes and different availability schedules) are down, the application still works.Non-functional enhancements: Caching to use Gemfire. Deployment changes: Cleaning up earlier disparate standards as well as introducing new standardized tools.
  • #16 We could have considered emulation library as well, but in the long run, it is more painful than it is worth. We are not thinking this code as legacy – it is a living code and as such deserves no such short term fixes.
  • #17 Pattern – Usage of “Member-Variables” in ControllersvFabric: Convert to Session variables in Spring MVC.@SessionAttributes(“sessionAttributeName”)public class MySessionVarClass {... ... }void myRequestMappingMethod(@ModelAttribute(“sessionAttributeName”) MySessionVarClassmsvc) {}Pattern – Persisting Application Logging to DatabaseDue to the use of Multiple logging frameworks, a multiple implementation were usedStandardized on Log4J.Used enhanced version Log4JDBAppender.Pattern – JSON SupportWL – no OOB support for JSON Serialization and DeserializationJSPs were used for de-serializing to JSON.Define object model on the Controller layer, and de-serialize them to JSON leveraging Spring-Jackson JSON Libraries.public @ResponseBodyOutputClasssaveSomething(@RequestBodySomeInputClass input) { //Little bit of logic to call Service Layer .. .. .. //Some more logic to convert service response to UI Object return output;}Pattern – Controller AnnotationsBeehive Pageflow Annotations converted to Spring MVC RequestMappingsNetuix tag libraries converted to MVC and JSTL Tag libraries.Pattern – AuthorizationWL – Container Authorization was leveragedSpring Security with Configuration based Access control and Role-User MappingPattern – Exception and Error HandlingWL – no common mechanism for error handlingClassify exceptions into Business and System Exceptions and populate appropriate codes. Use Spring MVC Exception Resolver to display appropriate error messages / pages
  • #19 Maven 1 lacked support for JSP tagsLeverage Project Lifecycles – QA is interested in running automated integration tests only!Transitive dependencies – Large number of Open Source Libraries were used – difficult to manage with Maven1So, we migrated to maven2
  • #24 The VMware Cloud Application Platform combines the Spring Framework for building new applications together with a complete set of Application Platform Services required to run and manage these applications.[CLICK] Spring Framework: Spring is a comprehensive family of developer frameworks and tools that enable developers build innovative new applications in a familiar and productive way while enabling the choice of where to run those applications, whether inside the datacenter or on private, hybrid, or public clouds. Spring enables developers to create applications that: Provide a rich, modern user experience across a range of platforms, browsers and personal devices Integrate applications using proven Enterprise Application Integration patterns, including batch processing Access data in a wide range of structured and unstructured formats Leverage popular social media services and cloud service API’s[CLICK] VMware vFabric: VMware vFabric is a comprehensive family of application services uniquely optimized for cloud computing including lightweight application server, global data management, cloud-ready messaging, dynamic load balancing and application performance management. [CLICK] The products behind these services include: Lightweight Application Server: tc Server, an enterprise version of Apache Tomcat, is optimized for Spring and VMware vSphere and can be instantaneously provisioned to meet the scalability needs of modern applications Data Management Services: GemFire speeds application performance and eliminates database bottlenecks by providing real-time access to globally distributed data Cloud-ready Messaging Service: RabbitMQ facilitates communications between applications inside and outside the datacenter Dynamic Load Balancer: ERS, an enterprise version Apache web server, ensures optimal performance by distributing and balancing application load Application Performance Management: Hyperic enables proactive performance management through transparent visibility into modern applications deployed across physical, virtual, and cloud environments Policy-Driven Automation: Foundry is the tentative name for a new offering still under development that is focused on policy-based automation of application and platform configuration and provisioning tasks.