loading...
Cover image for DevOps Is an Evolving Culture, Not a Team

DevOps Is an Evolving Culture, Not a Team

kylegalbraith profile image Kyle Galbraith Originally published at blog.kylegalbraith.com ・4 min read

There seems to be a growing misrepresentation about DevOps. Sometimes it's represented as another team in the engineering structure. Other times it's a single individual inside of an existing team (i.e. DevOps Engineer). But these perspectives are wrong and missing the point of DevOps in my opinion.

DevOps is a culture, not a team or an individual. It consists of a collection of philosophies, processes, and tools that a team nurtures. It evolves, it's not static because teams and technology are evolving.

It breaks down barriers between teams, it doesn't build new ones. It is engineering-minded folks becoming versed in operations and vice versa. The two become a homogenous one. When done right it can transform an organization and product.

By becoming a homogenous unit development can move quicker. They can iterate on their product or service to better-fit user needs at a faster pace. All while maintaining the quality, delivery, and reliability of the product or service.

How does it work though?

From the outside, this sounds complicated.

To be frank, it can be very complicated in organizations where "siloed" teams are common. In these cultures, operation teams feel as if their jobs are at risk. Development teams feel as if they are being asked to do more on top of what they already do.

These cultures have problems that are deeper than they appear. Often times these feelings or beliefs stem from a lack of trust in the organization. Other times they stem from teams feeling disconnected from the purpose of their work.

Whatever the case may be, these cultures need to be reset in order for a DevOps culture to evolve in its place.

The simplest approach is to rip the band-aid off. In a DevOps culture, the silos are torn down and development is no longer walled off from operations. In a lot of cases, these two teams become one. Meaning the team handles the entire application lifecycle. From development to deployment and beyond, this team is accountable and responsible for each step.

This can feel very chaotic, as is the case when a major process change occurs. But, a great way to combat the chaos is to trust the teams to make the right decisions for them. Nothing will make this change fail faster than not having confidence and trust in the folks making the transition.

By combining the two teams a strong base of knowledge can be formed across the entire team. Operation folks can share their expertise from the deployment and monitoring side of things. Development folks can share their expertise from application development.

This knowledge sharing often results in processes that automate a lot of the repetitive, manual, and slow tasks in the pipeline. This automation expedites the delivery of the product or service. Automation also lowers the friction associated with deployments.

A DevOps culture requires a change in mindset. These teams need to be given the control of the systems and applications they are responsible for. The team owns the entire lifecycle of their systems. As such they focus on iterating quickly, collaborating often, and continuously improving.

This full ownership leads to decreasing inefficiencies, tighter feedback loops, and improved reliability.

What DevOps is not...

I find it frustrating to see organizations and teams implementing processes that run counter to what DevOps is. A team or a single individual is not responsible for DevOps.

To me, this is missing the entire point of DevOps. It is a culture that the entire development team holds each other to. This culture isn't static, it's fluid and evolving as members join the team and technology changes.

Furthermore, the culture of DevOps is going to vary between organizations and even individual teams. This is because one team or organization is not a carbon copy of the other. So you can learn new ideas and concepts from others, but those will meld into your team or organization.

There is a real business impact to be realized in a culture that is backed by DevOps principles. Tight feedback loops and automation associated allow the business to iterate quicker. Faster iterations mean faster decisions and value in user's hands sooner. These benefits are very real, but the implementation to gain these benefits must be done well.

Focus on the benefits and the outcomes that a DevOps culture creates.

  • Development Speed - innovate faster to drive business results.
  • Rapid Delivery - release frequently and reliably.
  • Reliability - release your product or service with confidence.
  • Scalability - automation and reliability allow you to scale your architectures with relative ease.
  • Collaboration - no more walls, more communication, and more ownership.

The culture evolves and so do the processes that realize it, but these benefits are your North Star. This is a collaboration that is meant to unite a team to deliver business results. It tears down walls and expedites the delivery of your product or service.

Conclusion

We have given this culture of fast reliable iterations with increased collaboration and a ton of automation a name. That name is DevOps, but really we could call it anything we wanted to.

The important things to remember with DevOps are the principles and the tangible benefits it can help you realize. It is not another team or a single person. It is a common culture shared amongst a team that promotes ownership, accountability, increased collaboration, faster iteration and tearing down barriers that impede either of these.

