Your SlideShare is downloading. ×
  • Like
Building Scalable Cloud Applications - Presentation at VCCF 2012
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Now you can save presentations on your phone or tablet

Available for both IPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Building Scalable Cloud Applications - Presentation at VCCF 2012

  • 529 views
Published

Presented at the Techical labs & Live Demonstrations Session of the Virtualization & Cloud Computing Forum 2012 (VCCF 2012). March 14, 2012.

Presented at the Techical labs & Live Demonstrations Session of the Virtualization & Cloud Computing Forum 2012 (VCCF 2012). March 14, 2012.

Published in Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
529
On SlideShare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
9
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Building Scalable Applications for the Modern Cloud Presentation @ VCCF 2012 Tech Labs Fotis Stamatelopoulos (http://www.linkedin.com/in/fstamatelopoulos) Christos Stathis (http://www.linkedin.com/in/chstath)
  • 2. About this presentation● This is not a live demo presentation● It does not present a cloud product● It focuses instead on ○ designing software specifically for the modern cloud ○ building scalable applications● Discusses actual case study implementations
  • 3. Intro: Typical Cloud models image source: http://blog.nexright.com/?p=1
  • 4. Why/when deploy to the Cloud?● Financial reasons: pay only what you use● Scalability: fast & easy addition of resources● Elasticity: adapt to traffic● Ideal for SaaS offeringsRule of thumb:If your traffic/load is constantthen build your data center instead
  • 5. Designing SW for the Cloud● The IaaS environment ○ monolithic architectures are not an option ○ design to scale-up / down ○ monitor everything! have alerts ○ handle latency and replication delays● The PaaS environment ○ the cloud handles scaling ○ coding / lib limitations ○ modular design ○ service oriented approach
  • 6. Designing SW for the CloudExamples: ● break down your app in multiple server components hosted in multiple VMs ● use scalable back-ends: your own DB/NoSQL cluster or services like GAE datastore, AWS SimpleDB ● handle PaaS limitations like: ○ maximum request process time ○ limitations in Java / Python lib support (GAE) ○ no filesystem I/O ○ limitations of high availability, distributed services like AWS SQS
  • 7. Actual Example Case Studies
  • 8. Case Study 1:GSS / MyNetworkFolders● SaaS offering implemented by EBS.gr● A distributed, scalable file storage platform: ○ supporting access via multiple interfaces (web browser, mobile devices, desktop, WebDAV) ○ provides a RESTful API ○ based on our FOSS project gss-project.org (used by GRNET Pithos and the Univ of Zagreb)● It was designed from scratch as a scalable cloud application
  • 9. Design Decisions● Clustering without session replication● Stateless, RESTful design ○ easier to scale up ○ allows building of multiple clients● No HTTP session / no sticky session● Multiple levels of caching (client, front-end, second-level, etc)● Use polyglot storage
  • 10. GSS architecture
  • 11. Deployment to Amazon AWS Components hosted in AWS EC2 instances (VMs) AWS S3 handles files (replicated and highly available storage - PaaS) EBS volumes backed-up to S3 used for persistent VM storage will move to a distributed NoSQL (mongoDB, PaaS AWS service)
  • 12. Findings● Administration effort is minimal● S3 rules! as a reliable file storage back-end● With an IaaS providers like AWS you can achieve real elasticity● Availability and stability of services & resources is excellent, but you still need: ○ Monitoring & alerts is a must ○ Have a consistent backup plan● Fine tuning and good design will save you $$
  • 13. Case Study 2: EUDOXUS● Stakeholder: Hellenic Ministry of Education● Developed, operated and supported by GRNET http://grnet.gr/● A distributed system that supports and streamlines processes and operations related to the textbooks distribution for the higher education institutions of Greece● Handles ~ 300K named users per semester http://eudoxus.gr
  • 14. Design Goals - Challenges● Multiple APIs and integration with other ISs● Tight schedule, fixed milestones - deadlines ○ Incrementally release modules in production● Not finalized requirements ○ Be flexible, handle changing requirements● High availability ○ Redundant architecture ○ Live application updates – no downtime● Handle fluctuating load & traffic
  • 15. Design decisions● Rich Web-based clients (UIs) ○ State is handled by the rich clients● Support various APIs ○ RESTFul APIs (JSON / XML payload) ○ use SOAP-based web services specific cases● Back-end storage: RDBMS vs noSQL decision ○ noSQL offer better scalability than typical RDBMs ○ needed at least a minimal transactional core ○ dropped the initial hybrid approach - full RDBMS design
  • 16. Design decisions (contd)● Use caching as much as possible, at multiple levels to off-load the back-end storage● Authentication / Credentials ○ Stateless mechanism - killed user / http sessions ○ Support both ■ Shibboleth-based authentication for students (identity federation) ■ form based login for other user classes
  • 17. High level functional architecture
  • 18. Technical architecture
  • 19. The worker (AS) cluster
  • 20. The data store● Single RDBMS (postgresql) instance with fallback● “Plan B” alternatives ○ Cold replicas for reports ○ Sharding / hot replication (one writer / multiple readers) ○ Moving parts of the data to NoSQL or even use Solr as a NoSQL data store● Currently handling the load without sweating
  • 21. Findings● If your user space has an upper bound, you can make it with an RDBMS● Stateless is the way to go● Use caching at multiple levels and save on resources
  • 22. Questions