Living in the Cloud
            Conor O'Neill
CEO LouderVoice & Co-Founder HushVine
Introduction
 1.   Me
 2.   History of LouderVoice
 3.   Transition to Cloud
 4.   Current Model
 5.   Scaling
 6.   Issues
 7.   Outline of HushVine
 8.   Node.js + MongoDB
 9.   Iaas vs PaaS
10.   What's Next?
11.   Q&A
Me - 20 yrs Technology Management
○ 1990s : S3/Philips, Integral Design
  ○ Telecoms and then Digital TV
○ 2002 : Advanticus
  ○ Digital Convergence
○ 2003 - 2006 : EMC
  ○ Prof Services around SRM
○ 2006-2006 : McAfee
  ○ Localisation
○ 2006 -Now : LouderVoice
  ○ Customer Reviews SaaS
○ 2011-Now : HushVine
  ○ Social TV on a Second Screen
History of LouderVoice
2005 - We should do a startup
2006 - Build blog reviews aggregation platform
2007 - Expand to non-blogs and Twitter
2008 - Build first API for Business Customer
2009 - Build Widget-based solution
2010 - Move entirely to B2B Model
2011 - Scale
2012 - Grow via Channel and L10N
What it Looks Like 1
What it Looks Like 2
What it Looks Like 3
LAMP
Linux + Apache + MySQL + PHP/Perl/Python

LouderVoice =
  NGINX
  Apache mod_wsgi
  MySQL
  Python
  Django
  Memcached
LouderVoice Architecture
                  NGINX Simple Load Balancer

                                                                 Content Distribution
                                                                      Network


  Application            Application             Application
Server = Apache        Server = Apache         Server = Apache
  + Django +             + Django +              + Django +
    Python                 Python                  Python




           MySQL                         Solr Search                Memcached
Transition to Cloud
Pre-Launch = Simple Shared Hosting
2006 - 2007 = Low-end VPS
2007 - 2009 = Dedicated Softlayer Servers
2009 - Now = 99% Amazon AWS
2011 - Now = Some CloudFoundry, Heroku
and Nodejitsu
Current AWS Setup
A number of generic small EC2 Instances
   1.7GB Memory
   1 Compute Unit
All running Ubuntu 10.04LTS Linux
EBS for all live data
RDS for MySQL
Cloudfront for CDN
S3 for backup
Elastic IP for easy switchover
LouderVoice on AWS
                      Elastic IP


                                                                All Static Content on
                NGINX on EC2 instance
                                                                      Cloudfront




 Application          Application               Application
Server on EC2        Server on EC2             Server on EC2
 with Data on         with Data on              with Data on
     EBS                  EBS                       EBS            Backups on S3




                                   Solr Search on EC2 with     Memcached on EC2 with
      MySQL on RDS
                                         Data on EBS               Data on EBS
How it all Works
 Client site with
  LouderVoice        Widget code, CSS,     Content searched usingSolr
Code running on     images delivered by
 one or more of      Cloudfront CDN for
their web-pages          geographic
                        performance



 Client site with                                Data cached
  LouderVoice                                        using
Code running on                                 Memcached for
 one or more of                                  performance
their web-pages


                    Required content etc
 Client site with    retrieved from App
  LouderVoice              Servers            Reviews/Users/etc
Code running on                              stored/retrieved from
 one or more of                                     MySQL
their web-pages
Other Services
 1.   DNSMadeEasy
 2.   AuthSMTP
 3.   Pingdom
 4.   Google Apps for my Domain
 5.   WordPress
 6.   GitHub
 7.   Redmine
 8.   Bit.ly
 9.   Facebook APIs
10.   Twitter APIs
Management Tools
1.   AWS Console
2.   Elasticfox
3.   Cloudberry Explorer
4.   Digital Mines + Cloud Vertical
5.   Cloudkick
6.   Boto
7.   Putty SSH and CLIs
Scaling
1.   Pre-Optimisation is root of all evil
2.   Think about best/worst case scenario
3.   But do not build it day 1
4.   Don't re-invent wheel
5.   Avoid lock-in technologies
6.   Use Open Source as much as possible
7.   You probably won't be Facebook
8.   Scale vs Time vs Skills vs Money
9.   How fast is fast enough?
Words of Warning
1. Build to your budget not perfection
2. Do you have the skills or can you pay for
   them?
3. It's not cheaper than traditional hosting
4. You get Enterprise Functionality for Small
   Biz
5. Servers disappear, DBs get corrupted,
   backups fail, Amazon has outages. Plan?
