1. Ing. Stefano Dindo
Zero12 s.r.l.
@stefanodindo
Ing. Paolo Latella
Interact SpA
@latellapaolo
Versatilità del Cloud Computing: dalle App
al Disaster Recovery

2. Chi siamo ??
s
Idea nel 2009
Fondato nel 2011
3 Meetup e 3 eventi

3. TEAM
Ing. Stefano Dindo
Zero12 s.r.l.
s.dindo@zero12.it
@stefanodindo
Ing. Paolo Latella
Interact s.r.l.
paolo.latella@interact.it
@latellapaolo

4. Perchè usare AWS per le App
Flessibilità Scalabilità Varietà di metodi
• Elevata quantità di servizi
• Pay per Use
• Risorse di diverse tipologie
• Strutturare l’infrastruttura secondo
le esigenze di progetto
• Infrastrutturale in caso di
picchi di traffico
• Delle risorse in real-time
• Elasticità di gestire le risorse
su costi orari
• Risorse disponibili al
crescere del progetto
• Protocollo disponibili: JSON,
BSON, SOAP, REST, HTTP/s,
TCP, RTMP
• SDK di sviluppo Mobile
• Supporto di diversi linguaggi
di programmazione server side:
java, Python, PHP, Ruby

6. Distribuzione Geografica

7. Servizi basso livello
Servizi “cross” Strumenti
Architettura Amazon Web Services

8. Region
AZ- A AZ- B AZ- C
Security Groups
Load Balancer
Web Traffic
RDS
o
NoSQL
EBS
S3
EC2
AMI
Cloud
watch
Autoscaling

9. Architetture Cloud
per le App

10. il tuo Storage
il tuo Processore
la tua Estensione
Per le App il Cloud rappresenta :

11. Il tuo Storage:
IAM
STS
1
SimpleDB
S3
2

13. Instagram Case Study
AZ-A
AZ-B
S3
App Terzi
Instagram
IAM
STS

14. Il tuo processore:
AZ-A
AZ-B Multi-AZ

15. La tua estensione
VPC Subnet 1 VPC Subnet 2
Corporate Datacenter
AZ - 1 AZ - 2
Amazon Virtual Private Cloud
EC2 Instance
for mobile
DB E-Mail CRM
File
Server
Connessione VPN

16. Architetture Cloud
per il Disaster
Recovery

17. RPO RTO
Disastro
€€ €€

18. Modelli di costo
Cost savings w/
AWS
Ability to scale – no
arbitrary time limit to
failback
Time!
InfrastructureCost!
Test Test Failover Failback

19. Backup e restore - Backup

20. Backup e restore - recovery

21. In Caso di disastro
1.Recuperare l’ultimo backup da S3
2.Avviare le istanze da AMI preconfigurate
3.Aggiornare i volumi delle istanze dal backup
4.Switch del DNS
Obiettivi
• RTO: tempo necessario ad aggiornare i volumi +
tempo necessario ad avviare le istanze dalle AMI
• RPO: tempo dell’ultimo backup

22. Soluzione “pilot light” - preparazione

23. Soluzione “pilot light” - recovery

24. In caso di disastro
1.Avviare (automaticamente) le risorse intorno alle
risorse “core”
2.Scalare il sistema per il traffico di produzione
3.Switch DNS verso la nuova architettura (AWS)
Obiettivi
• RTO: tempo necessario ad avviare le risorse non
core (es. istanze) + tempo necessario a scalare

25. Soluzione warm standby - preparazione

26. Soluzione warm standby - recovery

27. In caso di disastro
1.Switch del DNS verso l’architettura “hot”
2.Scalare il sistema per il traffico di produzione
Obiettivi
• RTO: tempo necessario allo switch + tempo
necessario per entrare a regime
• RPO: dipende dal tipo di replicazione

28. Soluzione multi sito - preparazione

29. Soluzione multi sito - recovery

30. In caso di disastro
1.Isolare l’architettura guasta
2.Scalare il sistema per il traffico di produzione
Obiettivi
• RTO: tempo di identificazione del guasto
• RPO: dipende dal tipo di replicazione

31. Ing. Stefano Dindo
Zero12 s.r.l.
@stefanodindo
Ing. Paolo Latella
Interact SpA
@latellapaolo
www.meetup.com/awsusergroupitaly