The last couple of weeks, we've been having some great conversations about DevOps. On my Twitch streams we've been discussing the roles and responsibilities of DevOps engineers; all while playing Fortnite.
On our recent Twitter GitHub Community Spaces we discussed the definition of DevOps and what it means to "do" DevOps.
In both these instances, there has been a lot of lively discussion around "what does DevOps mean", and "who 'does' DevOps". In our Twitter spaces chat, I talked about the four pillars of DevOps as a good definition for what DevOps is.
What is DevOps?
DevOps is as much about a cultural change as it is about the tools you use. The word comes from the combination of development and operations.
If you Google "what is DevOps?", you'll probably see lots of diagrams like this:
This one comes from the GitHub DevOps website and it describes the lifecycle of DevOps, and the things you 'do' in DevOps. This diagram doesn't show the pillars or 'practices'. If this diagram is the things you 'do' in DevOps, what is the mindset or the culture around DevOps?
Many companies often ask: "we're doing DevOps now, what systems do we need in place to do the coding, planning, deploying etc?". You can't simply 'throw' DevOps into a company and expect it to work. The culture and the mindset around the way you work and develop are just as important (if not, more important) than the software and the systems you use.
Why? Because you can switch out the toolset as needed. If the culture and practices are there, everyone is on the same page.
In short, DevOps isn't software. Software helps, yes, but it's a set of practices. There are the four pillars of DevOps:
These aren't in any specific order, and I have collaboration first as it's one of my favourites. Here's a brief overview of each pillar.
Collaboration
This is an important part of any workplace. You need to be able to collaborate and communicate effectively with your team, and the border company. If you don't things will lag behind, goals won't align, and you won't be making a product to service your customers.
If you work together, have great teamwork, collaboration, and communication, you'll build better products.
Communicate effectively with your team and you'll all know what's going on. Image: Mulyadi via Unsplash
Workflows and automation
Every software lifecycle should have a good workflow. It might follow industry best practices, and you might have some practices your organisation follows. Good, consistent workflow ensures all products follow the same flow, everyone knows what's happening, and everyone knows where the product sits in the development timeline.
Building automation into that workflow will help make your flow more consistent, timely, and effective. You can build automation into your system with things like CI/CD, and many others.
This is really key to the diagram I showed above. That diagram above, the infinity diagram, is the DevOps workflow!
Security and Compliance
An important part of software development is ensuring your product is secure and compliant. Secure in the way it runs, stores information, and handles personal information. And compliant in the laws where the software is being used as well as practices within the industry.
This part is so important to the legal side of your product, that there are many specialists in this area. It is so specific, it even has its own title: DevSecOps, short for development security operations.
Even at GitHub, we have a saying: "we are all on the security team". Whilst there might be DevSecOps engineers, we all need to think about security.
Continuous improvement
Always be thinking about how your product could be improved. Not just improvement for the customer, but also improvement on the software side. How can you make the code better, cleaner, faster.
It is this continuous cycle of development that you'll in the see infinity diagrams. Those are key to DevOps. In the infinity diagram above, you'll see it never stops. This diagram describes how you don't just 'do' DevOps and it's 'done'. It's a constant cycle that continues to happen even after you release a product into the wild.
Who 'does' DevOps
The reason these pillars aren't in any particular order, is because all these things are as equally important when it comes to DevOps. These pillars sit over the DevOps infinity diagram and are part of every stage of that diagram.
Using DevOps allows you to be more innovative, and build various systems into the design of your product from the start. Ie. thinking about security throughout the design of the product means it isn't an after thought. Instead, security is robust and works well with the whole system.
In the same way, whilst we have 'DevOps Engineers', in a way, ALL developers should be DevOps engineers. Yes, there are specialities, and these should remain. But all software developers, as they are developing products and platforms, should be thinking about the pillars of DevOps:
- how do I collaborate better to make an awesome product?
- am I building automation into my product?
- is my product compliant?
- how can I improve the product?
Those are four key questions everyone should ask as they are developing software.
What do you think? Should we have DevOps engineers? Or should all developers be DevOps engineers?
Top comments (0)