6. How mission critical is your service/site?
7. How much downtime can you accept?
Costs
1.   Basic Server costs
2.   Reserved Instances
3.   Database, CDN, EIP, Multi-AZ etc etc
4.   All those other services
5.   People cost - who will manage?
Outline of HushVine
1. Original idea
   a. A power-user filtering Twitter client
   b. Show you all the Tweets you want, hide all the noise
2. Target market narrowed to Social TV
   watching e.g. #xfactor #apprentice
3. Creating unique second screen Social TV
   Platform for Tablet and Smartphone
4. Initially Twitter, then Facebook
5. Back-end = Cloud
6. Front-end = Cross-Platform Mobile
HushVine Outline 2
HushVine Outline 3
HushVine Architecture

  HushVine Tablet, Mobile and Web Apps. Cross-platform using HTML5+CSS3+JS and
                               FeedHenry (or similar)




              HushVine API                         HushVine Dashboards and Analytics



  Node.js + Express = Filtering and Data
           Crunching Platform
                                                        MongoDB NoSQL Database

  Hadoop Non-realtime Data Processing




               Twitter Streaming API delivering realtime sub-set of firehose
Node.js and MongoDB
1. Hot Tech
2. Node.js
  a.   Server Side JavaScript
  b.   Uses Google Chrome V8 Engine
  c.   Massive performance
  d.   Widely understood programming language
3. MongoDB
  a. NoSQL
  b. Document-based DB
  c. Massive performance and scalability
4. 3000 X-Factor Tweets per minute
  a. CPU barely ticking over
IaaS vs PaaS
● IaaS
    ○   Infrastruture as a Service
    ○   e.g. Amazon AWS, Rackspace
    ○   You design you architecture
    ○   No hand-holding, it's all on you
    ○   Ultimate in flexibility
●   PaaS
    ○   Platform as a Service
    ○   e.g. Cloud Foundry, Heroku etc
    ○   You fit within a particular architecture
    ○   Get best-practices built-in
    ○   Reduces your management overheads
CloudFoundry PaaS
● No lock-in, multiple
  Clouds
● Partnered with
  FeedHenry
● VMware
● Spring, Ruby on
  Rails, Ruby and
  Sinatra, Node.js,
  Grails
What's Next
1.   More automation and tools built-in to AWS
2.   Look at more automatic scaling
3.   Re-evaluate cost-benefit of more robustness
4.   Ever-reducing prices
5.   Cost Analysis and tuning
6.   Proper evaluation of Microsoft Azure
7.   Move some aspects to CloudFoundry
8.   Small Business friendly Cloud Offerings
Q&A




      Questions?

