2014 IEEE DOTNET CLOUD COMPUTING PROJECT Automatic scaling of internet applic...
Opensymbol - BMW case study
1. How BMW Uses SugarCRM
& Amazon EC2 for Lead
Management in Italy
Enrico Maggi – co founder and CEO of OpenSymbol – Italian SugarCRM Gold Partner
http://www.opensymbol.it
enrico.maggi@opensymbol.it
2. Important information
This is not the full presentation
We’re still waiting for BMW approval before publishing
the full one
For more information please contact
enrico.maggi@opensymbol.it
3. The Italian Market for BMW
Italy is in the top 5 market in the world for BMW - Mini
4. The Italian Market for BMW
Italy is the second market in the world for BMW Motorrad
5. BMW Italy Sales Organization
National sales company based in Milan
6. BMW Italy Sales Organization
Nearly 150 dealers in all over the italian territory (3 brands)
7. Why SugarCRM
High degree of software customizability
High degree of software integrability
Opensymbol focus on BMW needs: starting from the
earlier stages Opensymbol always kept in mind customer
needs
Opensymbol skills on integrating other softwares and on
fast customizing SugarCRM
Deployment Flexibility: on demand but with the option to
install in house if needed
Price Flexibility: the same price per user regardless of the
number of users (from 100 to 2000)
8. How to size the hardware?
How to size the hardware to guarantee the same price per
user regardless of the number of users?
10. Amazon WS: instances
Instances are similar to Virtual Servers:
STD Small / Medium / Large
– Up to 15GB RAM with up to 1,6TB disk space
– Up to 8 EC2 Compute Units 64bit
HIGH MEMORY Extra / Double Extra / Quadruple Extra
– Up to 64GB RAM with up to 1,6TB disk space
– Up to 26 EC2 Compute Units 64bit
HIGH CPU Medium / Extra Large
– Up to 7GB RAM with up to 1,6TB disk space
– Up to 20 EC2 Compute Units 64bit
11. Amazon WS: pricing model
“per instance-hour consumed for each instance type, from
the time an instance is launched until it is terminated”
12. The architecture on Amazon Cloud
Database scalability
Dynamic web server scalability
High availability
Disaster Recovery
During working hours there can be as many web servers as needed.
Nightly there are usually only two Amazon Instances up and running.
13. Database: scalability
No MySQL Proxy (it’s in alpha stage already)
No MySQL Cluster (different table type, too focoused for
typical “telco” needs)
So we decided to setup a Single Amazon Instance
(currently a “Large instance”) with failover criteria based
on Linux Debian
14. Database: scalability
The database is not strictly “elastic”, but we can easily scale
up or down by switching the db server to a larger or
smaller instance (in less than one hour) to guarantee very
good performances to users
17. Web Server: elastic scalability
Nginx (small linux instance for loadbalancing management)
Apache Web Server based on Linux Debian (e.g. medium
instance) scalable up or down as load increases / decreases
18. Web Server: elastic scalability
Nightly there is only 1 virtual web server up and running
19. Web Server: elastic scalability
During working hours as load increases / decreases
e.g. at 8 am
e.g. at 11 am
e.g. at 4 pm
20. Amazon recommends
1. Have a coherent backup and restore strategy for your
data and automate it
2. Build process threads that resume on reboot
3. Allow the state of the system to re-sync by reloading
messages from queues
4. Keep pre-configured and pre-optimized virtual images to
support (2) and (3) on launch/boot
5. Avoid in-memory sessions or stateful user context, move
that to data stores.