DevOps and the Spiritual Awakening

Growing up, my dad would often encourage me to focus on the small and simple things in life. It was his hope that, with this knowledge, I would accomplish great things. By playing, working, and socializing, the small things we learn create patterns of behavior. We are creatures of habit and the more we repeat a habit, the harder it is to break. Pair that with this age of rapid technological change, and we face the problem of what was right yesterday is not what’s best, or even close to efficient today. Old habits, once revolutionary, became outdated very quickly. We are so attached to them however, that we forget to adapt and grow.

Waterfall Model

During college, I learned the Software Development Life Cycle (SDLC) using the Waterfall Model. I found this approach organized and methodical, but it didn’t leave much room for error. This approach has been used by the tech industry for decades. For example, an app development project would be drawn out over the course of two years, with nothing released until the one-time massive implementation.

This process ensured internal testing but had no practical testing in the field. As such, high numbers of bugs would occur at the time of release, overwhelming database and development teams. Customers felt very unsatisfied when the release wasn’t as flawless as planned. The process for deploying the code (app, database, and infrastructure) was manual and error-prone and did not easily transfer between individuals. Companies designed entire software suites to aid in managing the code deployment process.

The Role of a Database Architect

As a Database Architect (DBA) with over 15 years’ experience, I have a unique perspective on change and the need to adapt. DBAs are an interesting breed; we’re smart, but many carry massive egos. In most work cultures, the DBA role is the only one stopping critical, database-dependent systems from crashing and burning, effectively taking the company down with it. Because of this responsibility, I became very good at reviewing & deploying code, architecting disaster recovery plans, and stopping developers from hurting my databases with inefficient, or even dangerous, SQL code.

I felt honored, a sense of purpose, and was fulfilled by these responsibilities. All was well in my little world of command and control. However, the unintended, but the natural consequence of my role lead me to slowly become the enemy of the developer, and even the whole IT industry.

As our industry progressed, developers, managers, and companies wanted a faster, and less bug-prone, approach to testing and deploying code than the Waterfall Method. Developers felt blocked by DBAs and this dysfunctional relationship tended to fester for years. Developers taking shortcuts to bypass DBAs lead to even greater problems when it came to DevOps. We needed a single team with common goals and both operational and developmental expertise. Little did I know, I would be schooled and humbled in this very lesson.

Following the DBA Code of Conduct Considering DevOps

Several years ago, I was approached by a gentleman my company called a “Scrum Master”. He wanted to chat about adopting a new process of giving developers permissions to push code into production themselves and allow them to introduce new database platforms other than SQL Server into our environment. He also requested that I give some of my time to attend a daily scrum meeting. It was his opinion that coupling my operational expertise with empowering developers would lead to such efficiency that nothing could stop us from accomplishing all our business and departmental goals.

Surprised by his request, I dutifully replied that I could not support what he asked me to do. I had a thousand objections. What he was asking me to do violated the long-standing tenet of the DBA code of conduct: keep our production environments isolated and protected. Not to mention, and more importantly, the thought of giving away control offended and scared me.

I asked myself the following questions: What value would I have if this was allowed? What damage could an unchecked developer do? There are over 400 developers and only five DBAs, how would we have the time to attend every scrum meeting? What about SOX, PCI, and HIPPA protocols? Indeed, the Bill Murray quote Ghostbusters was not that far off the mark: “Human sacrifice, dogs and cats living together…mass hysteria!”

Joining Forces

The conversation continued, and I will admit, it became contentious. The Scrum Master viewed DBAs as controlling, close-minded, and eager to hold onto power. I viewed him as an inexperienced radical who was not only threatening the stability of our databases, but my career as well. I asked him where he received the authority to enact such a change? He told me that if I was worried about authority then this process won’t work at all. We both just stared at each other. Two people could not have communicated more poorly. We left the meeting agreeing to disagree.

Shortly after my meeting with the Scrum Master I brought his request to my manager’s attention. His response (more of a rebuke) was a career changing epiphany for me:

“Dustin, if you don’t adapt you will get left behind. Your vision is short-sighted, selfish, and you are denying your company the possibilities of running a thousand-fold more secure and efficient system by not being open to exploring this new process. The Scrum Master wants to help you, but in return needs your help as well. He needs your expertise to keep the systems secure and you need him to empower the developers to do great things.”

My approach being wrong was not something I had considered. I concluded that both my expertise and the developers’ experience was valuable. We needed to work together. I began to realize how dysfunctional the communication between ops and devs were and I felt embarrassed. Together we could do fantastic things that were good for our product, the company, my career, and even the industry as a whole.

Progress and Growth in DevOps

I couldn’t escape the feeling that automation was the answer. If we were going to empower developers, we needed to create a less error-prone process of deploying and managing our code and infrastructure. We needed short and measurable goals plugged into a long-term vision, that could be course-corrected along the way. We needed collaboration in order to teach each other.

I decided to do some research. I googled “Information technology unity” and, after scrolling through a few pages, I found the term DevOps. I read about Pipelines, Continuous Integration/Continuous Delivery, unit testing, cloud and on-premise deployments, culture shift, automation, authority, stability, success, monitoring, PaaS, and IaaS. I was an instant convert.

It wasn’t about me anymore; it was about progress and I wanted to be a part of it because I knew this was not only good for my employer but would be fantastic for my career. But where could I start?

Read about the personal aspects of the DevOps conversion here.

Connect with Fortified Data on Facebook.