DevOps Practical steps towards greater business agility AND stable IT operations.

Transcription

1 DevOps Practical steps towards greater business agility AND stable IT operations.

2 White Paper BUSINESS AGILITY VS OPERATIONAL STABILITY In today s world, organisations, and the software teams that deliver their business critical systems, must be able to adapt quickly and respond to change in order to be successful and stay relevant. Equally important is the need to ensure operational systems and the services they provide are stable and available at all times. Can we really achieve both of these aims? There is an obvious conflict. On the one hand we have development teams motivated to deliver new and updated capabilities into Operations as quickly as possible; on the other we have Operations teams motivated by the need to keep operational systems stable by controlling and reducing the amount of change. This struggle between Development and Operations has been around for decades. Historically, organisations have put processes and gates in place to help ensure the changes delivered into Operations have been tested and verified and can be supported by the relevant teams. This can work, up to a point. However, modern businesses demand real agility, not just during design and development but throughout the lifecycle including the release and deployment of changes into the Operational environment and ongoing support. Combined with the need for business critical systems to always be available, a new way of working has to be adopted. Modern businesses demand real agility, not just during design and development but throughout the lifecycle including the release and deployment of changes into the Operational environment and ongoing support As the name suggests, DevOps is an approach that aims to bring together the Development and Operations teams and addresses their conflicting motivations. Through a combination of new ways of working that lead to better communication and collaboration, the DevOps movement has transformed the way organisations run their IT. 2

3 DevOps: practical steps towards greater business agility and stable it operations Probably the best known examples of this are Netflix and Amazon who are deploying changes hundreds of times a day without service interruption. It simply isn t acceptable to wait weeks for a change to be released operationally. We have identified four practical steps that teams can start to adopt today which will make a huge impact on your ability to provide responsive AND stable IT Operations Examples such as these highlight the power of adopting DevOps principles and practices. However, getting to a position where multiple deployments a day is considered the norm requires significant change in terms of new technology and techniques. The most significant aspect of a move to DevOps is the cultural mindset shift required across the organisation, from the business, development and operational support teams, right up to executive sponsors. Depending on the nature of the organisation and the environment in which it operates, this is likely to present a huge business change challenge and will take time to embed. But don t be put off. Just like eating the proverbial elephant, DevOps practices can be adopted one bite at a time. Key to embedding any large scale cultural change is to start with relatively small, bite-sized changes and build up trust with those people who might be afraid of what such a change may mean for them. In most organisations today, agile teams are empowered to adopt new technology and ways of working. With this in mind, we have identified four practical steps that teams can start to adopt today which will make a huge impact on your ability to provide responsive AND stable IT Operations and build up the trust required to embed a highly effective DevOps culture. 3

4 White Paper STEP 1 ORGANISE YOUR TEAMS FOR DEVOPS The first of these steps is to organise teams to break down the barriers between the Development and Operational Support teams. Bringing together the Development and Operations teams and tasking them from a single backlog has been proven to drive the behaviours that will lead to a more supportable, sustainable and higher quality product or serviceb. By combining development and support activities into a single team, delivery Bplanning is made more effective. The software under development will have welldefined, operationally driven content that is delivered at the right time for the business. Key to the success of this approach is a strong Product Owner who has awareness of both the functional needs of the system and its operational requirements. This enables rapid prioritisation between the sometimes competing development and support needs to ensure the team is working on the right things at the right time. Key to the success of this approach is a strong Product Owner who has awareness of both the functional needs of the system and its operational requirements Taking this a step further, in many successful DevOps teams, Developers own the code they write throughout the delivery lifecycle, including when it runs in the operational environment. This ensures supportability features and quality measures are baked into the application from the very start. Successful software delivery is not just about functional quality but also operational quality. A project team is typically measured on quality of the features they deliver (which are often tested to a very high level of quality) but in more traditional team structures operational quality and supportability is not their responsibility and as such is given significantly less attention. In a non DevOps world, Developers do not have to work with/debug/fix code in the same circumstances as Operational support teams. In development there are typically reduced security restrictions, lower volumes and there are unlikely to be irate customers breathing down your neck whilst you try to restore service! In development, servers can be restarted with no disruption 4

5 DevOps: practical steps towards greater business agility and stable it operations for example, all of which makes for a better environment in which to work with code. To work quickly and precisely in Operational situations, people need to have the right tools and information available and these need to have been designed and built into the system during development. By creating ownership such that developers are on the hook to fix issues relating to their code in the operational environment, the overriding motivation for a development team will be to focus on supportability, maintainability and automation. Bringing Developers and Operational Support teams together into a single team ensures that knowledge is retained in the team and not diluted by handover to a separate organisation A further advantage of organising people into DevOps teams is to remove handoffs of work between teams. Handing work off between one team and another leads to dilution of knowledge and increased lead times. Whether this is passing a support ticket through the different support teams, or the handover of a system from development into support. Bringing Developers and Operational Support teams together into a single team ensures that knowledge is retained in the team and not diluted by handover to a separate organisation. 5