Are you hungry to learn even more about Amazon Web Services?

If you are looking to begin your AWS journey but feel lost on where to start, consider checking out my course. We focus on hosting, securing, and deploying static websites on AWS. Allowing us to learn over 6 different AWS services as we are using them. After you have mastered the basics there we can then dive into two bonus chapters to cover more advanced topics like Infrastructure as Code and Continuous Deployment.

Posted on by:

kylegalbraith profile

Kyle Galbraith

@kylegalbraith

Programmer by day and author by night. I am passionate about all things development related, but especially Amazon Web Services. I recently created a course about learning AWS by using it.

Discussion

pic
Editor guide
 

I think that what you say is what DevOps was intended to be, but to be honest, most developers I met have zero interest in the Ops part and they don't care. So, it kinda morphed into a position for individuals with skills at Ops and Dev trying to get some value from the original idea.

 

"...most developers I met have zero interest in the Ops part and they don't care..."

This is a tough one. Some do, some don't, some move from Dev To Ops, some Ops move into Dev. IMO, everyone in an organization should care about the product/service the organization exists for. A dev who does not care about the output of their labor is, honestly, not someone I would want to work with. The laissez-faire attitude spreads and the next thing you know no one cares and people start leaving.

 

This has been my experience as well. It is true that not all developers want to do operations things and it's even more true in the vice versa. However, I believe that is a trend that is going to change and must change if folks want a face paced, quick iterations, and effective CI/CD environment.

 

I'm with you in the idea that you should care about the complete lifecycle of what you do. The problem is that reality is what it is and in more or less 10 years I have found 3 kinds of attitudes towards Ops from developers:

  • They don't care as long as the build is green. (most of them)

  • They have zero interest in Ops but they don't want to depend on other teams and so they learn DevOps to have freedom. (usually, highly skilled developers that pursue feedback as quickly as possible)

  • They care about Ops and eagerly learn about it. (I have met about 3 or 4)

 

I kinda get the feeling that DevOps is similar to the organisational transformation or culture that a lot of business management talks about.

Just that we focus on a different term to talk about it in the tech context, we focus on it exclusively to ship software.

This is reinforced further while I was reading some chapters of the DevOps Handbook.

 

Absolutely agree. The DevOps culture is largely a business transformation but taken from the point of view of developers. DevOps Handbook is a fantastic book to read on this topic.

 

"...To me, this is missing the entire point of DevOps..." You and me both. I was recently at a client site and over heard a manager use the phrase "...if we are implementing agile devops we need X product...". It made me sad.

 

Exactly. I did a bit of consulting and this was a very common answer. I have seen how this plays out with Agile and I see folks taking the same approach when it comes to DevOps.

 

Hey Kyle, I can completely resonate with what you're saying. I think the issue is that while people rush towards developing their skills with new trends, they often neglect to develop their mindset to align with them. In order to build that DevOps culture, it's necessary for organizations to look beyond the technical skills of the development and operations professionals. Otherwise, as you said, there is no meaning as the point of DevOps is completely missed. I would like to know your views on this blog here that explains what it takes for organizations to match their pace with DevOps. Check it out here - cigniti.com/blog/key-aspects-to-co...

 

You might think about how docker and the "containers paradigm" have contributed to enforce t this kind of recent aproaching between development and IT.

I think is because never like before we have the opportunity to debug the app in a similar context that in production.

I have seen the phenomenon that you describe in one case. The DevOp team did make a lot of stuff with containers in the test and release process but undervaluated the need of setting up some add-ons to the development environment in order to make easier the use of the containers and debug them.

There are some examples in github that make use of a base image that is reused in period or DEV just by adjusting some parameters in docker compose.

As you say, it should be faced from both perspectives, but it should have a responsible DevOp group in charge that take into account all the necessities and not just the release deployments.

Deployment maybe ubiquitous nowadays thanks to containers. The app being developed can be provisioned in every development environment so easily as in prod, and with minimal differences.

That is not only good for new developers that come to the dev team. It is also good so that they can quickly reproduce situations that happen in prod. They're was a time where I could not reproduce some error in proof and it was because some dependency was different in prod. Those times are gone. 😉

The dev image can also include some automation scripts that handle the extra components (like orm operations with the database, running some tests, etc..)

So those kind of advantages are the ones that dev and IT teams can profit from when working together and shaping the DevOp culture that you say.