Running a business in the Cloud with AWS

  • 1.
    Living in theCloud Conor O'Neill CEO LouderVoice & Co-Founder HushVine
  • 2.
    Introduction 1. Me 2. History of LouderVoice 3. Transition to Cloud 4. Current Model 5. Scaling 6. Issues 7. Outline of HushVine 8. Node.js + MongoDB 9. Iaas vs PaaS 10. What's Next? 11. Q&A
  • 3.
    Me - 20yrs Technology Management ○ 1990s : S3/Philips, Integral Design ○ Telecoms and then Digital TV ○ 2002 : Advanticus ○ Digital Convergence ○ 2003 - 2006 : EMC ○ Prof Services around SRM ○ 2006-2006 : McAfee ○ Localisation ○ 2006 -Now : LouderVoice ○ Customer Reviews SaaS ○ 2011-Now : HushVine ○ Social TV on a Second Screen
  • 4.
    History of LouderVoice 2005- We should do a startup 2006 - Build blog reviews aggregation platform 2007 - Expand to non-blogs and Twitter 2008 - Build first API for Business Customer 2009 - Build Widget-based solution 2010 - Move entirely to B2B Model 2011 - Scale 2012 - Grow via Channel and L10N
  • 5.
  • 6.
  • 7.
  • 8.
    LAMP Linux + Apache+ MySQL + PHP/Perl/Python LouderVoice = NGINX Apache mod_wsgi MySQL Python Django Memcached
  • 9.
    LouderVoice Architecture NGINX Simple Load Balancer Content Distribution Network Application Application Application Server = Apache Server = Apache Server = Apache + Django + + Django + + Django + Python Python Python MySQL Solr Search Memcached
  • 10.
    Transition to Cloud Pre-Launch= Simple Shared Hosting 2006 - 2007 = Low-end VPS 2007 - 2009 = Dedicated Softlayer Servers 2009 - Now = 99% Amazon AWS 2011 - Now = Some CloudFoundry, Heroku and Nodejitsu
  • 11.
    Current AWS Setup Anumber of generic small EC2 Instances 1.7GB Memory 1 Compute Unit All running Ubuntu 10.04LTS Linux EBS for all live data RDS for MySQL Cloudfront for CDN S3 for backup Elastic IP for easy switchover
  • 12.
    LouderVoice on AWS Elastic IP All Static Content on NGINX on EC2 instance Cloudfront Application Application Application Server on EC2 Server on EC2 Server on EC2 with Data on with Data on with Data on EBS EBS EBS Backups on S3 Solr Search on EC2 with Memcached on EC2 with MySQL on RDS Data on EBS Data on EBS
  • 13.
    How it allWorks Client site with LouderVoice Widget code, CSS, Content searched usingSolr Code running on images delivered by one or more of Cloudfront CDN for their web-pages geographic performance Client site with Data cached LouderVoice using Code running on Memcached for one or more of performance their web-pages Required content etc Client site with retrieved from App LouderVoice Servers Reviews/Users/etc Code running on stored/retrieved from one or more of MySQL their web-pages
  • 14.
    Other Services 1. DNSMadeEasy 2. AuthSMTP 3. Pingdom 4. Google Apps for my Domain 5. WordPress 6. GitHub 7. Redmine 8. Bit.ly 9. Facebook APIs 10. Twitter APIs
  • 15.
    Management Tools 1. AWS Console 2. Elasticfox 3. Cloudberry Explorer 4. Digital Mines + Cloud Vertical 5. Cloudkick 6. Boto 7. Putty SSH and CLIs
  • 16.
    Scaling 1. Pre-Optimisation is root of all evil 2. Think about best/worst case scenario 3. But do not build it day 1 4. Don't re-invent wheel 5. Avoid lock-in technologies 6. Use Open Source as much as possible 7. You probably won't be Facebook 8. Scale vs Time vs Skills vs Money 9. How fast is fast enough?
  • 17.
    Words of Warning 1.Build to your budget not perfection 2. Do you have the skills or can you pay for them? 3. It's not cheaper than traditional hosting 4. You get Enterprise Functionality for Small Biz 5. Servers disappear, DBs get corrupted, backups fail, Amazon has outages. Plan? 6. How mission critical is your service/site? 7. How much downtime can you accept?
  • 18.
    Costs 1. Basic Server costs 2. Reserved Instances 3. Database, CDN, EIP, Multi-AZ etc etc 4. All those other services 5. People cost - who will manage?
  • 19.
    Outline of HushVine 1.Original idea a. A power-user filtering Twitter client b. Show you all the Tweets you want, hide all the noise 2. Target market narrowed to Social TV watching e.g. #xfactor #apprentice 3. Creating unique second screen Social TV Platform for Tablet and Smartphone 4. Initially Twitter, then Facebook 5. Back-end = Cloud 6. Front-end = Cross-Platform Mobile
  • 20.
  • 21.
  • 22.
    HushVine Architecture HushVine Tablet, Mobile and Web Apps. Cross-platform using HTML5+CSS3+JS and FeedHenry (or similar) HushVine API HushVine Dashboards and Analytics Node.js + Express = Filtering and Data Crunching Platform MongoDB NoSQL Database Hadoop Non-realtime Data Processing Twitter Streaming API delivering realtime sub-set of firehose
  • 23.
    Node.js and MongoDB 1.Hot Tech 2. Node.js a. Server Side JavaScript b. Uses Google Chrome V8 Engine c. Massive performance d. Widely understood programming language 3. MongoDB a. NoSQL b. Document-based DB c. Massive performance and scalability 4. 3000 X-Factor Tweets per minute a. CPU barely ticking over
  • 24.
    IaaS vs PaaS ●IaaS ○ Infrastruture as a Service ○ e.g. Amazon AWS, Rackspace ○ You design you architecture ○ No hand-holding, it's all on you ○ Ultimate in flexibility ● PaaS ○ Platform as a Service ○ e.g. Cloud Foundry, Heroku etc ○ You fit within a particular architecture ○ Get best-practices built-in ○ Reduces your management overheads
  • 25.
    CloudFoundry PaaS ● Nolock-in, multiple Clouds ● Partnered with FeedHenry ● VMware ● Spring, Ruby on Rails, Ruby and Sinatra, Node.js, Grails
  • 26.
    What's Next 1. More automation and tools built-in to AWS 2. Look at more automatic scaling 3. Re-evaluate cost-benefit of more robustness 4. Ever-reducing prices 5. Cost Analysis and tuning 6. Proper evaluation of Microsoft Azure 7. Move some aspects to CloudFoundry 8. Small Business friendly Cloud Offerings
  • 27.
    Q&A Questions?