Your SlideShare is downloading. ×
festival ICT 2013: Versatilità del Cloud Computing: dalle APP al Disaster Recovery
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

festival ICT 2013: Versatilità del Cloud Computing: dalle APP al Disaster Recovery

108
views

Published on

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
108
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
14
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. 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
  • 5. Distribuzione Geografica
  • 6. Servizi basso livello Servizi “cross” Strumenti Architettura Amazon Web Services
  • 7. Region AZ- A AZ- B AZ- C Security Groups Load Balancer Web Traffic RDS o NoSQL EBS S3 EC2 AMI Cloud watch Autoscaling
  • 8. Architetture Cloud per le App
  • 9. il tuo Storage il tuo Processore la tua Estensione Per le App il Cloud rappresenta :
  • 10. Il tuo Storage: IAM STS 1 SimpleDB S3 2
  • 11. Instagram Case Study AZ-A AZ-B S3 App Terzi Instagram IAM STS
  • 12. Il tuo processore: AZ-A AZ-B Multi-AZ
  • 13. 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
  • 14. Architetture Cloud per il Disaster Recovery
  • 15. RPO RTO Disastro €€ €€
  • 16. Modelli di costo Cost savings w/ AWS Ability to scale – no arbitrary time limit to failback Time! InfrastructureCost! Test Test Failover Failback
  • 17. Backup e restore - Backup
  • 18. Backup e restore - recovery
  • 19. 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
  • 20. Soluzione “pilot light” - preparazione
  • 21. Soluzione “pilot light” - recovery
  • 22. 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
  • 23. Soluzione warm standby - preparazione
  • 24. Soluzione warm standby - recovery
  • 25. 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
  • 26. Soluzione multi sito - preparazione
  • 27. Soluzione multi sito - recovery
  • 28. 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
  • 29. Ing. Stefano Dindo Zero12 s.r.l. @stefanodindo Ing. Paolo Latella Interact SpA @latellapaolo www.meetup.com/awsusergroupitaly