Into the Deep End

DevOps at Domain

Leading up to my last day at Domain, I realised that I never really reflected and thought about my experience over the last year as a whole. So I thought what better time to do so than right now —so here goes nothing, my takeaways from a year of DevOps at Domain.

This was my second gig out of university and coming from a large financial enterprise the first thing I experienced was definitely culture shock. I had come from a place of change requests, executive approvals, security matrices and the list goes on (I’m sure many of you have experienced) and on my first day I was already touching production code. My mind was blown to say the least.

Instead of going through change requests and doing releases outside of working hours, we made sure we could rollback every change easily and quickly.

Instead of getting approval from your boss’s boss, you got consensus from your peers.

Instead of delegating responsibilities to other teams, we had access to everything and were responsible for the changes we made.

My on-boarding experience was very much learning on the job, essentially “take a look at the tasks that are coming in and choose what you think you could learn and do”, but with the caveat that I was surrounded by incredibly talented and smart people who I could ask anything. This worked unbelievably well, I was learning at such a fast pace and was up to scratch and confident in no time; and as I saw new people coming into the team going through the same experience, I summed it up as this:

Rather than placing trivial controls around your employees, hire talented people and trust them to do their job.

It was so refreshing, and one of the things I enjoyed most about Domain.

Depending on the size of the organisation, there are many different ways DevOps can be introduced. At Domain we are organised as a centralised resource for development teams to engage with. To me, this is sort of the “easy way out” as it’s not too many steps away from having a good old fashioned ops team. That being said, a lot of collaboration with the developers is required and does happen; however, one glaring problem that we are faced with is that of focus.

When each individual on the team is spread across a plethora of different teams and applications, all with their own niches and ways of working — context switching becomes a huge issue. A lot of these sorts of issues are almost dismissed by people saying that “DevOps should be a mindset, everyone in the organisation should know how to apply it”. Which sounds really nice when you’re presenting at a conference or writing a textbook, but in reality you have to start somewhere. Everyone is trying to find their groove when it comes to DevOps and I think one of the big challenges DevOps at domain is currently tackling is focus. Which leads me to my second takeaway:

DevOps is hard.

Every individual on the team eventually needs to be across every aspect of the software development lifecycle — CI/CD, networking, infrastructure, monitoring, application knowledge, etc. This kind of knowledge can’t be imparted onto a team in a project or in a training course. There has to be champions who push for DevOps practices, whether they are embedded within the teams or come from a centralised resource pool.

And this isn’t just me trying to keep myself in the job, I (and many of my peers) firmly believe that a good “DevOps engineer” would like nothing more than to automate and teach themselves out of the job.

I’ve just realised how many times I’ve written the word DevOps in this article, let’s see if we can do this final section without mentioning it.

Innovation, it’s a wonderful word to hear when you work in tech and even better to be a part of. The nature of the culture at Domain breeds innovation — give a bunch of smart people the freedom to try solutions they think are the best and trust them to determine the best fit for the company. In the realm of DevOps (couldn’t do it) this is especially crucial because the industry moves at blinding speeds, we’re expected to learn and pick up a new technology every second week otherwise you risk being left in the dust. This meant that we were able to experiment with bleeding edge technology and adopt it if we saw the benefits.

However as Uncle Ben once said, with great power comes great responsibility. Having all of this freedom and incentive to innovate can be a double edged sword when it comes to tech debt. We were really good at implementing cool new shiny things, but not very good at cleaning up after ourselves. This creates a backlog of legacy systems that we’re still expected to support and maintain, many of which the majority of knowledge is lost over time. And as champions of certain technologies leave and new people and ideas come into the team, the stack is re-architected creating more legacy — it’s a vicious cycle.

The main contributor to this issue in my eyes is unity. Within the team there needs to be unity on what we implement and promote, but more importantly our end users — the developers have to be on the same page. If the incentive to move off certain technologies and implement new ones comes from us as well as developers, our goals are aligned. We no longer have to support this beast that no one really understands because some developers are still using it. This is the essence of DevOps. So my final takeaway is this:

Innovate, but be calculated

Are you innovating for the sake of innovation? It’s often a hard pill to swallow, but the value of your work needs to be agreed on by everyone that it effects, otherwise you will end up with competing priorities.

DevOps is a fascinating thing. Seeing and hearing about how it manifests itself in different organisations and the challenges that come with it are what keeps me hooked — My experience and Domain has certainly added fuel to the fire!

Related posts:

NBA Live mobile is the suitable and also in fashion version of significant basketball computer game in sight of NBA events. The game is generated by Electronic Arts and is made available for…

The act of continuously evaluating and adjusting the resources that drive your business applications, infrastructures, and workloads is known as IT cost optimization. IT cost optimization, when done…

My psychic powers are pretty much limited to knowing what I’m going to have for lunch, though sometimes I’m wrong about that. When I started practicing meditation, I had all kinds of ideas of what it…