back to xpand blog

X:ED And AAN: The DevOps Q & A Wrap Up!

27th Aug 2015


With another successful series of meet- ups under our belts, X:ED and the Australasian Architecture Network are bringing you the wrap up of all the highlights from both the Sydney and Melbourne DevOps events, with our Q & A on the evening’s topics of conversation, courtesy of some of our top notch, industry- expert panellists.

Various snaps from the Sydsney and cross both the Sydney and Melbourne meet-ups we were extremely fortunate to have all our DevOps questions answered by our incredible panel comprised of;

  • Yann Krätzschmann, Cloud Solutions Practice Lead at Bulletproof


  • Andrew Khoury, who is a Senior DevOps Engineer at Odecee


  • Shiva Narayanaswamy, a Solution Architect at AWS;


  • Phil Jay, Senior DevOps Lead at Odecee;


  • Peter Gatt, Managing Director of Vibrato;


  • Andrew Hatch, Head of DevOps at Seek;


And for those that were unable to attend our meet-ups- Phil Jay, Peter Gatt and Andrew Hatch have kindly put pen to paper and answered all the questions you missed and with decades of DevOps experience between them, you can be assured that you’re in for a quality read.

Can you tell us about your intro and your DevOps journey?

PJ: Working for a small firm where I did everything that was not pure-development: support, integration, release engineering, deployments, config management...  Was invited to the DevOps Melbourne meetup in 2011 - I've been thinking about DevOps ever since.

PG: I initially started with devops at a large search engine and marketing company based in Melbourne.  At the time, we had a lot of divide between developers and operations, and we saw lots of things coming to the infrastructure team that just wasn't validated, but was expected to just Go Live.  I hired James Martelletti ( our now CTO of Vibrato and Hava ) as an infra guy in the development team.  Since then, we've been doing devops.

What is DevOps?

