It was not long ago that I though DevOps to be one of those things that happened to other people, and honestly, I did not give it that much thought. That was a time when I was a DBA in the part of the company that does deployments and support for our products, the Ops.
After working in the Ops for almost 20 years, at the beginning of the 2017, I transferred from the Ops to the Dev to lead a small team of database developers on a grand quest to save the world. For me this has been an eye-opening experience in many ways and it has also made me realize the value and possibilities of the DevOps culture.
Let me tell you a story on what happened and brought on this change of heart.
Dev vs Ops
I believe that in most organizations where the Dev and Ops people are kept in their own silos, or whatever you call them, there will be some amount of animosity between these groups. Since people do not dislike each other automatically based on where they might be on the organizational charts, the question is, what causes this animosity?
Based on my own observation, it often comes simply from the lack of understanding in the both sides of the fence on how Dev and Ops work. And then there is the fact that these two groups have vastly different expectations and requirements for the software that is being developed. This unfortunately has a tendency to make them natural opposites of each other.
To put it simply: When the Devs are not part of the teams that deploy and administer applications, they will not share the same view on the possible issues than the Ops. And when the Ops are not part of the development, it often means that the in-depth knowledge of these applications stays only with the Devs and not with the people who handle the day-to-day operations. Ops on the other hand tend to have a good understanding of the metrics that should be monitored, which would be important knowledge for the Devs when they design APIs for that purpose.
And these are just some examples. To bridge this kind of gaps is not an easy task and to accomplish it, it requires more than good intentions.
Communication plays an important role here, as it can be one of the first things that lead to actually having any type of DevOps culture, or at least that is my experience on the topic. There was a time, long ago, when I would happily sit in my cubicle (happily, in cubicle??) wondering what is up with these Developers coming up with ideas like these. And I think that most people working in the Ops have had similar thoughts over the years.
Eventually I started having dialogue with our Developers and Architects alike and it paid off. These discussions were often about sharing information on how we build production environments, how we implemented High Availability and Disaster Recovery, what version of Windows or SQL Server to use, and many other things of the similar nature. However I still could not understand the Developers, because I mostly shared my knowledge to them, but I did not ask questions in return (that I learned bit later on my career).
And then I became a Developer…
Having worked in the Ops for a considerable time, I have come to know that world rather well. It is the world where we are concerned about things such as SLAs, RPOs, RTOs, backups and restores, data integrity, deployments, security and a long list of other things. When I went to a Developer territory, I did not simply feel like stepping outside my comfort zone. Instead, I felt like I set my comfort zone on fire and launched it to outer space.
Luckily I have good colleagues, great ones actually, who helped me to get into speed relatively quickly. With their help I started learning the ropes on how to work in a Scrum team and getting more insight on how our Developers worked. I also became familiar with the processes and tools they used rather quickly. One of the tasks my team was given had to do with renewing our database development practices to better support the new architecture. Being now more familiar with the Dev side of things, I soon realized that they had a number of good practices, such as source control and test automation, that would offer some interesting options for Continuous Integration on database development.
Armed with these ideas my team began it’s work. We started to put together a solution piece by piece to bring the database to an equal footing with the rest of the software development. As we moved forward, I made sure to maintain communications with our Architects and Developers for a feedback. In practice though, while I had adopted many good ideas and even some of the language from the Developers, my Database-as-Code approach was very Ops oriented. It was, after all, the area I knew the best.
The issue with the focus on Ops became reality when we started discussing deployment methods with the Developers. They wanted to keep the schema together with the application and for me, that was a cause for a huge disturbance in the Force. It actually took me one whole weekend to chew on that idea, before I started feeling comfortable with it. Looking back now I can tell that my initial dislike for the idea came as an instinct, an automated response intent to keep the Dev and Ops separated. I suppose that is what the long history from working only on one side of the fence will get you.
As I finally managed to tune out that nagging feeling on the back of my head and took a better look at the idea, I realized that it actually completed what I had originally suggested and made it even better. The solution we came up with, together, turned out to be quite good. This was also the tipping point for me, where I would finally start seeing the benefits of bringing the expertise of the Dev and Ops together. The solution we came up with also opened up some exciting possibilities to actually share the responsibilities between Dev and Ops during the maintenance and development of the software. It will be interesting to see where we will go with it!
I believe that such possibility of shared responsibilities will play an important role in the future, as far as nurturing a developing DevOps culture goes.
So how do you build DevOps culture and why it matters?
This is a topic that could easily make a blog post on its own. I will however briefly summarize some of my thoughts on it.
In recent years many new technologies and trends have emerged that have huge impact on the traditional Ops tasks. For example the infrastructure as Code approach for provisioning infrastructure is one of the things, where employing Dev practices like source controlling, will be essential for the Ops. I believe that most of the Ops people are already working quite a lot with scripts to set up servers etc, so source controlling these like the application code, could be a natural next step.
While we are seeing plenty of new technologies, like containers, making deployments faster and more reliable the Devs still need to pay attention to Ops beyond that. What I mean by this is, that when designing software things like maintenance and monitoring need to be taken into account. Always consider the design also from the Ops perspective and make sure you are creating and giving tools to the Ops they need.
As how to get the Dev and Ops people to work together? I honestly do not have a perfect answer to that. How I would do it, would be to make sure that the Developers always participate in deployments to production environments for their own products and every once in a while work in the support. I would also make sure that the Ops people participate in deployments, troubleshooting and monitoring in the development and pre-production environments, doing it just as they would do it in the production.
As the Dev and Ops people generally tend to be interested in technology, albeit from bit different angles, you are likely to see something good come from them working together. I would probably not set up dedicated DevOps teams, because they just seem bit too artificial creations. I believe that creating and nurturing DevOps culture is something that should happen at the grass-root level, naturally, and not forced upon the Dev and Ops people.