This time it is a bit of a historical view on how culture and technology change each other.

“The art of the critic in a nutshell: to coin slogans without betraying ideas. The slogans of an inadequate criticism peddle ideas to fashion”.

Walter Benjamin

In my previous articles, I defined DevOps and checked out (pun is intended) version control. After that, I explained the idea behind CI/CD pipelines. The next step would be to explain how some of the tools we are using slowly influence and enable the DevOps cultural side. Let's go on a historical journey to learn if we can see any change coming from the DevOps movement.

A Cultural shift?

Most people would argue that a cultural change would need a technological change (and vice versa). My point would be that the divide between the technological and the cultural is a bit artificial. They are interleaved and change each other all the time. It's an endless feedback loop; both are not existing in a vacuum; technology is changing all the time. I aim to see how this relates to DevOps transformation.

Developers and Operators? 

Before the creation of time, there were both devs and ops: ancient arch-enemies and rival tribes. Developers were called programmers, and they were the ones who would write the programs that were running on the computers. Operators were the people who operated the machines. They were making sure that the computers were working and available to the users.

In some aspects, nothing has changed, there are still people who write the software, but they are now called developers. There are still people who make sure that the platform is available, and in some cases, they are called ops, system engineers, or SREs. 

But if nothing changed, why am I writing this article? Let me argue that there is a change, one that I see as semi exciting. In some aspects, what we are seeing is a slow standardization of our field. We understand that using a specific set of tools makes life much easier when you move from a company to a company. But when people with different roles use the same tools, it's much easier for them to collaborate on projects and work together. If everyone uses Git, the developer, and the operator, they start to have a common language. This common language is slowly changing the culture. 

Developers and operators have been fighting for years, and if they don't understand the big picture, both would have different agendas. The developers would like to release as many features as possible, and the operators would like to keep their system as stable as possible. Each release that is being deployed would make the system less stable. One of the great merits of doing this DevOps transformation is that developers and operators become a team. They share one goal to release and maintain software that the end-user would enjoy. 

How can tools change the culture?

Let's be honest. The tools by themselves are not changing any culture. But the right tools used by the right people at the right time could help an organization change its current state. I must add that you can have a great DevOps culture in the organization without the tools I mention in this article; they are mainly used as examples.

I want to stress that for me, the tools are not created from thin air, and they are a product of their time. They are designed to give answers to technical needs, and they represent what is possible in the current state of affairs. Sometimes the big breakthrough comes from rebranding or tweaking some already available technologies that now can be used radically (iPhone, or Docker, for example).

This is all fine and dandy, but how does the tool reflect or change the culture? Until the last couple of years, devs would normally use their own set of tools, and ops would use their own. In the last couple of years, we see a shift, devs shifting slowly towards a more operational role, and vice versa.

Using tools that can appeal to devs or ops simultaneously is slowly bringing us to work together as one happy team. But what kind of tools? How this kind of shift happened?

Let's see what we can see.

Configuration Management to Infrastructure as code

The first shift i would like to show is the slow conceptual move from configuration management tools to Infrastructure as code tools.

Some time ago, most DevOps engineers would use CMs to automate their servers. Tools such as Puppet, Chef, Salt, and Ansible were synonymous with the idea of DevOps. 

Those tools were mainly a way to automate your stack. Yes, they could offer ideas on connecting developers and operators (for example, puppet modules needed some development). However, I think that they offered a limited perspective on what could be achieved. They were still mainly system administrator tools. As such, they were designed to be used by operators and less by developers. 

Nowadays, we prefer to use Infrastructure as Code (IaC) to manage and provision resources. Think about tools such as Terrafrom, AWS CDK, and Pulumi. They strive to add features of a real programming language to a tool that should provision infrastructure. 

Terrafrom tries to add layers over the HCL to make it feel and act more like a programming language and not just a configuration syntax. Amazon defines AWS CDK as:” an open-source software development framework to define your cloud application resources using familiar programming languages.” Pulumi offers another SDK that relieves you from using YAML or proprietary languages.

No matter which IAC tool you are using, it is still amazing to see how we can use developer concepts and provision our so-called “hardware” or underlying infrastructure. We took a long way from when someone like me needed to install the actual switches and routers on the company LAN and WAN, and now we live in a different world. I am not sure if I prefer it, but it is different.

Hypervisors and Kubernetes

A long time ago, in a galaxy far, far away, I work for a company called Qlusters. It was a revolutionary idea for its time to use a unified interface for a single datacenter. One of the things that were groundbreaking for me at the time when testing the tool was VMware’s hypervisor. The idea the one can buy a lot of cheap machines or one expensive machine and use hypervisors to provision virtual machines was amazing. Virtual machines are part of the cloud now. For example, AWS uses Xen for its infrastructure.

A virtual machine is already a game-changer, but it still uses the old language. And I recall that the first time we used AWS VMs was like a regular data center in the cloud. The VM brought a bit of a change since it was easier to automate it, and hence it's a reflection of the configuration management tools. The more radical change would come on the back of the VMs and cloud they produced.

Let's talk a bit about Kubernetes. It brings many great features to the game, but for me, the most interesting one is that it abstracts the hardware. Hence, you no longer need to think about the servers, but you think about different beings: pods, operators, services, etc.

Kubernetes adds a declarative API to provision your infrastructure. If there is something that developers know how to handle is an API, this mammoth of a tool is slowly bridging the gap between devs and ops technologically and culturally. It would make the developer’s life much easier. Some of its features add automation to tasks that the good old ops would do when the servers were down back in the days.

Kubernetes changes the way devs and ops work together; it shifts the responsibilities both roles have. Devs are now asked to deploy their own services, and ops are slowly shifting into building pipelines and maintaining the environment. The question we need to ask, is Kubernetes a result of the cultural change? Or was born only from technological problems that needed an answer? I think it's both.

GitOps

Last but not least, I would like to talk about GitOps. Some people would ask what's new about GitOps? We have been doing that for ages! Well, the fact you have been using Git to maintain your Terrafrom modules or YAML files does not mean that you have been doing GitOps.

In a sense, GitOps is a horrible name to describe a situation where everyone from the team uses git as the source of truth to describe the desired state of affairs. We are using Git in combination with CI/CD to automate application and infrastructure deployment. When you think about how everyone has a unified environment, the difference between developers and operators is slowly fading. We are using the ultimate dev tool to deploy and maintain the app and the infrastructure. That's a concept that can really be a game-changer if you think about it. Using the same tools makes dev and ops work more together.

Using operational tools that moved slowly towards the developer land and making sure that a source control tool is (hopefully) the source of truth and even rollbacks is somewhat of a radical way of doing things for someone like me, who used to do everything manually or with some bash scripts.

Conclusion

Culture and technology have their own special relationship. they are changing each other according to the trends and needs of the world around them. Of course, both of them are also changed by the business's needs, but for me, his is a different story.

Do you some questions about DevOps and tooling? Feel free to contact me or anyone on our team at Polar Squad. Empathy is one of our values, and now might be a good time to start doing some first steps in the realm of DevOps transformation. Feel free to drop us an email or Linkedin message! Maybe we can help you or guide you in the right direction.