Giga Spaces Alternative To GAE_JavaOne 09
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Giga Spaces Alternative To GAE_JavaOne 09

on

  • 1,148 views

 

Statistics

Views

Total Views
1,148
Views on SlideShare
1,147
Embed Views
1

Actions

Likes
0
Downloads
20
Comments
0

1 Embed 1

http://www.slideshare.net 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Enabling to run a single app on a dist. env. Leveraging in memory resources to gain performance
  • Try to add a machine and see what happens? NothingEvetything is hard wired, staticAssuming we did do that, what the effect? Can you predict
  • Remoting over IMDGMessaging over IMDGIMDG as a system of record, async persistency
  • 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
  • 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.
  • 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
  • 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)
  • 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.
  • 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.

Giga Spaces Alternative To GAE_JavaOne 09 Presentation Transcript

  • 1. Alternative to Google Application Engine for Java™ Technology-Based Applications Francis de la Cruz Nati Shalom Manager, CTO GigaSpaces Natishalom.typepad.com Argyn Kuketayev Twitter.com/natishalom Senior Consultant, Primatics Financial
  • 2. About GigaSpaces A middleware platform enabling applications to run a distributed cluster as if it was a single machine 2,000+ Deployments Among Top 50 Cloud Vendors 100+ Direct Customers 2 2
  • 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) 3
  • 4. Introduction to cloud computing SaaS PaaS IaaS 4
  • 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 5
  • 6. AWS vs GAE Source:Zdnet 6
  • 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 7
  • 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) 8
  • 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, Joinquot; queries,..) Source: InfoQ 9
  • 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 10
  • 11. Typical Enterprise Application Business tier Do you see a problem? Web Tier Load Balancer Back-up Back-up Back-up Back-up Data Tier Messaging 11
  • 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 12
  • 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 13
  • 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 14
  • 15. PaaS on top of AWS – Architecture view MT Application Provisioning 2)Deploy Application 3)Manage Deployment Configuration 1)Install Provision IaaS Provider (EC2, GoGrid, Sun, VMWhere, Citrix,..) Application Repository (S3) App A App B 15
  • 16. Dynamic Images Cluster Manager Admin-Ui > 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 GSM Machine UI Machine Web Jmet er IMD G Web Tomc at WW IMD Mirro W G r Web Comp- Node IMD G Web Com p- Node Database s LB Machine Machine SLA Containers Ext-Machine 16
  • 17. Understanding the provisioning process Deployment manager Machine Parse the deployment configuration Provision the VM with assigned profile Install software packages from repo Assign machine profile DB LB Initialize the database storage Start the Load Balancer Start the database Repeat for all machines Add/Remove web container GSC GSM Start GSC Start GSM Join the GSM cluster Deploy processing units Monitor and manage the application 17
  • 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) 18
  • 19. Develop Custom SLA 19
  • 20. Middleware virtualization > quot;All problems in computer science can be solved by another level of indirectionquot; ( Butler Lampson) > Similar principles to storage virtualization App > Decouple the application from the deployment environment > Use partitioning to split the load and the data. 20
  • 21. End 2 End Elasticity Load Balancer to Database Dynamic Load Balancer Load Balancing (Apache) Embedded Web Web Browser Container Dynamic Processing Unit Processing Unit Processing Unit SLA Based Grid Service Web Web Web Container Container Container Scaling Manager Grid Service Grid Service Grid Service HTTP Session Container Container Container Replication Processing Unit Processing Unit Processing Unit Processing Unit Service Service Service Service Processing Unit Bean Bean Bean Bean Client Client Replication Replication Application Application Primary 1 Backup 1 Primary 2 Backup 2 Grid Service Container Grid Service Grid Service Grid Service Grid Service Container Container Container Container In Memory Data Grid Async update to the Database 21
  • 22. Design for linear scalability Partition the entire application stack Web Business Processing Processing Units Units Load Balancer Users DB 22
  • 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 23
  • 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 24
  • 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 25
  • 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 26
  • 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 27
  • 28. Business Needs: Accounting-Cashflows INPUT Loan Portfolio (100MB): 100k Loans x 1 KB data Forecast Scenarios (100MB): 1MB per simulation path Market History (<1MB) Assumptions, Setting, Dials (<1KB) Risk Analytics Platform Stochastic (Monte Carlo) simulation: for each loan run 100 paths (360 months each) OUTPUT Cashflows (3GB): 100k Loans x 360 months x 10 Doubles 28
  • 29. Business Needs: Scale Many firms Many users in Many jobs by a firm the same user More loans, more simulations, longer time horizon Risk Analytics Platform 29
  • 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 30
  • 31. Evolv Risk 1.5 vs 2.0 Software Stack Web-Interface SSL AWS Not In Architecture Loans & securities Scenarios Loss & Valuation Space Based Architecture Loans Securities HPI rates Loss Forecasts SLA Custom Templates Interest rates Valuations OLAP Reports Auto Throttling Registration Validation Market rates Discount rates Manual Process Prior Grid Framework GIGASPACES AWS Registration Model API Management AWS Inbuilt Pluggable Client Model Validation Cohorts management models models & statistics Billing Load Balancing Failover / Recovery Scaling Reporting Provisioning Billing Provisioning Monitoring Job Scheduling Warehouse Model Validation & statistics Node Management SLA Auto Throttling Monitoring Broker (MQ) Sun JMS Discovery Space Based Architecture Persistence Manager Node Management * J2EE Platform Platform J2EE 31
  • 32. Performance, Scalability, Data Security, Data Integrity Central Central Backup Loans Cash Runner PU 100k- Cash runner 100k- Flow Flow 1M 1M Database Database Backup Loans data Loans data grid grid grid Loans Loans cashflow cashflow cluster cluster cluster cluster 60M – 60M – 400M 400M Compute PU Compute PU Compute PU Compute PU orrin o in miirr g m rr g Cashflow Cashflow Cashflow Cashflow Cashflow Cashflow Cashflow Cashflow Cashflow data grid Backup Backup Backup Backup Backup Backup Backup Backup Cashflow Cashflow Cashflow Cashflow Cashflow Cashflow Cashflow Cashflow Model Run Cluster 32 32
  • 33. Performance, Scalability, Data Security, Data Integrity Backup runner Runner PU Loans 100k- 100k- 1M 1M Central Central Cash Cash Flow Flow Database Database Backup Loans data Loans data grid grid Loans Loans cashflow cashflow cluster cluster cluster cluster 60M – 60M – 400M 400M Compute PU Compute PU Compute PU Compute PU rin rin mirro mirro gg Cashflow Cashflow Cashflow Cashflow Cashflow Cashflow Cashflow Cashflow Cashflow data grid Backup Backup Backup Backup Backup Backup Backup Backup Cashflow Cashflow Cashflow Cashflow Cashflow Cashflow Cashflow Cashflow Primatics Gateway Model Run Cluster AWS Provisioning Central Central Backup Loans Cash Runner PU 100k- Cash runner 100k- Flow Flow 1M 1M Database Database Backup Loans data Loans data grid grid Loans Loans cashflow cashflow cluster cluster cluster cluster 60M – 60M – 400M 400M Compute PU Compute PU Compute PU Compute PU rin rin mirro mirro gg Cashflow Cashflow Cashflow Cashflow Cashflow Cashflow Cashflow Cashflow Cashflow data grid Backup Backup Backup Backup Backup Backup Backup Backup Cashflow Cashflow Cashflow Cashflow Cashflow Cashflow Cashflow Cashflow Model Run Cluster 33 33
  • 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. 34
  • 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. 35
  • 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 36
  • 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) 37
  • 38. Summary: Key Takeaways > 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,..) 38
  • 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 39
  • 40. Nati Shalom Natishalom.typepad.com Twitter.com/natishalom Run your own demo http://www.gigaspaces.com/mycloud 40
  • 41. Speakers Argyn Kuketayev Francis de la Cruz Senior Consultant Manager akuketayev@primaticsfinancial.com fcruz@primaticsfinancial.com 703 342 0053 703 342 0438 >quant development team lead >Has been using the Java Programming >using Java since 1998 Language since the days of Java 1.2 >Previously worked on the DoD and Security >degrees in Physics and Finance domain before moving on to the Financial >started in scientific computing 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 41