DevOps and the Enterprise Cloud

Editor's Notes

• #5: software defined everythingAPI economyopen sourcemicroservicescloud
• #7: 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.
• #8: 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
• #9: 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
• #10: 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
• #11: 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.
• #12: Product / Tool features: Standardization, Automation, Modularity, Interoperability (reduces long-term investment) – open technologies
• #13: 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
• #14: 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)
• #15: 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.
• #16: 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.
• #17: 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.