OpenStack Israel Summit 2013 - It’s the App, Stupid!


Published on

Orchestration, DevOps Automation & What’s in Between

Published in: Technology, Business
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • 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
  • 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
  • OpenStack Israel Summit 2013 - It’s the App, Stupid!

    1. 1. It’s the App, Stupid!Orchestration, DevOps Automation& What’s in BetweenUri CohenHead of Product @ GigaSpaces@uri1803#openstackIL
    2. 2. SomeBackground
    3. 3. OpenStack IsDoing Great,Thanks• 2013: “The year of theuser”• 166 contributingentities• A few big public clouds• Many public customeruse cases– “2013 - Year of the User”
    4. 4. And We AllKnow thePayPal Story(or Do We?)
    5. 5. Platform IsMore Well-Roundedthan Ever
    6. 6. But ThenAgain, It’saboutServices &Apps
    7. 7. Automation IsKey for:• Testability• Consistency• Agility• Stability
    8. 8. What It ReallyTakes toDeploy andManage AppsProvisionInstallConfigureDeployMonitorScale
    9. 9. The Automation ContinuumEnvironmentCreationSW Infra.Setup &ConfigCode Push Monitoring& AlarmingRepairing Scaling
    10. 10. The Automation Continuum• VMs / Bare Metal Servers• Network (Firewall, NAT, VPN, etc.)• LB Groups• Storage (Block / Blob)EnvironmentCreation
    11. 11. The Automation ContinuumSW InfrastructureSetup & Configuration• OS Configuration (e.g. ulimit, useradd, permissions, etc.)• Installation of packages and middleware components• Startup orchestration• Update (not very frequent)
    12. 12. The Automation ContinuumCode 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. 13. The Automation ContinuumMonitoring& 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. quotautilization)• Alarms upon failure or when reaching certainthresholds– Simple (a-la CloudWatch) or complex (CEP driven)
    14. 14. The Automation ContinuumRepairing• 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. 15. The Automation ContinuumScaling• 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. 16. What’sAvailable forToday’sStackers
    17. 17. Orchestration ToolsEnvironmentCreationSW Infra.Setup &ConfigCode Push Monitoring& AlarmingRepairing ScalingGrizzly, HavanaV1
    18. 18. CM ToolsEnvironmentCreationSW Infra.Setup &ConfigCode Push Monitoring& AlarmingRepairing Scaling
    19. 19. MonitoringEnvironmentCreationSW Infra.Setup &ConfigCode Push Monitoring& AlarmingRepairing Scaling
    20. 20. PaaS FrameworksEnvironmentCreationSW Infra.Setup &ConfigCode Push Monitoring& AlarmingRepairing Scaling
    21. 21. Tying ThePiecesTogetherUsuallyLooks LikeThis
    22. 22. AWSOpsWorks,AKADevOpsAutomation least not in an OpenStack conference)
    23. 23. UrquhartCalled itTheComposablePaaSJames Urquhart
    24. 24. And SomeCalled ItThe PaaS JailBreakerorDevOps MeetsPaas(Yours trulyincluded) Shalom
    25. 25. DevOpsAutomationGives YouControl• A Way to tie all thepieces on theAutomation Continuumtogether– Use what works nest, notreinvent each piece fromscratch
    26. 26. So You Can Have ThisEnvironmentCreationSW Infra.Setup &ConfigCode Push Monitoring& AlarmingRepairing Scaling
    27. 27. DevOps Automation, High LevelOrchestratorCIMonitoring &AlarmingCM InfrastructureAPI
    28. 28. OpsWorks isCool, butWhat AboutOpenStack?
    29. 29. TOSCATopology and Orchestration Specification for Cloud Applications
    30. 30. Heat(ProbablyAfterHavana)• New DSL, more than justcloud resources -complete aplication stackorchestration• Inspired by TOSCA andCAMP• Looks quite promising• Current state: DSL proposal• Still not covering postdeployment aspects aspart of the DSL
    31. 31. Donabe(Not YetPublic)• Started by Cisco tohandle networkconfiguration• Quickly evolved tohandle applicationstack configuration• Not much publicinfo, will be releaseas OSS soon (?)
    32. 32. • Open source• Does most of this stuffon OpenStack today• Integrates with Chef,Puppet, Jenkins OOTB• Still proprietary API– TOSCA and Heat, stay tuned…
    33. 33. Thank You!