DevOps and the Enterprise Cloud
•
1 like•540 views
This document discusses DevOps and its challenges in the enterprise. It identifies 5 common pitfalls that enterprises face when adopting DevOps: 1) lack of understanding of DevOps terminology, 2) balancing development and operations interests and accountability, 3) establishing the correct culture, 4) finding champions for buy-in, and 5) justifying DevOps to the business. It then provides recommendations for addressing these challenges, such as focusing on customer experience, using cloud services to improve processes, and establishing metrics to measure DevOps success.
Recommended
More Related Content
What's hot
What's hot (20)
Similar to DevOps and the Enterprise Cloud
Similar to DevOps and the Enterprise Cloud (20)
More from Ashish Patel
More from Ashish Patel (16)
Recently uploaded
Recently uploaded (20)
DevOps and the Enterprise Cloud
- 1. © 2015 TeraGo Networks Inc. DevOps and the Enterprise Cloud Ashish Patel Director, Cloud Services @pateltech
- 2. © 2015 TeraGo Networks Inc.2 Speaker Ashish Patel Director of Cloud Services TeraGo @pateltech
- 3. © 2015 TeraGo Networks Inc.3
- 4. © 2015 TeraGo Networks Inc.4 Why?
- 5. © 2015 TeraGo Networks Inc.5 Today’s journey through DevOps… 5 common pitfalls of DevOps Challenges in the Enterprise Framework for your organization Using Cloud to accelerate DevOps
- 6. © 2015 TeraGo Networks Inc.6 Problem #1: Terminology that is not well understood – What is DevOps? Continuous Improvement Respond to business changes more rapidly People Process Tools
- 7. © 2015 TeraGo Networks Inc.7 Problem #2: How to balance interests and establish accountability? Deliver new features and bug fixes Productivity is measured on the velocity Improve cross functional collaboration Remove the wall between development and operations! I deliver change! I ensure stability! Ensure operating stability and efficiency Productivity is measured on service levels
- 8. © 2015 TeraGo Networks Inc.8 Problem #3: How to establish a the correct culture? Re-think employee performance measurement Recognize competing interests drive mis-alignment in cross-functional teams
- 9. © 2015 TeraGo Networks Inc.9 Problem #4: How to find a champion to help get buy-in from the business? Middle Management “Permafrost” Goals should be relevant in this team sport. Most IT departments are not a team, but collections and layers of individuals.
- 10. © 2015 TeraGo Networks Inc.10 Problem #5: How to gain business justification and attention for DevOps? Focus on the Experience Economy to drive higher value. Develop new experiences and operate existing ones with finesse.
- 11. © 2015 TeraGo Networks Inc.11 "Mo Money Mo Problems“ Moving to DevOps requires a viable Business Case Culture People ProcessTools Customer Experience PerceptionTolerance Cost Case Revenue Case Establish the correct culture across the team In order to create valuable experiences for customers!
- 12. © 2015 TeraGo Networks Inc.12 Why is DevOps difficult in the Enterprise?
- 13. © 2015 TeraGo Networks Inc.13 Where one starts with DevOps depends on business objectives. Source: Forrester Research Inc. 2014.
- 14. © 2015 TeraGo Networks Inc.14 Target specific pain points to validate DevOps is working for your organization. Insights Observed 1. Do not formulate a roadmap with a number of projects along a timeline to enable DevOps. 2. Pick projects where the business understands that they have to work with IT differently to get what they need. 3. DevOps will be used in pockets and requires time for the mindset of the business to change.
- 15. © 2015 TeraGo Networks Inc.15 Strive for operational excellence through the reduction of risk by using cloud services Focus on standardization and cloud automation to address issues Not enough capacity Time spent waiting Scaling issues with demand Defects take time to reproduce Lack repeatability and speed Assets are locked-in to a vendors platform Poor visibility to collaborate productively • Application releases are delayed or scope is decreased • Applications are released with a greater probability of defects • Production deployments fail • Inconsistent environnements from dev to production • Complex, manual and processes • Integration difficulties without interoperability, reusability, and portability • End users are less satisfied Correct skills to execute and demonstrate culture Validate security and compliance for dev/test using a multi-tenant IaaS Demonstrate continuous integration and deployment Select an Enterprise IaaS provider for production. Ensure open cloud is in providers’ roadmap Standardize and orchestrate from dev to production Standardize and orchestrate images Understand implications of PaaS for your application architecture Consume microservices Implications Step 2 Step 3 Step 4 IssuesCloudPlan Step 1
- 16. © 2015 TeraGo Networks Inc.16 How to establish a the correct culture? Two options 1. Change the existing culture (difficult) 2. Change talent search and hiring criteria (easier)
- 17. © 2015 TeraGo Networks Inc.17 Many tools are available to support DevOps
- 18. © 2015 TeraGo Networks Inc.18 How to measure your success with DevOps Data-Driven DevOps May 2014
- 19. © 2015 TeraGo Networks Inc. Q&A Ashish Patel Director, Cloud Services @pateltech
Editor's Notes
- software defined everything API economy open source microservices cloud
- Different definitions of DevOps as it relates to tools and technology, or people and process Overall goal of DevOps: Continuous Improvement or Respond to business changes more rapidly People A group of individuals who execute Development and Operations activities in unison, rather than in disparate silos. Process Apply agile techniques to operations and getting development and operations to actually work together. Tools Continuous Integration > Continuous Delivery > Continuous Deployment DevOps philosophies and institute continuous delivery capabilities are able to respond to business changes more rapidly and are more profitable than businesses that are hindered in these areas. DevOps typically increases the level of transparency between IT and the business giving them greater input into direction and providing them a wider perspective for how what is below the water line today impacts the very attributes the business cares about. Continuous Integration is the practice of merging development work with a Master/Trunk/Mainline branch constantly so that you can test changes, and test that changes work with other changes. The idea here is to test your code as often as possible to catch issues early. Most of the work is done by automated tests, and this technique requires a unit test framework. Typically there is a build server performing these tests, so developers can continue working while tests are being performed. Continuous Delivery is the continual delivery of code to an environment once the developer feels the code is ready to ship. This could be UAT or Staging or could be Production. But the idea is you are delivering code to a user base, whether it be QA or customers for continual review and inspection. This is similar to Continuous Integration, but it can feed business logic tests. Unit tests cannot catch all business logic, particularly design issues, so this stage or process can be used for these needs. You may also be delivering code for Code Review. Code may be batched for release or not after the UAT or QA is done. The basis of Continuous Delivery is small batches of work continually fed to the next step will be consumed more easily and find more issues early on. This system is easier for the developer because issues are presented to the developer before the task has left their memory. Continuous Deployment is the deployment or release of code to Production as soon as it is ready. There is no large batching in Staging nor long UAT process that is directly before Production. Any testing is done prior to merging to the Mainline branch and is performed on Production-like environments, see Integration blog article for more information. The Production branch is always stable and ready to be deployed by an automated process. The automated process is key because it should be able to be performed by anyone in a matter of minutes (preferably by the press of a button). After a deploy, logs must be inspected to determine if your key metrics are affected, positively or negatively. Some of these metrics may include revenue, user sign-up, response time or traffic, preferably these metrics are graphed for easy consumption. Continuous Deployment requires Continuous Integration and Continuous Delivery - otherwise, you are just cowboy coding and you will get errors in the release. Continuous Deployment relies on small changes which are constantly tested and that are deployed and released to Production immediately upon verification. The ownership of the code from development to release must be controlled by the developer and must be free flowing. The automation of steps allows this process to be implemented and executed without cumbersome workflows.
- Traditionally, the goal of Development is to deliver features and of Operations is to ensure stability of those features. While Development is measured on the velocity of delivery, Operations is measured on service levels. Both of these groups have competing interests as Development can quickly deliver new function claiming they are meeting requirements and customer needs, but Operations often receives the brunt of complaints when stability is compromised – eg. an outage in service Dev - meeting customer needs Ops - receives the brunt of complaints when stability is compromised
- From an organizational view, the performances of these teams are often measured on an individual basis, which results in individuals competing to establish their personal brand equity in the organization. Often this results in individuals making decisions that maximize their own personal success to grow their brand and reputation, rather than in benefit of the joint mission between Development and Operations. Furthermore, both of these groups may report into separate departments (especially in an Enterprise), making the problem only worse as each line of business would have its own and disparate business objectives. Separate departments where each line of business has its own objectives Measured on an individual contributor performance Competition to establish their personal brand equity in the organization Decisions may be made that maximize their own personal success over the joint mission
- Upper management is so focused on growing the business that mention of DevOps is often glazed over because its business value is not well understood or communicated. What is communicated to upper mgmt comes from middle management who were sold on the technology and tools aspects of devops, but failed in translating that to how it helps the business – in terms of acquiring new customers, upselling to the existing customer base, expanding to new markets or geographies, or even improving the bottom line. As a result, middle management doesn’t champion the idea of DevOps much further because they don’t want to “that person” who isn’t aligned with upper management or on the next resource action list. This has been called the “middle management permafost” (insert reference). The developers understand it and the senior managers understand it - largely because they have read The Phoenix Project - but the middle managers see it and think, "I don't know how I am going to add value to it so I am going to fight it because if I don't I think I am going to wind up on the street". One way to do it is to understand that agile is a team sport. Most IT departments are not a team, they are collections of individuals – DevOps is the same. Example: reducing batch sizes reduces operational risk
- How does DevOps support the business – its not about technology or tools driving DevOps A business thrives by serving the customer. In order to serve customers, a business must create a compelling experience. Once a customer is acquired, the business must turn this customer into a high-value one. Customers tend to exhibit loyalty to a brand if their experience with the business and its’ products are enhanced. Otherwise, the business risks losing the customer to competitor. To create a higher value customer new experiences must be developed, and existing experiences must operate with finesse. If those who develop experiences are not aligned with those operating those experiences, a customers experience is in danger.
- Product / Tool features: Standardization, Automation, Modularity, Interoperability (reduces long-term investment) – open technologies
- Difficult to create a business case to justify augmenting with DevOps on Systems of Records (70% of IT budgets are spent here maintaining these systems) Enterprises have mission critical systems that are Systems of Records, whereas, startups don’t have a legacy environments making it easier to build greenfield environments using DevOps from day one Enterprises are formed with teams with functional (“silo”) responsibility, and not a singular focus (eg. Netflix) Change control & transparency of that overall process and its owners Many enterprises are mult-product/service firm, which constantly aim for business justification to allocate the correct investments in the correct lines of business to maximize return Comply with existing corporate standards and security policies – eg change management systems, version control etc. Do not over confuse DevOps with an IT transformation where you might change policies and systems. – this also helps to preserve existing interfaces between silos Support with stability of a Partner network
- Business value – reach new markets or customers with new services, or upsell existing customers with new experiences New delivery models (API services, mobile apps, continuous delivery) New delivery platforms (cloud, and continuous integration) New business models (open source, recurring subscription, on-demand)
- Do not formulate a roadmap with a number of projects along a timeline to enable DevOps. Pick projects where the business understands that they have to work with IT differently to get what they need. DevOps will be used in pockets and requires time for the mindset of the business to change.
- Step 0 Ensure you have the correct skills in place not only to execute but also to demonstrate the desired team culture. Step 1 Start with a multi-tenant IaaS to validate a project passes necessary compliance and security aspects for dev/test environments. Prepare standardized images for middleware and orchestrate provisioning in collaboration with operations. Implement Continuous Testing and Continuous Deployment to track quality to business expectations. Step 2 Select an IaaS service provider with proven Enterprise expertise to run workloads in production. Ensure that OpenStack or other open technologies are part of the providers’ roadmap or portfolio to enable portability and reusability. Ensure you have a design for standardizing databases, middleware, application servers, and deployment architecture across the dev/test and production environments. Step 3 Understand how PaaS helps accelerate development and scaling of your applications architecture. Look to consuming microservices to create integrated customer experiences, technology is bite size consumable, and independent from disparate sources.
- From an organizational view, the performances of these teams are often measured on an individual basis, which results in individuals competing to establish their personal brand equity in the organization. Often this results in individuals making decisions that maximize their own personal success to grow their brand and reputation, rather than in benefit of the joint mission between Development and Operations. Furthermore, both of these groups may report into separate departments (especially in an Enterprise), making the problem only worse as each line of business would have its own and disparate business objectives.