Applications at Scale
•
0 likes•422 views
ServiceMesh's Dave Roberts presented, originally at Cloud Connect 2012, Santa Clara CA Applications are the heart of enterprise IT. Everything that IT does is focused on delivering new functionality through applications. Unfortunately, for most enterprises, the application delivery process is tremendously inefficient, leading outcomes where more application development projects are canceled than are completed.
Recommended
Recommended
More Related Content
What's hot
What's hot (18)
Viewers also liked
Viewers also liked (20)
Similar to Applications at Scale
Similar to Applications at Scale (20)
Recently uploaded
Recently uploaded (20)
Applications at Scale
- 1. THE AGILE IT PLATFORM Applications at Scale Dave Roberts SVP, Business Development and Platform Ecosystem dave.roberts@servicemesh.com Twitter: @sandhillstrat
- 2. ServiceMesh Overview Continuous Big-Data Analytics Enterprise PaaS Delivery (e.g. Grid, Hadoop) Governance Business Policies Policy- Complex Auto- scaling, Version- Self-service controlled controlled topology elasticity, App Store asset API provisioning and SLA repository Workflow mgmt. Access Management ServiceMesh Service Management Agility Platform Resource Management Public and Private Cloud Implementations Resources 2
- 3. What is “scale?” 3
- 7. Fundamental Question: How can we generate repeatable (positive) outcomes at scale? 7
- 8. 8
- 9. 9
- 10. 1 Planning at Scale 2 Construction at Scale 3 Deployment and Operations at Scale 10
- 11. 1 Planning at Scale 2 Construction at Scale 3 Deployment and Operations at Scale 11
- 12. 1. Triage 2. Categorization 12
- 13. “Is this application suitable for the cloud?” • Cloud Value refers to economic, High-priority candidates business, and functional filters that assign significant business value when transitioned to cloud environments. Cloud Readiness • Cloud Readiness refers to characteristics of latency, geography, responsiveness, platform, data, and organizational requirements that lend itself to cloud environments. Cloud Value Low-priority candidates 13
- 14. Migration Analysis Categories Application Portfolio Migration Group 1 Migration Group 2 Migration Group 3 Layer “Stateful” “Less Stateful” “Stateless / Cloud Native” Business Logic Unchanged – embedded in Unchanged Refactored to align with “cloud stateful image native” design patterns Application Framework Unchanged – embedded in Possible upgrade to the Refactored to align with “cloud stateful image current IPaaS Platform & OS native” design patterns versions Platform (e.g. IIS/.Net) Unchanged – embedded in Possible version upgrade Possible version upgrade stateful image Operating System (e.g. Unchanged – embedded in Possible version upgrade Possible version upgrade Windows 2008) stateful image Agility Integration Yes Yes Yes 14
- 15. 1 Planning at Scale 2 Construction at Scale 3 Deployment and Operations at Scale 15
- 16. 1. Standardized building blocks 2. Tool and process integration 3. Environment promotion 16
- 17. Provide standardized “as-a-service” building blocks to lower support costs, risks, and improve productivity Design Development Test Operations Self-service portal Unified governance and visibility Portfolio of Role-based access standardized offerings: iPaaS Offerings Standardized Packages 3rd-Party PaaS/SaaS Enterprise PaaS Windows 2008 Monitoring agents Salesforce.com Hadoop RHEL HIDS Force.com Cloud Foundry SQL Server Anti-virus Azure Apprenda IIS.NET Virtual Firewalls Google Apps WebSphere others… others… others… WebLogic 17
- 18. Leverage existing tools to access resources while retaining full control Design Development Test Operations SDLC systems others… and tools: API access REST-based API Unified governance and visibility Role-based access control via API Bare Metal Dev Clouds QA Clouds others… Environments 1-off sandbox environments 18
- 19. The Environment is an Artifact! Environment = VM topology, middleware configs, firewall rules, etc. Development creates Dev QA Prod application runtime Dev Cloud Reqmnts QA Cloud Reqmnts Prod Cloud Reqmnts environment as part of the development process. The environment travels with the code and data sets as a part of the development process. Prod Cloud Dev Cloud QA Cloud What gets tested and Internal Private Cloud runs in production is exactly what development created. Many other providers… 19
- 20. 1 Planning at Scale 2 Construction at Scale 3 Deployment and Operations at Scale 20
- 21. 1. Agile Ops 2. Traceability 3. Policy and Governance 4. Reporting and SLA Management 21
- 22. Characteristics of Agile Operations Traditional Agile Ops Dev Deployed App 1 Dev Deployed App 2 Apps 1…n App 3 Deployment takes weeks or months Deployment takes minutes Manual, custom assembly for each app Automated, repeatable outcomes Craftsman model with high labor costs that scale Craftsman build the robots instead of working in the assembly line 22
- 23. Reference architecture for traceability and control Deliver precise versioning, roll-back and deployment management. Monitoring/PerfMgmt Chargeback/Billing LDAP/AD Services and Stateless Environment Others Resources Images Configuration Code Development Base Environment Dev Team Deploy Code Test Base Environment Repository Mgr Deploy Dev Team • Images • Packages Deploy Code • Resources Staging • Configuration Environment Base Deploy Dev Team Production Code Environment Base Dev Team Development Operations 23
- 24. Enforce fine-grain policies to govern across teams, resources, and environments London External NYC Dev India QA Dev Team Consultants Team Team Sample Policies: Regulatory: Live test data can only be deployed on secure private cloud. Create and enforce policies Access: Contractors are End-to-end audit trail permitted access only to Extensible policy framework external public cloud Policies control access to resources accounts. Policies determine right- placement 24
- 25. Detailed drill-down/roll-up reporting Roll-up or drill-down into groups, projects, environments, instances, etc Comprehensive audit trail Cost reporting and chargeback 25
- 26. Manage SLAs with automatic thresholds, compound rules, and custom notifications Setup highly detailed performance Create compound rules thresholds for auto-scaling based on chains of events Create custom notifications based on different lifecycle events 26
- 27. Outcomes 27
- 28. Customer Example: Time-to-Market Reduction Current External Cloud Internal Baseline Provider Pre-Production Cloud Platform 70 days Not Available -52 days (41% reduction) Client specific patches/utilities 17 days -11 days (-8%) -11 days (8% reduction) IaaS (Base OS) 40 days -36 days (-29%) -36 days (29% reduction) Total Provisioning 127 days -47 days (37%) -99 days (78% reduction) Time NOTE: All time-to-market scenarios include a conservative 20-days allocated for general purpose build and test tasks. 28
- 29. Customer Example: Migration Cost Savings Ramp Customer migration plan based solely on known server refresh dates: Virtual Machine Month Month Month Month Month Month Month Month Month Month Month Month Types 1 2 3 4 5 6 7 8 9 10 11 12 Windows Servers 32 32 41 41 49 49 9 9 0 0 0 0 Virtual Servers - 0 0 36 36 36 70 34 102 102 69 150 81 Sandbox Virtual Servers - 0 0 0 26 26 27 27 11 11 10 10 0 Silver Virtual Servers - 0 0 0 0 0 12 12 22 22 11 11 0 Gold Outsourced 0 18 18 29 73 63 88 77 41 33 8 8 Physical Servers In-House 0 0 0 0 29 29 64 64 63 63 27 27 Physical Servers Total (VMs) 32 50 94 132 213 250 233 285 239 184 205 116 Running Total 32 82 176 308 521 770 1004 1289 1528 1712 1917 2034 (VMs) Total Monthly 45,728 117,178 214,784 376,892 681,269 9891500 1,360,256 1,704,281 2,045,812 2,354,648 2,564973 $2,823,966 Savings ($) Notes Approx $3M • Includes only existing workloads due for refresh, i.e. excludes new demand. • Excludes servers with unknown Refresh Dates. per month savings 29
- 30. Thank you Dave Roberts Vice President, Business Development and Platform Ecosystem Email: dave.roberts@servicemesh.com Web: http://www.servicemesh.com/ Company Twitter: @servicemesh Personal Twitter: @sandhillstrat 30
Editor's Notes
- NOTES: Earlier I mentioned that Continuous Delivery encompasses developer resources and deployment environments… not just the code. Talk a little about the “resources” side of that statement.
- NOTES: Its more than just self-service portals….Folks want to access deployment environments seamlessly as part of their daily work routine. You want to access it from the tools you already use, and in most cases you don’t need to be exposed to the inner workings of how those environments are getting spun up. If you can provide these on-demand and tailored for the user’s needs… you can eliminate significant wait time. Agility has a REST-based API that is full featured. That includes role-based access rights managed through the API. You can access Agility from a wide range of tools to spin up an unlimited variety of deployment environments…. All of which are fully governed and controlled. These environments are all tracked and versioned as well… so you can share them with other teams, and/or roll back as needed.
- Center = artifact repository. Do this well = version everything. Precise versioning.Product apps…on the left side.Architect producing platforms and infrastructure (ServiceMesh)Configuration has 2 faces: environment independent. Environment specific configuration.Problem? Probably related to a software change. Ask “what changed”? Need a yesterday button with precisely versioned artifacts. (or don’t repair…reprovision).Strong versioning. This scales. A lot of participation of organization to publish change. Apache makes a change. Not everyone will push the update right away. Not on same day. Rolling upgrades instead. Have to have that kind of infrastructure. Zooming into the 80% problem. This is future state. Current state is series of tailored applications. Each LOB has a separate process. No economies of scale. A bunch of small independent units with different processes. Each group on left going to a separate environment in parallel. This x number of LOBs. (Stop 32:09)
- Enterprise organizations can have hundreds of separate pre-production teams…. All of which need access to resources and environments. Providing automated, policy-driven governance is important to efficiently empower these teams with self-service access to the resource (such as platforms and applications) that they need, along with rightplacement to the appropriate sandbox environments. Agility Platform allows you to create and enforce these policies, which are leveraged across the SDLC to give you an end-to-end audit trail. The policy framework is also designed for extensibility… so that policies can be easily created for unique industry or organizational needs. For example… you could create a regulatory policy… such as a requirement that Live test data can only be used on the secure private cloud.….. Or a security policy…. So that external dev contractors can only use external public cloud accounts.
- NOTES: (OSI/SOA refers to the client’s approved Operating System Image / Standard Operation Environment, which includes a range of the client’s patches and client specific utilities. )Traditional data center: this current approach includes 20 days for customer application build and test processes. It is assumed this is consistent across all other approaches as well. Pre-Production Cloud:Reductions mainly in automated provisioning and for design work across all layers.External Cloud Provider (Fujitsu and HP)CSPs were asked primarily for data on their core IaaS services. “Platform” services were not available from the CSPs. OSI/SOE are assumed to be the same as for pre-production cloud, but are likely to be less as an increase in engagement effort and decision gateways would be likely.