Giga Spaces Alternative To GAE_JavaOne 09
Download as PPT, PDF0 likes591 views
The document discusses an alternative PaaS solution to Google App Engine for Java applications called GigaSpaces. It summarizes the key differences between AWS and GAE, challenges with enterprise applications on the cloud, and how GigaSpaces addresses these challenges by providing a PaaS platform on top of AWS. This provides more flexibility than GAE while still offering ease of use. A case study is presented of a risk analytics company that used GigaSpaces to build a scalable platform on AWS for running Monte Carlo simulations.
![Speakers Argyn Kuketayev Senior Consultant Francis de la Cruz Manager [email_address] 703 342 0438 Has been using the Java Programming Language since the days of Java 1.2 Previously worked on the DoD and Security domain before moving on to the Financial Domain. Degree in Electrical Computer Engineering Has created many dead end open source projects notables including Active Record framework using annotations, proxy and Apache Torque HTML based web framework Java based batching and processing application [email_address] 703 342 0053 quant development team lead using Java since 1998 degrees in Physics and Finance started in scientific computing](https://image.slidesharecdn.com/gigaspaces-alternativetogae-j1-09-090610182322-phpapp01/85/Giga-Spaces-Alternative-To-GAE_JavaOne-09-41-320.jpg)
Giga Spaces Alternative To GAE_JavaOne 09
- 1. Alternative to Google Application Engine for Java™ Technology-Based Applications Nati Shalom CTO GigaSpaces Natishalom.typepad.com Twitter.com/natishalom Francis de la Cruz Manager , Argyn Kuketayev Senior Consultant, Primatics Financial
- 2. About GigaSpaces 2,000+ Deployments 100+ Direct Customers Among Top 50 Cloud Vendors A middleware platform enabling applications to run a distributed cluster as if it was a single machine
- 3. Agenda Introduction to Cloud Computing AWS vs GAE Challenges of Enterprise Applications PaaS on EC2 Case study – Primatics Risk Management as a Service Summary & References PetClinic in the Clouds: Scaling a Classic Enterprise Application Wednesday 1:35 PM - 3:15 PM LAB-5564BYOL Hall E 132 Free drinks Webtide & GigaSpaces party – Tuesday 8 PM SOMA 201 3rd St (gigaspaces.com/javaone)
- 4. Introduction to cloud computing SaaS PaaS IaaS
- 5. Agenda Introduction to Cloud Computing AWS vs GAE Challenges of Enterprise Applications PaaS on EC2 Case study – Primatics Risk Management as a Service Summary & References
- 6. AWS vs GAE Source:Zdnet
- 7. AWS vs GAE (1/2) AWS Very flexible, lower-level offering (closer to hardware) = more possibilities, higher performing Runs platform you provide (machine images) Supports all major web languages Industry-standard services (move off AWS easily) Require much more work, longer time-to-market Deployment scripts, configuring images, etc. Various libraries and GUI plug-ins make AWS do help
- 8. AWS vs GAE (2/2) GAE Easy to use, free (but limited) fees coming soon Very tightly controlled – no installation/config of open source software Proprietary environment = hard to move away from Further support may be limited (ex: Ruby on Rails tightly coupled with relational DBs)
- 9. GAE Java Limitations Once a request is sent to the client no further processing can be done. A request will be terminated if it has taken around 30 seconds Sandbox restrictions: Applications can not write to the file system and must use the App Engine datastore instead. Applications may not open sockets Applications can not create their own threads or use related utilities such as timer. java.lang.System has been restricted as follows: exit(), gc(), runFinalization(), and runFinalizersOnExit() do nothing. JNI access is not allowed. Limited JPA support (many relationships, Aggregation queries, Join" queries,..) Source: InfoQ
- 10. Agenda Introduction to Cloud Computing AWS vs GAE Challenges of Enterprise Applications PaaS on EC2 Case study – Primatics Risk Management as a Service Summary & References
- 11. Typical Enterprise Application Business tier Back-up Back-up Back-up Back-up Load Balancer Web Tier Messaging Data Tier Do you see a problem?
- 12. Enterprise application challenges Adding additional resources dynamically No out-of-the-box infrastructure for J2EE Dealing with a lack of persistence Dealing with distributed programming models Having to think about the whole stack. Not just the code. Using Memory Data Grids and Caching considerations Messaging Understanding configuration management tools Pricing and licensing Source: Cloud Mailing List
- 13. The solution Build a Generic PaaS ontop of AWS Get the best out of the two worlds Flexibility and performance of AWS Simplicity and ease of use of PaaS JEE as first class citizen Minimize lock-in Use middleware virtualization Abstract the application code from the infrastructure Enable end to end elasticity
- 14. Agenda Introduction to Cloud Computing AWS vs GAE Challenges of Enterprise Applications PaaS on EC2 Case study – Primatics Risk Management as a Service Summary & References
- 15. PaaS on top of AWS – Architecture view Application Repository (S3) MT Application Provisioning IaaS Provider (EC2, GoGrid, Sun, VMWhere, Citrix,..) App A App B Application Deployment Configuration 2)Deploy 1)Install Provision 3)Manage
- 16. Dynamic Images Each machine can be assigned with 64/32 S,M,L,XL Images individually Each machine dynamically install software packages GSM responsible for deploying application packages to GSC machines Cluster Manager Admin-Ui GSM Machine UI Machine WWW LB Machine Web Web Web Web Mirror IMDG IMDG IMDG Tomcat Comp- Node Comp-Nodes Jmeter Ext-Machine Database Machine SLA Containers
- 17. Understanding the provisioning process GSC Start GSC Join the GSM cluster GSM Start GSM Deploy processing units LB Start the Load Balancer Add/Remove web container DB Initialize the database storage Start the database Deployment manager Machine Parse the deployment configuration Provision the VM with assigned profile Monitor and manage the application Install software packages from repo Assign machine profile Repeat for all machines
- 18. SLA Driven Containers of Containers Break physical machines into sub machines Automation of manual deployment Auto scaling Self healing Container of Containers Jetty Glassfish Tomcat (Not supported yet)
- 20. Middleware virtualization App " All problems in computer science can be solved by another level of indirection" ( Butler Lampson ) Similar principles to storage virtualization Decouple the application from the deployment environment Use partitioning to split the load and the data.
- 21. End 2 End Elasticity Load Balancer to Database Embedded Web Container Dynamic Load Balancing HTTP Session Replication In Memory Data Grid Async update to the Database Dynamic SLA Based Scaling
- 22. Design for linear scalability Users Load Balancer Web Processing Units Business Processing Units DB Partition the entire application stack
- 23. Agenda Introduction to Cloud Computing AWS vs GAE Challenges of Enterprise Applications PaaS on EC2 Case study – Primatics Risk Management as a Service Summary & References
- 24. Case Study: Evolv ™ Risk: Cloud Computing Use Case for Java One 2009 Francis de la Cruz Manager, Primatics Financial Argyn Kuketayev Senior Consultant, Primatics Financial
- 25. Use Case Outline Business Challenge Client Needs and Application Evolution Business Needs Architectural Challenges Risk 1.5 Application Stack Risk 2.0 Application Stack Processing Unit diagram Lessons Learned
- 26. Business Case Many mid-size regional banks with sizeable mortgage portfolios Outsource sophisticated mortgage credit risk modeling Outsource IT infrastructure to perform costly computations, suited for on-demand PaaS
- 27. Primatics’ Story in Cloud Computing Company with roots in financial services and IT Multiple clients in financial services, 2 products 2007 EVOLV Risk V1: Web-based hosted solution, a regional bank 2008 V2: embrace Cloud computing, Amazon EC2 V1.5: big national bank M&A, portfolio valuation, AWS EC2 2009 V2 “reloaded”: ground up redesign, GigaSpaces
- 28. Business Needs: Accounting-Cashflows Risk Analytics Platform Stochastic (Monte Carlo) simulation: for each loan run 100 paths (360 months each) INPUT Loan Portfolio ( 100MB): 100k Loans x 1 KB data Forecast Scenarios (100MB): 1MB per simulation path Market History (<1MB) Assumptions, Setting, Dials (<1KB) OUTPUT Cashflows (3GB): 100k Loans x 360 months x 10 Doubles
- 29. Business Needs: Scale Many jobs by the same user Many users in a firm Many firms More loans, more simulations, longer time horizon Risk Analytics Platform
- 30. Overarching Challenges Quantitative financial applications (models) with heavy CPU load Large volumes of data I/O Infrastructure to support growing number of clients, and users Varying load on the system, with spikes of heavy load Avoid lock-in to cloud vendors
- 31. Evolv Risk 1.5 vs 2.0 Software Stack GIGASPACES Prior Grid Framework J2EE Platform Loans & securities Loans Web-Interface SSL Reporting Warehouse Model API Scenarios Loss & Valuation Securities Custom Templates Validation Pluggable Client models Model Validation & statistics Cohorts HPI rates Interest rates Market rates Provisioning Monitoring Job Scheduling Failover / Recovery Load Balancing AWS Billing Registration Management Loss Forecasts Valuations Discount rates Node Management OLAP Reports Auto Throttling SLA Space Based Architecture Scaling Manual Process Model Validation & statistics Provisioning Monitoring Billing AWS Registration AWS management Not In Architecture Auto Throttling Space Based Architecture SLA Node Management * Broker (MQ) Sun JMS Discovery Persistence Manager J2EE Platform Inbuilt models
- 32. Performance, Scalability, Data Security, Data Integrity
- 33. Performance, Scalability, Data Security, Data Integrity Primatics Gateway AWS Provisioning
- 34. Lessons Learned : Cloud Integration Provisioning Configuration API vs. Using Scripts Auto Throttling vs. Manual Throttling Failover and Recovery provided by framework Monitoring VIA GS Console and API vs in house application. Infrastructure took 5 weeks vs 8 weeks to develop. Achieving linear scalability was a matter of creating Processing Units.
- 35. Lessons Learned : Data and Processing Data Distribution Uses Spaces Architecture vs. In house developed JMS Broker and Discovery to push to Grid Deployment Uses GS API vs. Pushing data to grid or using machine images.
- 36. Lessons Learned: Problems are now high class problems. GigaSpaces Framework spared us from low level problems. Code written is for more answering ‘why’ not answering ‘how’. GigaSpaces: Provisioning out of the box Failover and Recovery much easier Monitoring through API and Console SLA out of the box Integrated into the Cloud Significantly lowers the barrier of entry into Cloud computing
- 37. Agenda Introduction to Cloud Computing AWS vs GAE Challenges of Enterprise Applications PaaS on EC2 Case study – Primatics Risk Management as a Service Summary & References PetClinic in the Clouds: Scaling a Classic Enterprise Application Wednesday 1:35 PM - 3:15 PM LAB-5564BYOL Hall E 132 Free drinks Webtide & GigaSpaces party – Tuesday 8 PM SOMA 201 3rd St (gigaspaces.com/javaone)
- 38. Adding PaaS to AWS brings the flexibility and performance of AWS and ease of use of PaaS Enterprise applications can run on the cloud today: No need to re-write your application Preventing lock-in to specific cloud provider Enabling seamless portability between your local environment to cloud environment Choose simple applications first Avoid dealing with complex security issues Application with Clear path to ROI (Fluctuating load, large scale testing, DR,..) Summary: Key Takeaways
- 39. References PetClinic in the Clouds: Scaling a Classic Enterprise Application Wednesday 1:35 PM - 3:15 PM LAB-5564BYOL Hall E 132 Cloud Mailing List http:// groups.google.ca /group/cloud-computing Amazon Cloud: aws.amazon.com GigaSpaces PaaS on AWS gigaspaces.com/mycloud
- 40. Nati Shalom Natishalom.typepad.com Twitter.com/natishalom Run your own demo http:// www.gigaspaces.com/mycloud
- 41. Speakers Argyn Kuketayev Senior Consultant Francis de la Cruz Manager [email_address] 703 342 0438 Has been using the Java Programming Language since the days of Java 1.2 Previously worked on the DoD and Security domain before moving on to the Financial Domain. Degree in Electrical Computer Engineering Has created many dead end open source projects notables including Active Record framework using annotations, proxy and Apache Torque HTML based web framework Java based batching and processing application [email_address] 703 342 0053 quant development team lead using Java since 1998 degrees in Physics and Finance started in scientific computing
Editor's Notes
- #2: <number><number><number><number>
- #3: Enabling to run a single app on a dist. env. Leveraging in memory resources to gain performance
- #11: <number>
- #12: Try to add a machine and see what happens? NothingEvetything is hard wired, staticAssuming we did do that, what the effect? Can you predict
- #18: <number>
- #21: <number>
- #22: <number>
- #23: Remoting over IMDGMessaging over IMDGIMDG as a system of record, async persistency
- #31: PerformanceMust run in a matter of hours and minutes not days.On-demand performance. High priority requests can be run on more machines.Stochastic (Monte Carlo Simulation) or DeterministicScalabilityLinear scalability per additional node.Multiple ScenariosClients may choose to execute 1 to N scenariosHorizon 2 years to 30 yearsStress Tests – unemployment rate rises above 10% and home prices fall by another 25%Data Size can easily run into the tens and hundreds of gigabytes and maybe even terrabytesData IntegrityClient’s data must never reside on the same location as another client’s data.Cashflow or valuation produced cannot be lost.Transacted
- #32: This is primatics’ story.Stress how respectful we are of the open source framework and we are not here to talk about merits and demerits.1.0 to 1.5 to 2.01.0 typical J2EE app. 1 client. 50k loans. Non Enterprise grade models. Few hours. 1.5 1st cloud app. N clients. 160k loans. Enterprise grade models. Few minutes/hours.2.0 NNNN clients. 1MM loans. Enterprise grade models. Few minutes/hours.Start out with 1.5Stress how 1.5 currently in production.What are the things that proved difficult to scale for multiple clients.Things that are missingThings that are not enterprise grade.1.5 not designed to scale over clients.2.0 is designed to scale over N clientsPulled Manual and Things we liked into the application.Replaced the underlying frameworkReplaced with enterprise gradeAdded space based architecture.<number>
- #33: All Jobs are stored in spaces.Cashflow objects in the spaces are backed up to a store on a different PU.Compute PU will load models as needed.Compute PU will also push the cashflows to a MySQL database. Current throughput is at 60MM records in 13 minutes (transacted)1.5 Data PerformanceMax. throughput at 60M records in 30minutes. = 33k records / second on MySQL2.0 Data PerformanceEst. Max. throughput at 60M records in 13 minutes = 77k records / second on MySQL innodb33
- #34: All Jobs are stored in spaces.Cashflow objects in the spaces are backed up to a store on a different PU.Compute PU will load models as needed.Compute PU will also push the cashflows to a MySQL database. Current throughput is at 60MM records in 13 minutes (transacted)
- #35: Importance of integration into the cloud.ProvisioningCould take minutes to set up vs configThrottlingBring up servers, put application on it, have it register vs auto-throttlingStability / monitoringProbably works well on traditional grid environment – didn’t work well on AMZN.When you start out on the cloud. Pick up the tools that you know will work well vs making the tools work well.
- #36: Data had to be pushed into the Grid vs using the spaces for caching and data distributionunicast vs multicast issue in Amazon forced us to create the JMS Broker and Discovery module for pushing data and monitoring.Deployment – bring server up through AMZN console then deploy application. 2.0 allows us to leverage GigaSpaces for deployment.Images can be a versioning nightmare.