6 White Paper STEP 2 TREAT INFRASTRUCTURE AS CODE... but it worked when we ran this scenario as part of UAT in our Reference environment!...yes, but the Operational environment isn t configured in quite the same way... Sound familiar? All too often issues are found as a system in development is deployed into a new environment as it moves through the delivery lifecycle and eventually into Operational usage. All teams use source control to ensure that the right version of code can be deployed and run in a consistent and repeatable manner, so why is this such a common occurrence? The answer is that code is only one aspect of the system. The infrastructure it runs on and the related configuration has an equal bearing on how a system functions. Yet, in a lot of cases the configuration of infrastructure and middleware differs between environments, leading to software running and behaving differently from one environment to the next. Thankfully, with virtualisation, utility computing and cloud based server provisioning, the solution to this problem is relatively simple; treat infrastructure as code and get it under source control. Automated Infrastructure provisioning tools enable teams to hold environment configuration in source control and to automate the provisioning of environments and the deployment of the software (including related middleware) in a consistent and repeatable way. This approach enables environments to be provisioned at the push of a button This approach enables environments to be provisioned at the push of a button, whether they be development or operational environments. Environmental issues are then identified and resolved much earlier in the delivery lifecycle. This method also saves time and effort when onboarding new members of the team, enabling them to have a working environment in minutes rather than days. This saves time and money and sees developers adding value sooner. 6

7 DevOps: practical steps towards greater business agility and stable it operations In some organisations constraints such as security can prevent base servers from being automatically provisioned using these infrastructure provisioning tools, however it is still possible to benefit significantly from the automation and configuration control of aspects such as: Creating middleware execution environments Creating file mounts Installing RPMs Installing and updating the application Managing properties files Altering logging levels Application status checks Manual installs, with the inevitable element of human-error, can be a thing of the past Manual installs, with the inevitable element of human-error, can be a thing of the past as these tools also make installation and deployment of upgrades over large scale multi-server environments a straight-forward and repeatable process. 7

8 White Paper STEP 3 DO CONTINUOUS INTEGRATION PROPERLY AND THEN TAKE IT TO THE NEXT LEVEL Continuous Integration (CI), the practice whereby a system or application is automatically built and tested upon every committed change to the code base, is in widespread use and considered standard practice for modern day development teams. Key to a successful CI regime, is not so much the tools and software used, but the working practices around them. That is to say, the action a team takes following a failed CI test is more important than the tool used to automate the build and run the tests. Key to a successful CI regime, is not so much the tools and software used, but the working practices around them Although people might not like to admit this, in our experience, it is the working practices around CI that often get overlooked. If phrases like if we stopped development to fix issues with the CI build every morning we d never complete our stories or we don t need to fix these issues now, we ll pick them up during integration testing sound familiar to you, then CI is not being done properly and the benefits of such an approach are not being realised. The fundamental point of CI is to frequently integrate together code and components of a system in order to identify AND resolve integration issues early in the lifecycle. Resolving integration issues as soon as they are identified is not only more efficient but it also builds confidence within the team and with wider stakeholders. Building confidence like this helps to address the cultural challenges associated with moving to an approach of Continuous Delivery and the ultimate aim for business agility through multiple operational releases a day. Once your team is doing CI properly you can then look to take things to the next level by continuously delivering a working system, not just at the code level but also with infrastructure and middleware as well. By combining your CI approach with automated provisioning tools such as those referred to in Step 2, you can move to a Continuous Delivery model that helps identify issues at all points in the technology stack. This significantly de-risks the release of a system through environments and into Operations, shortening lead times and improving responsiveness without negatively impacting stability. 8

9 DevOps: practical steps towards greater business agility and stable it operations STEP 4 ADOPT CANARY BUILDS Increasingly today, systems rely on external components and services in order to function. Decoupling interdependent systems through common, open interfaces attempts to address issues around interoperability and, to a lesser extent, backwards compatibility, but this can only go so far. At some point those interfaces, and/or the functionality behind them, will change and your system or application will need to change with it, in a lot of cases for no additional business benefit just continuity of service. In the interdependent world of service and cloud based architectures it is crucial that your system can quickly move to new versions of these dependent services and components. This not only ensures your customers benefit from new features but it also prevents your system from falling behind in terms of security patches and the like. In the interdependent world of service and cloud based architectures it is crucial that your system can quickly move to new versions of dependent services and components In our experience, upgrades of this kind are hard to get prioritised. Typically, the business wants more new features and the project funding the change wants to move risky upgrade work off of their plans and out to Business as Usual. When these upgrades eventually do get scoped they have become large, risky changes, often jumping multiple versions and with significant testing and verification involved. There is a better way, and as an extension of your Continuous Integration approach, it is relatively simple to adopt; Canary Builds. Canary Builds are named after the analogous yellow bird that miners used to take down the pit to give them early warning of a dangerous build-up of poisonous gas. If the Canary dies, it s time to evacuate the pit, pronto. So it goes with Canary Builds, you set up a separate automated build that takes in the latest version of all your external components and services and every night you run your automated regression pack against it. If the Canary Build dies you know you have work to do to take the latest version and can plan that in asap. If the tests show a clean bill of health, you can take on the latest version with confidence and include it in your next release. 9

10 White Paper SUMMARY These four practical steps: 1. Organise your team for DevOps; 2. Treat Infrastructure as Code; 3. Do Continuous Integration properly; and 4. Adopt canary builds, are relatively simple ways to move your team towards the nirvana of the DevOps world where multiple releases per day is the norm and development and operational support teams work hand-in-glove to deliver a world class service to their customers. If you would like to find out more about our experience of implementing the four steps or how Deep Sky Blue can help your organisation benefit from adopting these and other practices then we would be delighted to hear from you: devops@deepskyblue.com 10

11

12 White Paper GET IN TOUCH If you would like to know more about Deep Sky Blue and how we can help your business then we would love to hear from you: Tel: Web: 12