Building Scalable Applications    for the Modern Cloud      Presentation @ VCCF 2012 Tech Labs                 Fotis Stama...
About this presentation● This is not a live demo presentation● It does not present a cloud product● It focuses instead on ...
Intro: Typical Cloud models       image source: http://blog.nexright.com/?p=1
Why/when deploy to the Cloud?● Financial reasons: pay only what you use● Scalability: fast & easy addition of resources● E...
Designing SW for the Cloud● The IaaS environment  ○   monolithic architectures are not an option  ○   design to scale-up /...
Designing SW for the CloudExamples:  ● break down your app in multiple server components     hosted in multiple VMs  ● use...
Actual Example Case Studies
Case Study 1:GSS / MyNetworkFolders● SaaS offering implemented by EBS.gr● A distributed, scalable file storage platform:  ...
Design Decisions● Clustering without session replication● Stateless, RESTful design   ○ easier to scale up   ○ allows buil...
GSS architecture
Deployment to Amazon AWS                                    Components hosted in                                    AWS EC...
Findings● Administration effort is minimal● S3 rules! as a reliable file storage back-end● With an IaaS providers like AWS...
Case Study 2: EUDOXUS● Stakeholder: Hellenic Ministry of Education● Developed, operated and supported by  GRNET http://grn...
Design Goals - Challenges● Multiple APIs and integration with other ISs● Tight schedule, fixed milestones - deadlines  ○ I...
Design decisions● Rich Web-based clients (UIs)  ○ State is handled by the rich clients● Support various APIs  ○ RESTFul AP...
Design decisions (contd)● Use caching as much as possible, at multiple  levels to off-load the back-end storage● Authentic...
High level functional architecture
Technical architecture
The worker (AS) cluster
The data store● Single RDBMS (postgresql) instance with  fallback● “Plan B” alternatives  ○ Cold replicas for reports  ○ S...
Findings● If your user space has an upper bound, you  can make it with an RDBMS● Stateless is the way to go● Use caching a...
Questions
Building Scalable Cloud Applications - Presentation at VCCF 2012
Building Scalable Cloud Applications - Presentation at VCCF 2012
Upcoming SlideShare
Loading in …5
×

Building Scalable Cloud Applications - Presentation at VCCF 2012

744 views

Published on

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

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
744
On SlideShare
0
From Embeds
0
Number of Embeds
8
Actions
Shares
0
Downloads
11
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Building Scalable Cloud Applications - Presentation at VCCF 2012

  1. 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. 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. 3. Intro: Typical Cloud models image source: http://blog.nexright.com/?p=1
  4. 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. 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. 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. 7. Actual Example Case Studies
  8. 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. 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. 10. GSS architecture
  11. 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. 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. 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. 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. 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. 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. 17. High level functional architecture
  18. 18. Technical architecture
  19. 19. The worker (AS) cluster
  20. 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. 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. 22. Questions

×