3 DevOps Lessons Learned While Scaling
July 15, 2016

Adam Serediuk
xMatters

Throughout my 15 years in operations I've noticed the same dilemma pop up within most organizations that practice traditional software development – many companies have gotten into the habit of "triage" development. They react to problems defensively, and because the strategy is reactive, triage development occupies most of the ops team's time.

When the ops team is constantly putting out fires, they have no time, people, or tools left for building the actual product. Make no mistake, the operational component is equally important to the product. Recognizing the cost of constant fire-fighting, many teams take a more proactive approach and try to predict breakdowns.

Failures are inevitable. However by implementing a few best practices, operations professionals can take back control of their output and build more resilient systems. Here are three lessons I've learned that have allowed my teams to spend more time building up, rather than hunkering down:

1. Automate the B.S.

We've already established that spending your time putting out fires is a sure-fire way to guarantee you'll never be productive. So, should you automate your system completely and eliminate the need for human intervention in incidents? Maybe, but that's an awfully lofty goal to start. You may not need total automation.

The key is to find the right areas to automize. This should be determined strategically, but there will also be an element of trial and error. If you put automation in the wrong place or discover a newer, better way of doing things, don't be afraid to throw code out.

Some people think that constant change causes lines and logic to become muddled. I happen to believe the opposite. Constant change can eliminate problems. Ops teams should not be intimidated by change. Embracing change on a regular basis will make it less scary, and you'll see fewer fires as a result.

This must be balanced with automated testing and QA of Ops code and infrastructure. The same software development approach to unit testing and test plans can and should be applied to Ops, to eliminate regression and enable confidence in change.

2. Go Beyond IT Automation

Repeat after me: Deploying an enterprise IT automation platform is not the same as adopting DevOps. Developers, systems administrators and operations professionals use these platforms to manage the continuous integration/delivery pipeline that defines agile software development and manage system environments. While IT automation platforms are important for DevOps practitioners, they are in no way the foundation of the model.

Give equal focus to the process – the build, test, release, deploy and monitoring lifecycle – so you can iterate quickly on changes. I've seen far too many DevOps teams focus only on their automation code without giving adequate attention to the software development process and how this code fits into the larger picture. This means having ongoing conversations with your teams, QA, Development and Ops alike.

By ensuring conversations are ongoing, DevOps teams can deploy IT automation without making the situation more complicated for themselves. The team should be able to understand each deployment framework or tool selected to run automation code and where it fits into the big picture. This may mean team meetings and regular messaging, but, hey, communication is what DevOps is all about.

3. Reset Your Definition of Done

As we've seen, constant change is essential for avoiding problems. That's why startups are passing over traditional development for soft releases and continuous, everyday delivery. It's also more stimulating for the team when every day is different, and releasing small, incremental changes is safer than large monolithic releases. Recognizing the changing tide of software development, the industry has developed deployment tools that have unit and integration testing baked into them.

Thanks to these new tools, IT professionals are able to complete tasks to a fuller extent. Not only do they build, they also test and launch. With this power comes responsibility; there's no excuse for leaving anything short of "done." This is where product owners can enable and support the process, by giving equal importance to uptime, continuous delivery and testing as part of story planning.

One of my past roles was Lead Operations Engineer at a mobile and online gaming company, where my team and I built the software and cloud infrastructure. Recently, I spoke to my former boss and he noted how the code I built performed reliably in the two years since I left. The secret was developing a cohesive system, a complete package through continuous iteration. Investing in this process allowed us to build a product that adhered to the new definition of "done", which made it good enough to last.

Which brings us to what might be the most important lesson of all: software code should not exist separately from infrastructure code. The reason is simple – infrastructure without software is pointless and software can't exist without infrastructure.

Conway's Law states that "organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations." In short, if teams don't talk to each other, parts won't talk to each other. At the same time, if a product is built to work as a whole, it will work. So, why not put the pieces together?

Adam Serediuk is Director of Operations at xMatters.

The Latest

November 14, 2018

What to automate? Which parts of the delivery process are good candidates? Which applications will benefit from automation? At first, those sound like silly questions. Automate all your repetitive processes. If you think that you'll do the same thing manually more than once, automate it. Why would you waste your creative potential and knowledge by doing things that are much better done by scripts? Yet, an average company does not adhere to that logic. Why is that? ...

November 13, 2018

I'd love to see more security automation deeply integrated into the development process. Everybody knows since the 1990s that security as an afterthought just doesn't work, yet we keep doing it. The reason, I think, is because it's very hard to automate security ...

November 09, 2018

DEVOPSdigest asked experts from across the IT industry for their opinions on what steps in the SDLC should be automated. Part 5, the final installment, covers deployment and production ...

November 08, 2018

DEVOPSdigest asked experts from across the IT industry for their opinions on what steps in the SDLC should be automated. Part 4 is all about security ...

November 07, 2018

DEVOPSdigest asked experts from across the IT industry for their opinions on what steps in the SDLC should be automated. Part 3 covers the development environment and the infrastructure ...

November 06, 2018

DEVOPSdigest asked experts from across the IT industry for their opinions on what steps in the SDLC should be automated. Part 2 covers the coding process ...

November 05, 2018

Everyone talks about automating the software development lifecycle (SDLC) but the first question should be: What should you automate? With this question in mind, DEVOPSdigest asked experts from across the IT industry for their opinions on what steps in the SDLC should be automated. Part 1 starts with by-far the most popular recommendation: Testing ...

October 31, 2018

Halloween is a time for all things spooky, but not when it comes to your mobile app experience. A poor experience can not only scare off your customers but keep them away for good ...

October 30, 2018

As organizations have embraced open source, they have become polyglot — using multiple programming languages and technology stacks to accomplish software and hardware related tasks. Enterprises are caught between the benefits provided by a polyglot environment and the complexities and challenges these environments bring. Ultimately, if the situation remains unchecked, polyglot will kill your enterprise ...

October 29, 2018

Factor 5 of the Twelve-Factor App relates more to processes and advises strictly separating the build and run stages. The emphasis is on identifying and separating each stage of app development, and encouraging automation between each so as to accelerate the process ...

Share this