Cap2194 migration from weblogic to v fabric - cloud application platform
•Als PPTX, PDF herunterladen•
1 gefällt mir•1,842 views
This is a presentation given at VMworld 2011
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie Cap2194 migration from weblogic to v fabric - cloud application platform
Ähnlich wie Cap2194 migration from weblogic to v fabric - cloud application platform (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Cap2194 migration from weblogic to v fabric - cloud application platform
- 1. CAP2194 - An end to end case study Migrating Java Applications from Weblogic to vFabric Cloud Application Platform “Start your Journey to PaaS” Thirumalesh Reddy, VMware Rama Kanneganti, HCL
- 2. 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. Migrating Java Applications from Weblogic to vFabric Agenda Rationale for migration Steps in migration Taking advantage of the new platform Concluding Remarks
- 4. 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. More details on the VMware problem 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? 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 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. 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. 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. 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. Our scope 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. 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. New Target platform Target Custom Web Applications Platform Presentation – AJAX, CSS, JQuery Frameworks & Tools Portals/Widgets – Spring Web MVC, Spring Web Flow, Spring Framework 3.0 Web Service Integration – Spring WS Security – Spring Security Persistence – Hibernate Audit/Logging - Apache LDAP – Spring LDAP Caching – Gemfire Alert Mgmt - Custom Common Application Services Platform Services GemFire Apache Web Server Spring tc App Server Hyperic Cloud Infrastructure and Management Cloud Application Platform – Start journey to PaaS
- 13. Defining a development platform Using a virtualized devenv 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.
- 16. Configuration changes to move to vFabrictc Server – Cloud App Platform
- 17. WL portal code changed to Spring MVC
- 18. Security code (Authentication and Authz) changed to Spring Security
- 20. Migration of the code to configuration (eg: Spring Security)
- 22. Weblogic modified Beehive was being used for MVC layer.
- 23. Weblogic netuix tag libraries were used on the portal
- 24. Weblogic Personalization was being used for AuthN and AuthZ
- 26. RMI was used for Integration Layer
- 28. 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
- 29. 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
- 30. 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
- 32. 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
- 33. 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.
- 35. Reduced OPEX costs by at-least 15%
- 36. Savings of $300k+/year with the retirement of Oracle WebLogic licenses=~ 66% App Server VMs =~ 71% App Server Clusters
- 38. Reduced downtimes by 5 times
- 39. Improved performance of key transactions by using Gemfire
- 40. Improved Security using Spring security and Spring LDAP* Data sampled over 3 month averages before and after deployment
- 41. 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. ThankYou!
- 42. Q & A
Hinweis der Redaktion
- 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.
- 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.
- 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.
- 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.
- 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).
- 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.
- These are standard steps. The main interesting part is lot of enhancements we can bring to operations, once we moved to the platform.
- 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.
- We went with the standard reference platform of spring source. It was easy; it was proven; and it supported our needs.
- 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.
- 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.
- 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
- 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
- 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.