WHAT DOES DevOps MEAN FOR YOU?

WHAT DOES DevOps MEAN FOR YOU?

OUR SPEAKERS DEREK WALSH SIMON STEFANOFF GLENN GORE Manager, Application Development Melbourne IT Head of Technology Reactive Senior Manager, Technology Solutions Amazon Web Services

QUESTION What are the cultural challenges that an organisation will face with moving to a DevOps practice?

WHAT ARE THE CULTURAL CHALLENGES THAT AN ORGANISATION WILL FACE WITH MOVING TO A DEVOPS PRACTICE? C Culture A Automation M Measurement S Sharing For many organisations, the adoption of DevOps involves changes to entrenched roles and processes. Making these changes and adopting a collaborative multi-department approach to delivery is required and this is the key challenge. A lot of organisations and specific business units or roles are resistant to change, with some areas of the business even being incapable of change; this requires extra assistance. An organisation s culture must change to encompass DevOps. Cloud enablement, automation etc. are all key to DevOps but at its heart is a cultural concern, and a management concern. Culture is where the challenge is within IT teams themselves. Change management, release management a lot of roles get changed which can have an impact on the overall culture, however the biggest change happens outside of the tech team. Management layers and business owners can often be a catch 22 they can be really optimistic about wanting fast change from moving towards DevOps, but at the same time fearful about myths around loss of control, quality concerns etc. Those changes can sometimes occur without their direct input. TOP TIP Even before you address culture look at purpose. What is the purpose that you re trying to achieve by working towards a DevOps framework? Define this you will find that this approach drives cultural change nicely.

QUESTION Do you believe that DevOps reduces the inherent bias of developers to program for success only, and not failure - by providing an Ops perspective?

DO YOU BELIEVE THAT DEVOPS REDUCES THE INHERENT BIAS OF DEVELOPERS TO PROGRAM FOR SUCCESS ONLY, AND NOT FAILURE - BY PROVIDING AN OPS PERSPECTIVE? Does DevOps change the focus of developers? Regardless of whether DevOps practices are utilised or not, developers need total awareness of the target infrastructure and environment. Appropriate use cases and requirements need to be baked into the development lifecycle to ensure smooth transition to operational state. Systemic issue if operational parameters don t form part of the requirements the solution will not be successful. DevOps makes developers directly accountable. It removes a place to hide where development isn t operationally aware when previously developers might have thrown it over the fence to the operations team. If it is failing in production developers are having to stop other work they re doing and come back to fix the issues. BENEFITS 1 2 Fixing issues great incentive to fix root cause properly. SCENARIO A The application has broken down over the weekend it s now Monday you re trying to figure out what went wrong by which point it has likely affected your customers and you have no solid insights. SCENARIO B You gain visibility into the platform when it s not working this drives better awareness around what metrics you should be tracking that will allow you to proactively fix the system before it has an issue affecting customers.

QUESTION With DevOps philosophy, how does the idea of separation of concern fit in?

WITH DEVOPS PHILOSOPHY, HOW DOES THE IDEA OF SEPARATION OF CONCERN FIT IN? Separation of concern (SOC) is a traditional IT concept each team is doing the single task it s required to do. This is important for accountability and the way that traditional organisations are run (especially in IT departments). However, in many ways that is what needs to change! Concerns need to be melded together to increase efficiency of each discipline. Once you begin to involve developers in what happens after code delivery, and involve operations in what happens before code delivery, everyone takes more responsibility. DevOps should result in smaller, more manageable software releases which will benefit both disciplines. TOP TIPS Sharing is an important part of DevOps Share responsibility of software delivery. Acknowledge the impact of the development team on the operations team and work together whenever possible this is hugely beneficial. Increase communication and cultural shift This is vitally important. Bring both teams together, both are affected by; and are playing a part in the outcome. Traditional SOC is not needed outside of any requirements for governance/auditing Everything should be everybody s responsibility. This is really where the benefits of DevOps lies.

QUESTION Breaking down silos between operations and developers: how do you stop silos from being built around applications?

