OpenStack Israel Summit 2013 - It’s the App, Stupid!
•Descargar como PPTX, PDF•
2 recomendaciones•3,257 vistas
Orchestration, DevOps Automation & What’s in Between
Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Destacado
Similar a OpenStack Israel Summit 2013 - It’s the App, Stupid!
Similar a OpenStack Israel Summit 2013 - It’s the App, Stupid! (20)
Más de Uri Cohen
Más de Uri Cohen (20)
Último
Último (20)
OpenStack Israel Summit 2013 - It’s the App, Stupid!
- 1. It’s the App, Stupid! Orchestration, DevOps Automation & What’s in Between Uri Cohen Head of Product @ GigaSpaces @uri1803 #openstackIL
- 3. OpenStack Is Doing Great, Thanks • 2013: “The year of the user” • 166 contributing entities • A few big public clouds • Many public customer use cases – “2013 - Year of the User”
- 4. And We All Know the PayPal Story (or Do We?)
- 6. But Then Again, It’s about Services & Apps
- 7. Automation Is Key for: • Testability • Consistency • Agility • Stability
- 8. What It Really Takes to Deploy and Manage Apps Provision Install Configure Deploy Monitor Scale
- 9. The Automation Continuum Environment Creation SW Infra. Setup & Config Code Push Monitoring & Alarming Repairing Scaling
- 10. The Automation Continuum • VMs / Bare Metal Servers • Network (Firewall, NAT, VPN, etc.) • LB Groups • Storage (Block / Blob) Environment Creation
- 11. The Automation Continuum SW Infrastructure Setup & Configuration • OS Configuration (e.g. ulimit, useradd, permissions, etc.) • Installation of packages and middleware components • Startup orchestration • Update (not very frequent)
- 12. The Automation Continuum Code Push • User code installation on software infrastructure – e.g. jar, war, rails sources, PHP sources, DB scripts, etc. – After setup – On going - can be very frequent • Push policies (canary, red/black, a/b)
- 13. The Automation Continuum Monitoring & Alarming • What should be monitored? – Availability: are my services up or not? – Performance (OS &services level metrics). How are my services doing? – State: What’s running where, state of system resources (e.g. quota utilization) • Alarms upon failure or when reaching certain thresholds – Simple (a-la CloudWatch) or complex (CEP driven)
- 14. The Automation Continuum Repairing • Various types of failures – Service level – service not responding, process failed – VM / Node failure – Infrastructure failure (disk, network) • Automation tools can go a certain way – Resiliency should also be part of the SW stack
- 15. The Automation Continuum Scaling • Manually or Automatically (alarm triggered) • Scaling by – Adding / removing instances (AKA out / in) – Adding / removing resources to / from an existing instance (AKA up / down) • For both, it needs to be supported by the SW stack
- 16. What’s Available for Today’s Stackers http://transferium.files.wordpress.com/2010/11/hipster-1.jpg
- 17. Orchestration Tools Environment Creation SW Infra. Setup & Config Code Push Monitoring & Alarming Repairing Scaling Grizzly, Havana V1
- 18. CM Tools Environment Creation SW Infra. Setup & Config Code Push Monitoring & Alarming Repairing Scaling
- 19. Monitoring Environment Creation SW Infra. Setup & Config Code Push Monitoring & Alarming Repairing Scaling
- 20. PaaS Frameworks Environment Creation SW Infra. Setup & Config Code Push Monitoring & Alarming Repairing Scaling
- 22. AWS OpsWorks, AKA DevOps Automation http://www.allthingsdistributed.com/2013/02/aws-opsworks.html He-Who-Must-Not-Be-Named (At least not in an OpenStack conference)
- 24. And Some Called It The PaaS Jail Breaker or DevOps Meets Paas (Yours truly included) http://bit.ly/12Gor4W Nati Shalom
- 25. DevOps Automation Gives You Control • A Way to tie all the pieces on the Automation Continuum together – Use what works nest, not reinvent each piece from scratch
- 26. So You Can Have This Environment Creation SW Infra. Setup & Config Code Push Monitoring & Alarming Repairing Scaling
- 27. DevOps Automation, High Level Orchestrator CI Monitoring & Alarming CM Infrastructure API
- 28. OpsWorks is Cool, but What About OpenStack?
- 29. TOSCA Topology and Orchestration Specification for Cloud Applications
- 30. Heat (Probably After Havana) • New DSL, more than just cloud resources - complete aplication stack orchestration • Inspired by TOSCA and CAMP • Looks quite promising • Current state: DSL proposal • Still not covering post deployment aspects as part of the DSL
- 31. Donabe (Not Yet Public) • Started by Cisco to handle network configuration • Quickly evolved to handle application stack configuration • Not much public info, will be release as OSS soon (?)
- 32. • Open source • Does most of this stuff on OpenStack today • Integrates with Chef, Puppet, Jenkins OOTB • Still proprietary API – TOSCA and Heat, stay tuned…
- 33. Thank You!
Notas del editor
- Great at creating openstack resources, basic integration with Chef / puppet for swconfig, basic built in monitoring and alarming, moving to ceilometer in Havana
- Env setup is not automated SW infra setup is good but has no startup orchestration
- Healthnmon is more geared toward cloud resource monitoring and is has more opinionated domain model, ceilometer seems to be picking momentum and
- Env setup is not automated but with very little control, same for SW infra. Code management capabilities are great, incremental updates, devenv integration, etc. Very basic if any monitoring and alarming. Repairing is good within he boundaries of the platform (and not for the underlying cloud)Scaling support is also quite good, though mostly manual
- http://www.allthingsdistributed.com/2013/02/aws-opsworks.html
- Werner termed the coin
- Werner termed the coin
- Even AWS used Chef for this…
- Templates to describe and drive all these processes
- Talk about what’s next