From Agile Development to Agile Operations (QCon SF 2009)
Download as PPTX, PDF3 likes1,034 views
From Agile Development to Agile Operations discusses how cloud computing is changing the relationship between development and operations. It suggests design goals for cloud technology to better integrate application design, development, and operations. These include separating applications from infrastructure, enabling computer-assisted design and operations through machine reasoning, and improving collaboration between teams. The document also characterizes an integrated approach with distributed control, open documentation describing systems, model-driven practices, goal-driven specifications, viewpoint-based modeling, collaboration, and governance.
From Agile Development to Agile Operations (QCon SF 2009)
- 1. From Agile Development to Agile OperationsStuart Charlton, CTO, Elastra
- 2. ObjectivesReflecting on how cloud computing is changing the game between development & operationsSuggested design goals for cloud computing technology, to help bridge these worldsCharacterizing an integrated approach to application design, development, and operations2
- 3. About Your PresenterStuart CharltonCanadian, now in San FranciscoCTO, ElastraIn prior lives... BEA Systems, Rogers Communications,Infusion Development,global training & consultingRESTafarian and Data geekStu Says Stuffhttp://stucharlton.com/blog
- 4. The Dev / Ops Game
- 5. The RealitiesOrganizationally & Geographically DistributedDesign and Operations (The Cloud)Performance, Scale, and Availability are due to a complex combination of design and operational decisionsApplication and infrastructure management is complex and inter-disciplinary5
- 6. The World of Design & Operations6
- 7. A Major Cultural SplitDelivery OrientationBig Culture and Tool Gaps!Operations Orientation7
- 8. Applying Agile Practices to Operations?Some can remain auseful guide…Greater value is placed on continuity and riskWhat’s the test environment?More like ”rehearsal”Legacy dependenciesNeed for situational awarenessWhere’s the source?Value expressed through functionalityAutomated Build, Test, IntegrationAutonomous teamsContinuous integration of source…But development practices don’t always translate well
- 9. Example:Why can’t these two servers communicate?Possible areas of problemsSecurityBad credentialsServer ConfigurationWrong IP or PortBad setup to listen or callNetwork ConfigurationWrong duplexBad DNS or DHCPFirewall ConfigurationPorts or protocols not open
- 10. Example:What do I need to do to make this change?Desired ChangeScale-out this clusterBut…Impacts on other systemsSecurity SystemsLoad BalancersMonitoringCMDB / Service DeskArchitecture issuesStateful or stateless nodesRepartitioning?Limits/constraints on scale out?10
- 11. Example:What is the authoritative reality?Desired StateConfiguration TemplateModelScriptWorkflowCMDBCodeCurrent StateOn the serverMight not be in a fileMight get changed at runtimeAnd when you do change…It may not actually changeIt might change to an undesirable settingIt might affect other settings that you didn’t think about11
- 12. Cloud Computing to the Rescue?What Exists, What is MissingWhat we have now:On Demand Provisioning of Commodity InfrastructureOS-level down registration, launch, attachmentOn Demand Provisioning of Constrained ApplicationsWorks for some cases, not integrated cases (yet)What we still need to consider:Configuration as data and as codeCollaboration on design and operationsAccounting for the full value stream of the system
- 13. Suggested Design Goals for Cloud ComputingSeparate Applications from InfrastructureHow far can Black-Box PaaS really go?Enabling Computer-Assisted Design and OperationsIT complexity is getting overwhelmingCan machine reasoning and planning help?Explicit CollaborationBoth design and operations suggest are highly collaborative workBut in operations, not traditionally supported by most tooling13
- 14. An Approach to Integrated Design and Ops14
- 15. Configuration Code, Config, and Models,or What is the Source?Bottom UpScripts & RecipesHand-grown automationRunbooksWorkflow, policyFrameworksChefPuppet, CfengineBuild Dependency SystemsMavenTop DownModeled ViewpointsE.g. Microsoft Oslo, UML, Enterprise ArchitectureModular ContainersE.g. OSGi, Spring, Azure rolesConfiguration ModelsSML, CIMECML , EDML
- 16. 16End-to-End Collaboration & Change ManagementModeled Collaboration & Change Management
- 17. On the other hand…“All Modeling is Programming and All Programming is Debugging” - Neil GuntherNeed visibility into what the model impliesSolutions don’t seem completely satisfactory…Code generation?Plan generation?Runtime adjustment?17
- 18. Accounting Barriers to Agile/Lean OperationsCost AttributionCapex vs. OpexLots of heat, little lightFixed vs. Variable CostMaybe? Still HW focusedAs opposed toLooking at the end-to-endsystem as a value streamCosting based on time calculations for repeatable activities: Time-Driven Activity Based Costing
- 19. An ApproachCloudy, with a chance of …
- 20. Characterizing an Integrated Approach to Cloud Application Design, Dev & OperationsDistributed, Autonomous ControlOwnership & stewardship of artifacts and systems are normally decentralizedOpen Document-Exchange Describing aSystemThe trouble with APIsToday’s attempts: model marts, CMDBs, scripts, POMsContrast to the success of the WebHyperlinked Web ArchitectureNo monolithic documents20
- 21. Characterizing an Integrated Approach to Integrated Cloud App Design & OperationsModel-DrivenMake documents conform to a logical framework and visual notationGoal and Policy Driven“What, not How”: Declarative specificationsAllow for automated planning of operational stepsViewpoint-BasedExtensible modeling languages & constraints21
- 22. Characterizing an Integrated Approach to Integrated Cloud App Design & OperationsCollaborativeLeveraging social computingFaster decision making to enact changes to a systemGovernableAccess control & entitlement enforcement22
- 23. Elastic Modeling Languages – A Beginning23