BREAKING DOWN SILOS BETWEEN OPERATIONS AND DEVELOPERS: HOW DO YOU STOP SILOS FROM BEING BUILT AROUND APPLICATIONS? Silos aren t necessary a bad thing (sometimes). There is a fine line between loosely coupled teams which are autonomous on their own (within AWS these are called single threaded teams ) vs complete autonomy where there is no coherence of what is happening across the teams. The grey area is where you draw the line between the two and this is up to the individual organisation. When you create silos and get it on the wrong side of the boundary you lose sharing of best practices and sharing of mistakes, which is important. COMMON PRACTISES WITH A SUCCESSFUL DEVOPS MODEL Peer reviews: one team has another team review their requirements at the start of a project. Code reviews between teams. Architecture forums anyone can come in and talk about the latest technology changes, architectural approaches to things etc. Activities which help to break down barriers while still allowing for a good sense of autonomy for you to move quickly. These techniques foster collaboration, communication, best practise sharing and most importantly communication! TOP TIPS Involve more than just the development team when you re doing development. Include the operations team from the start so that both teams understand their part in it. You need both operations and development disciplines working together to create the best product a team approach. When you start talking about solutions architecture make sure operations is involved. When you re using cloud hosting, you re in an environment with scaling and other features that you don t have in a traditional server environment. The operations team needs to be there to ensure it s being managed in an application that can be scaled out across the cloud, i.e. the application is stateless, all the caching is set up, the DNS is working (dynamic DNS) etc. Operations is really good at this they can add a lot of value into the development team.

QUESTION How does the DevOps model resolve tension between diverse functional goals. i.e. Ops - increase operational efficiency and reduce long term running costs vs Devs - deliver new features and capability while minimising project delivery costs and times?

HOW DOES THE DEVOPS MODEL RESOLVE TENSION BETWEEN DIVERSE FUNCTIONAL GOALS? Developers wants to change and release operations are charged with maintaining stability and consistency. The DevOps approach allows both of the above to happen using continuous delivery to make the release process more efficient and controlled. This saves money and reduces delivery costs and time. Start with a basic continuous integration/deployment process, then build up the rest of the DevOps around that. Developers are becoming more aware through communication with operations; aware of the cloud environment and things they need to factor in the transient nature of the cloud. If developers build in this way with these concerns at the front of their mind they will help the operations team in reducing running costs by delivering an application which can scale up and down in the cloud as required. Everyone takes on a shared responsibility this may not sound tangible but it is highly valuable. Changing times Operations used to be all about trying to attain operational availability at the cost of making changes to a platform and reducing costs. DevOps drives a culture change where you become more aware of why you re doing it because you want to increase the rate of innovation within the organisation to better serve your customers. Line up your KPIs, metrics, goals and start measuring. IT becomes valuable again instead of being seen as a blocker, or not adding value. There has been a perception that IT lags within a business but now we are seeing IT leading (potentially) with these techniques.

QUESTION Can DevOps work with applications and infrastructure built on a traditional model? In other words, how can DevOps be used to manage application life cycles for those applications which have never seen DevOps in their lives?

CAN DEVOPS WORK WITH APPLICATIONS AND INFRASTRUCTURE BUILT ON A TRADITIONAL MODEL? The benefits of DevOps are enabled by things we understand as per the accepted definition automation, cloud enablement etc. but there are a lot of benefits that can be retro fitted onto an application. So the question really is How can you bring DevOps to an application that already exists if the app wasn t made for it, or built with that in mind? There are a number of things to bring it up to start using DevOps practises continuous delivery can usually be retrofitted to some degree, and elements of configuration management can be included. DevOps is a great thing for management it starts showing how IT teams can bring in some value or reduce costs rather than being just a methodology. The application may not have used these techniques up until now, but there are benefits we can use from this point onwards dev and ops working together (they may not have spoken together about the application). It will take time for the elements to get aligned, but if you take one aspect and build capability - over time you can gain benefits.

QUESTION How do you do this when you have an external app development team and Ops is outsourced to a different 3rd party? Does it only work in an in-house scenario?

