Leveraging the Cloud - Getting the Most Bang for your Buck ( presentation by Salesforce on optimizing AWS costs )
•
3 gostaram•2,123 visualizações
This presentation was given by Nate Lindstrom, Director of Network Operations at Salesforce at the Silicon Valley Cloud Computing Meetup on April 4th 2013 in Mountain View - special thanks to host Quixey, along with organizers Scalr and Cloudyn. SalesForce,
Recomendados
Mais conteúdo relacionado
Mais procurados
Destaque
Destaque (16)
Semelhante a Leveraging the Cloud - Getting the Most Bang for your Buck ( presentation by Salesforce on optimizing AWS costs )
Semelhante a Leveraging the Cloud - Getting the Most Bang for your Buck ( presentation by Salesforce on optimizing AWS costs ) (20)
Último
Último (20)
Leveraging the Cloud - Getting the Most Bang for your Buck ( presentation by Salesforce on optimizing AWS costs )
- 1. Leveraging the cloud Getting the most bang for your buck
- 2. Nate Lindstrom Director of Network Operations in/nwlindstrom
- 3. salesforce desk We make it easy for you to support customers right from the browser, via email, phone, chat, web, Facebook, and Twitter We provide a hosted, cloud-based SaaS help desk platform for SMB
- 5. Process requirements Formal, documented change management ISO 27001 compliance SOX section 404 compliance Safe Harbor certification
- 6. Single file change process RFC Make SME RFC create pull reviews Close d request request d Change applied to staging ✓Effects observed Change applied to production Changes can be made rapidly and safely FIM updated Unauthorized changes reverted by the CMS or flagged by CloudPassage Halo FIM
- 7. Under the hood Chicken-and-egg problem for new instances Puppet determines role based on hostname Hostname isn’t set on new instances
- 8. How we start instances Scri pt Name=web01.desk .com Pupp web01.desk.com nginx ip-10-20-30-40.us-west-1.compute.internal et node /^webd+.desk.com$/ AMI inherits production_app { include web}
- 9. How we monitor instances web01.desk.com cron S3 Buck et
- 10. Effective monitoring Icinga is the most comprehensive open source monitoring solution available
- 11. Secret change process RFC Make SME RFC create pull reviews Close d request request d Change FIM applied to production updated “Secret” as in production secrets, like passwords
- 12. Under the hood Storing production secrets in plain text is bad Sending decryption key over same channel as encrypted data is bad
- 13. Secure repositories TechO Everyo ps ne Full Access Pull Request Only Puppet Prod Non-Prod git Credentials Credentials Repo GnuPG GnuPG
- 14. Secure distribution AMI Puppet GnuPG git git Key Repo Secrets Instance Puppet Credentials
- 15. What the cloud means to us More typing, less driving
- 16. Physical asset tracking If you came to doubt the accuracy of your CMDB, you could always fall back on a physical inventory Almost always, anyway
- 17. Virtual asset tracking When you don’t have any physical assets it’s even easier to “lose” instances “Lost” instances can silently consume big $$$
- 18. How an instance can be lost Provisioning script loses connectivity during launch Instance fails to upload existence information to S3 Provisioning CMDB Script Launches Updates S3 Instance Buck Uploads et
- 19. Minimizing lost instances Your CMDB may not see your lost instances consuming $$$, but Cloudyn does Cloudyn makes it easy to maintain an efficient and lean cloud presence
- 20. JIT capacity Let your servers order more servers
- 21. Auto Scale architecture Everything should scale horizontally
- 22. Auto Scale in action Loosely-coupled tiers provide greatest flexibility Scale up quickly, scale down slowly ELB Traffic Decreasing Traffic Increasing Web Web Web Web Web Web Web ELB App App App App App App
- 23. Auto Scaling control Scalr makes managing dynamic environments in the cloud easy and painless
- 25. Think in clusters If one instance is having problems, replace it If many instances are having problems, dig deeper Use the 1, 2, 3 rule for determining response ELB Instanc Instanc Instanc Instanc Instanc e e e e e
- 26. Architecting for failure Build it to land gracefully
- 27. Expect failure Make use of regions and availability zones Avoid storing sessions on any one server The cloud is inherently unreliable, but your app doesn’t need to be AWS us-west-1 us-east-1 us-west-1a us-west-1b
- 28. Security awareness False security is worse than no security
- 29. Cloud isn’t private Multitenancy means the cloud is never truly private Build security in from the very beginning Apply defense in depth Internet ELB Web ELB App DB
- 30. Security groups are limited An instance’s security groups cannot ever be changed Security groups can only limit inbound (ingress) traffic Security groups cannot restrict outbound (egress) traffic
- 31. Comprehensive security CloudPassage Halo allows the implementation of comprehensive security with minimal effort
- 32. The cloud... Is not a data center Is only as secure as you make it Is very expensive if not managed well Works best with lots and lots of little servers Will occasionally fail
- 33. Thank you!