PJ: Key things for me are;

  • alignment of goals (usually, via KPI's),
  • "friendliness" and inclusiveness of processes, i.e. deployments happen at reasonable hours so that devs and ops can do them together; ops have a transparent & easy way for devs to get code released; devs have a transparent & easy way for ops to know that the software is tested and good to go.
  • everyone at least considers the system-as-a-whole view from time to time.  DevOps does not mean doing everything, but it does mean considering everything.

PG: Such a loaded question.  So many answers.  Ultimately, we see devops as being a cultural change in a company looking to unify there dev and infra teams into an engineering team, so as to enable speed and agility of change in the company

AH: Without looking up the definition on Wikipedia, DevOps can be thought of in simple terms as bringing the Dev and Ops component of software delivery together such that they are in a constant cycle, referring between each other to deliver code faster and more reliably.

Firstly it is about moving the Ops component of software delivery up the stack to ensure that the required Ops work is covered off during design and delivery to ensure that what is going to be built can be deployed, monitored and supported simply and efficiently. Rather than the siloed, over-the-fence nature in which Ops traditionally has gotten code from developers in the past

Secondly it is about taking the best parts of development around version control and automation and bringing that into the Ops programme of work to ensure that infrastructure, monitoring, and deployments are managed within source control and are built in accordance with good agile development practices.

DevOps has been around awhile. Why what is all the fuss about now?

PJ: Studies such as "The State of DevOps" show that businesses can actually benefit by adopting some "DevOps Practises".  I think this is gaining attention.

PG: It's really about the fact that technology has allowed for the adoption of devops to mature at a much faster rate.  Services like AWS have given developers the ability to get quick insite into how infrastructure works.  As such, it's really meant that if you want to protect against shadow ops, or bypassing of your ITIL and Change processes, you need to start developing a devops culture in a hurry.  

AH: Tools have really matured in recent years that has made closer integration possible. Also numerous studies that show companies who do take on these initiatives deliver faster and with better quality thus getting an edge on their competitors

What are the most common challenges for facing DevOps teams today?

PJ: If you're in a "DevOps team" - chances are all you're doing is Build and Dev tooling.  It's challenging getting beyond that.

PG: We are seeing that it's hard for infrastructure guys to really start to embrace the development methodologies required for automation and agility in their environments.  We have found it's also hard for developers to not get carried away, and just release something without thinking about security and stability within the environments.  Some teams do it better than others, and some just need education, training and support to learn how to do it right.  

AH: Culture, culture, culture.

Who should be driving the changes needed, business or IT?

PJ: Business.

PG: BOTH.  I think IT needs the support of their business to really start to make change.  Most of the successful stories we see always have executive backing, and the tech teams were encouraged to automate and move to devops as a way to really empower the business.   

AH: Both. All parts have to be on-board otherwise it will not work. In many companies embedded in slow-moving delivery processes and practices based off CMMI, RUP TOGAF (etc…) this will be a massive challenge as the cultural change impact will be large, difficult and will have its fair share of critics

How do you explain DevOps to the wider Business?

PJ: It's the continuous improvement and analysis of the processes for getting code into production smoothly & without incidents.

PG: I would say start at the benefits.  We often point out the biggest pain points in a company, from the IT side of the world and the business side.  It's important to understand why a business may not be operating as efficiently as they can, and then draw on the DevOps practises that are out there to really solve the problem.

AH: Through value. Always through value. The most important of which is value in producing product faster and with greater quality.

Can Development teams ‘be Agile’ without collaboration with IT Operations?

PJ: Yes.  But it's ineffective.  Analyse at a system level.

PG: Not really.  That's a primary driver for devops.  If you aren't moving to infrastructure as code, and ensuring the infrastructure services can be as agile as development, then you're going to continually hit road blocks.  

AH: Yes of course. Arguably they have been for the better part of a decade. Agile improved out-dated waterfall software delivery processes immensely, but it never solved what happens after the code was built and tested and ready to be shipped

How can you become DevOps enabled?

AH: Good question, it really comes down to the company and the appetite for change

PG: Take a step back, and look at your environment and processes as a whole.  You should immediately find places where developers and operations teams working in harmony can help to improve the process.  Whether it be adopting infrastructure as code, CI for infrastructure, or even just a centralised repository of information... there are many standards out there now on how to achieve this.

What advice would you give anyone thinking of or just starting out on their DevOps journey?

PJ: Unless you're in the executive, start small, and start on a pain point: maybe you've got release engineering down pat, but deployments are still manual - start by automating deployments.  Perhaps deployments are automated, but Ops still have to do them at 3 in the morning - move the deployment to 10pm or 7am. Most importantly, start by talking to your colleagues.  Attend their stand-ups.

PG: Start doing something today.  Pick your biggest pain point, pull all of your teams together to discuss it as a single team, and start producing a solution that involves and empowers all teams from the beginning. 

AH: Critically assess your IT business now. Where are the bottlenecks, where are the constraints, how much unplanned work is worn through mistakes, outages and poor planning. Take that information and lay that over DevOps principles and draw out what projects, tools, processes etc.. are needed to get started.  Also read books like The Goal and The Phoenix Project.

What are some indicators that an organisation is ready to take on a DevOps project?

PJ: Just do it.

PG: When the teams are encouraged to be able to work together collaboratively, and engineering staff aren't having solutions thrown at them, but rather are encouraged to provide a solution to a business problem.

AH: Ones that are already showing a lot of adaptability to automation and infra coding plus a real appetite for cultural change is being made known.

What are the best Technologies to look at when implementing DevOps?

PJ: Version control (for everything!) and dashboards.

PG: The Atlassian suite (JIRA+Bitbucket+more), GITHUB, Hashicorp Technologies ( vagrant, packer, terraform, vault, +more ), Chef for dev weighted teams, puppet for the infrastructure weighted teams.  Ansible, sublime, new relic, monit, victorops, slack, hipchat... if you want more, and you want to know where the right place to use these tools lie, please contact Andrew Blades;

AH: Cloud based infrastructure is an obvious one but tools that increase your ability to automate infrastructure provisioning and provide intelligent monitoring are worth a look at. Realistically though, tooling is secondary. DevOps is about process and culture

Should we create a devops team?

PJ: No.  Create a dev-tooling team.  Create a automated-deployment team.

If you're going to create a DevOps team - give it the power to analyse and improve processes related to software production and delivery.

PG: NO...  it's important to not put a divide between your developers and your infrastructure/operational teams.  I have seen devops teams established that work well in an organisation, but normally if they are acting as an innovation tribe, or an enablement group.  

AH: It could be a good idea, especially if you want to raise the profile of these practices within an organisation

How does devops work with ITIL / Change Management?

PJ: They should be able to work in harmony.  Just think about the important pieces of ITIL and change management, and fit the "DevOps Practises" around them.

PG: It makes it stronger!  Those practices were developed to remove risk from your organisation.  By implementing a higher level of communication and collaboration in your development and operational teams, and leaning on automation and technology solutions that support your organisation, you can achieve a much more robust and automated ITIL and Change Management Practise. 

AH: I can’t answer this one with respect to ITIL. In respect to Change management it will make it  a lot more predictable as failure can be better managed and controlled as you can roll forward on failure with a lot more confidence – assuming you have a high level of infrastructure and deployment automation.

Is this the end for infrastructure groups?  What about OpsDev?

PJ: No.  But infrastructure groups should be thinking about how they can interact with the other teams.  Can they stay out of the critical path?

PG: The infrastructure teams, just like the development teams need to evolve.  I foresee a move to a collaborative engineer team, with a mix of highly skilled individuals in their respective field.  A strong OS member, a strong JAVA dev, a strong bamboo member.  Devs can learn a lot from infra, and vice versa... your staff have to be prepared to evolve. 

AH: S*%t no! They’re needed more than ever. But they have to be willing to upskill and change.

Is there a standard way to measure devops capability / maturity in my organisation?

PJ: No.  But the "DevOps Checklist" is a good start:

PG: We currently use the Jez Humble maturity model when looking at continous integration and delivery.  There are some really great civilization technology road map approaches that we're seeing evolve, and we're actually working on our own that we distribute with customers to give them a good view of their current technology capabilities and where it's all going.

AH: There are a few maturity models around. I would measure it by how much unplanned work has risen or fallen, how much faster code can be shipped and how a lessening of the fear of failure leads to more innovation and continuous improvement.

What have been some of the outcomes of devops on organisations?

PJ: More successful deployments.  More deployments.  Less stress.

PG: No dead cats getting thrown over the fence, faster delivery times, more frequent releases into production, fewer bugs going out... ultimately, an evolution of the system as code (inclusive of dev and infra changes)

AH: They have accelerated away from their competition, generally have a more engaged and productive IT department, innovation and new ideas increase as failure is much better contained and controlled leading to more opportunities for experimentation.

Tooling sprawl... why are there so many things we need to learn about?

PJ: What's new?  This isn't a DevOps problem.  There's always something new to be learned in IT!

PG: We're big believers in the right tool for the right job.  Unfortunately, we do see the sprawl of tooling, where we see customers try to use all of the tools at once, and see which one fits.  It's the wrong approach.  We work with customers to establish the full flow of their continuous integration and delivery through a process ( pseudo coding almost ), and then find the right tool to adhere to the requirements of each step in the process.  Then release that, and if it doesn't work for them in the future, switch the tool out.  

AH: We don’t really, use the best tools for the job, you don’t need to know them all.

Am I going to be automated out of a job?

PJ: Just remember, the computer doesn't know "Why?".  You're the custodian of the business logic & the reasons why you're doing something.

PG: Yes you are... and then you're going to inherit a new job, where you focus on automation improvements, reliability techniques, and other tasks that you can now focus on, rather than trying to build a server manually every day. 

AH: No, you’re going to be automated into a new one

What concerns would your IT security manager have about DevOps?

PJ: None.  But, get involved.

PG: They may think that devops = developer does what they want.  Well, that's relatively true... only, that has to come with a robust environment that has been built to enable the developer to do so securely.  Let them code, but ensure that when they submit their code, it goes through a vast array of security checks.  Then, you don't need to worry about what's being pushed out to production every day. 

What is the future for DevOps?

PJ: Continuous improvement - always.

PG: Engineering teams.  The ability to decouple the monolith.  The evolution of containers.  With AWS at your side, the ability to do away with the server all together (Lambda).  And so much more. If you truly unlock the power of your engineering team as a whole, the business will have the ability to continually move faster, and re-act to competitor advances with ease.    

AH: If the change is contained existing perimeters and boundaries it should not increase much if at all. If the company moves workloads into the cloud then this will be an entire new skillset that will need to be taken on. No-one wants open to the Internet!

A huge thank you goes to Phil, Peter and Andrew for annotating the answers to these questions for us and to all the remaining panellists for their fantastic efforts, as well all of those who were in attendance.

We look forward to seeing you all for our next set of X:ED meet-ups to be held once again in both Sydney and Melbourne this time centred on attracting, attaining and getting the best from your architects.

To attend the next meet-up or if you just want to find out more please click the link!