HOW DO YOU DO THIS WHEN YOU HAVE AN EXTERNAL APP DEVELOPMENT TEAM AND OPS IS OUTSOURCED TO A DIFFERENT 3RD PARTY? DOES IT ONLY WORK IN AN IN-HOUSE SCENARIO? It is more of a challenge to do it in this context the solution is getting the development team and operations team regularly talking, doing peer reviews, joint architecture work with the customer in the middle setting the right expectations. You need to think about things like contracts and legal terms around contracts when you try to get your third parties to think and operate like a DevOps framework where it s fast moving, things can change a lot. DevOps promotes an element of experimentation, then when you try to wrap a legal contract around it which is watertight, there is a big mismatch. From a vendor-relationship aspect, there is a bigger issue caused on the contract side, than the DevOps approach itself. How do you contractually manage a relationship where you want two vendors working together more closely in an environment where there is an ability for them to try different things and get closer to the goal by testing and trial & error? You want the development and testing to occur on a daily basis without failure modes causing disruptions to your customers. Contract agreements, SLAs etc. can sometimes work against the ability to change. Whenever third parties are involved you have to change the way you collaborate. You need to factor about 30% overhead when working with offshore or outsourced teams just in communication and collaboration. Both teams should share a common goal of breaking down barriers. There is no reason why you can t see some DevOps benefits, but its probably not as efficient as if you were running it completely in house.

QUESTION Is it a good idea deploying a developer as part of the operations team? Does DevOps mean developers need to gain skills in the operations area?

IS IT A GOOD IDEA DEPLOYING A DEVELOPER AS PART OF THE OPERATIONS TEAM? DOES DEVOPS MEAN DEVELOPERS NEED TO GAIN SKILLS IN THE OPERATIONS AREA? At Melbourne IT we have brought operational people into the development team during the development process so that when applications go into production we are ensuring an abundance of skills and knowledge and everyone works very closely together. IS IT A GOOD IDEA EMPLOYING A DEVELOPER AS PART OF AN OPERATIONS TEAM AND VICE VERSA? Developer inside the Operations team? Inside Reactive we gained a head-start on DevOps because one of our developers has been with the company for 15 years and was more interested in the infrastructure side; so over time he moved into the operations team. You could say we almost planted a developer into the operations team. This gives us a central point to keep momentum going with our DevOps journey someone who instantly creates empathy between the two teams. Someone who knows what is happening with the applications as they are being developed and what the impacts will be on the operations side. We have seen huge benefits through this. A great way to kick start process is staff with skills and understanding in both areas. With this approach you have everything to gain and nothing to lose developers who understand what makes operations good, means that they can take that into account when designing software. Operations inside the Development team? When you have operations staff in the development team there is an awareness around complexities and flexibility that can be required to make minor changes - as well as early stages when doing things like requirements gathering and feedback. Having an operations person involved can put suggestions at the front around architectural design, metrics, what happens in failure scenarios etc. This is worth gold! Don t tack these considerations on the end once you hand the software over to the operations team; that is the backwards way to do it. Everyone thinks it s a good idea to have development involved in operations and vice versa. Most organisations run in a way where there is a lack of resource, so this can be seen as taking someone away from their day job which can be a challenge. TOP TIPS Make the investment in a multi-skilled team early on get your purpose and goals established and this will show why it is a good investment. This approach is a brave thing to do and takes brave management. Taking someone from where they re on billable work etc. which is seen as a much more tangible benefit, can be perceived as a major risk. However, it takes someone with vision to see that this is going to improve business processes. A lot of enterprises are finding it hard to implement DevOps for the above reasons but the ones who do, are seeing such an advantage and will undoubtedly disrupt the ones who don t. This approach = competitive advantage.

QUESTION Why should I use DevOps instead of just managing AWS resources manually?

