WHAT DOES DevOps
MEAN FOR YOU?
WHAT DOES
DevOps
OUR SPEAKERS
Head of Technology
Reactive
SIMON STEFANOFF
Senior Manager,
Technology Solutions
Amazon Web Services
Manager, Application
Development
Melbourne IT
GLENN GORE
DEREK WALSH
QUESTION
What are the cultural challenges that an
organisation will face with moving to a DevOps
practice?
Sharing
Measurement
Automation
Culture
C
A
M
S
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.
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.
TOP TIP
WHAT ARE THE CULTURAL CHALLENGES THAT AN ORGANISATION WILL FACE
WITH MOVING TO A DEVOPS PRACTICE?
QUESTION
Do you believe that DevOps reduces the inherent
bias of developers to program for success only,
and not failure - by providing an Ops
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?
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.
Does DevOps change the focus of developers?
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.
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.
1 2
Fixing issues – great incentive to fix root cause properly.
SCENARIO A
SCENARIO B
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
Increase communication
and cultural shift
Traditional SOC is not
needed outside of any
requirements for
governance/auditing
Sharing is an important
part of DevOps
This is vitally important. Bring both teams together, both are affected by; and are playing a
part in the outcome. Everything should be everybody’s responsibility. This is really where the benefits of DevOps lies.
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.
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
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.
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
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.
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
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.
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?
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?
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.
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.
Operations inside the Development team? Developer inside the Operations team?
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.
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.
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?
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.
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.
COTS = commercial off-the-shelf,
HOW DOES COMMERCIAL OFF-THE-SHELF (COTS) FIT WITH DEVOPS?
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?
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.
Software (Jenkins, TeamCity etc) gives you systematic approach, scorecards and reporting – see if it’s working the way it should do.