WHY SHOULD I USE DEVOPS INSTEAD OF JUST MANAGING AWS RESOURCES MANUALLY? DevOps is so much more than simply infrastructure and API management it is a complete framework and touches on everything from culture and attitude to managing IT resources and how you develop software and make small incremental changes continuously, up to continuous integration and deployment. There are so many things that DevOps represents and a small component of that is the platform that you deploy the code to that which is providing the horsepower. AWS provides a very small component compute, network, application services and deployment methodologies etc but DevOps wraps all of those together into a practice. If you try to use AWS manually you will still see benefits but you won t have shifted past the methodology of managing IT in the same way you run it today a siloed approach based on technologies network team, O/S team, applications team etc. all managing their one piece of the pie. BEST PRACTICE We (AWS) encourage customers to start using CloudFormation which is template driven deployments. If you start using cloud in this way you are already a long way down the path of having a systematic approach to code deployment and can start doing A/B testing etc. which is much easier compared to doing this manually. Move past this and use high level functions that allow you to have a systematic, predictable approach to deploying your applications. Use third party tools also, which allow you to test changes as you make them etc. or even move higher up the stack and use PaaS. Free yourself up for writing and developing the function that will differentiate you in the marketplace.

QUESTION How does commercial off-the-shelf (COTS) fit with DevOps?

HOW DOES COMMERCIAL OFF-THE-SHELF (COTS) FIT WITH DEVOPS? COTS = commercial off-the-shelf, An adjective that describes software or hardware products that are ready-made and available for sale to the general public. COTS products are designed to be implemented easily into existing systems without the need for customisation. When it comes to big applications, i.e. typically the ones that haven t changed in years and are possibly resistant to change DevOps can help. The latter are probably the applications that also have large development timeframes and large deployment lifecycles and therefore take a long time to see if something worked or not. DevOps gives everyone an understanding and empathy of what is going to happen at every stage of the project, not just in debut once it s released. DevOps also provides techniques and a framework that powers an automated process. It allows you to cut down deployment lifecycles and do your automated testing earlier and more cheaply. A lot of developers of off-the-shelf software packages are embracing this themselves either by moving to the cloud and embracing cloud based deployment for their applications (common with most of the ERP suites out there) but even smaller vendors providing the platform DevOps plays a part in that.

QUESTION How do you actually start using DevOps toolsets etc?

HOW DO YOU ACTUALLY START USING DEVOPS TOOLSETS ETC? With continuous integration/continuous deployment (CI/CD) tools are there any in particular that have been seen to be successful? THERE ARE A FEW OUT THERE WHICH PROVIDE A REALLY EASY PATH INTO IT: Jenkins is a simple piece of software; a continuous integration server. Once you re familiar with xml build scripts etc. you can really start to leverage that for bigger things as you go. As an intro, Jenkins (for example) is perfect if you re in an organisation that uses Team Foundation Server or one of the more enterprise level application lifecycle management systems. Once you get a build script working on a simple CI server it is usually pretty transferable into other systems. Key component to any CI/CD the build script. This powers the process and determines what it does. You can get started in a simple way automate your build process, does it pass or fail? Start to get the feel for what you can automate in your organisation. Is there good support on how to use these tools successfully? Continuous delivery started in the late 2000 s as a concept which was really birth of DevOps. It enabled and empowered the movement and there is a lot written about that i.e. many startups blog about their experiences, continuous deployment practises etc. Looking at the platform (e.g. AWS) AWS has lots of tools that can assist right out the box DevOps is one of the most discussed topics in enterprises on the web Google it! There is no one tool for DevOps software packages do a lot out-of-the-box, but there is a lot of customisation required to get them working. TOP TIPS - KEY AREAS OF CONSIDERATION First thing to solve how do I create the environments themselves? AWS CloudFormation template will provision the exact same cloud environment repeatedly. Elastic Beanstalk is more of a PaaS. Testing layer how do I know if what I ve deployed is going to work? Software (Jenkins, TeamCity etc) gives you systematic approach, scorecards and reporting see if it s working the way it should do. Tool chain itself orchestration of all the pieces working together. Create the environment, test to see if it is deployed and working, promote it to production. You want all interfaces to feed back into the development environment, so that at the click of button you don t have to worry about the mechanisms behind the scenes.

BROUGHT TO YOU BY MELBOURNEITENTERPRISE.COM.AU AWS.AMAZON.COM REACTIVE.COM CORPORATE.SALES@MELBOURNEIT.COM.AU For a complimentary AWS assessment visit MELBOURNEITENTERPRISE.COM.AU/AMAZON-WEB-SERVICES/