DevOps — The journey to collaboration
I’ve heard many people refer to DevOps as if it is a destination. However, from practical experience, I can tell you that it is more like a journey — sometimes even an Odyssey. You can stumble and fall, get back up again and then experience an encouraging moment. It’s a fun trip regardless.
So what is DevOps?
DevOps is Agile and Agile says that you do what works for you. This means that all companies might have a different journey to a similar destination. Below are two formal definitions:
“DevOps is the union of people, process, and products to enable continuous delivery of value to our end users.” — Microsoft.
“DevOps is the combination of cultural philosophies, practices, and tools that increase an organisation’s ability to deliver applications and services at high velocity.” — Amazon.
The value of DevOps is locked in the last parts of both definitions; “Continuously deliver value to our customers”. We live in a time where the way we’re developing and deploying software has changed so much and so fast. We are generating and storing more data more quickly than ever.
Feedback loops from customers are so short that the end customer has the potential to tweet about something that went right or wrong faster than the deployment tool can report success. So if we are still writing software for a year, then shipping for six months, we might be doing it wrong because the customer will suffer for a long time and probably go to a competitor in the meantime.
With Agile, we have made massive leaps towards delivering value more often, and this to me, will probably remain a big part of DevOps, but we need to embrace different release cycles for various features: Releasing a feature and adding value as soon as possible instead of doing one ‘big bang’ deployment. When building software correctly, releasing smaller components more often would reduce the risk. We leave what is working and add value running in production; we fix what is not working. Continually improving the software should be the norm.
Unfortunately, I’ve also seen the abuse of DevOps as a buzzword. Buzzwords often appear when there is too much ambiguity and vagueness around a topic.
In essence, DevOps is simple.
The simplicity of DevOps rings truer when it comes to the technical implementation, which is usually done by a combination of developers and operations.
If it’s simple, why is there so much ambiguity? Because the tech geeks (that’s me) that drive the DevOps movement focuses a lot of the effort on the technical implementation, and this is only one leg of the three pillars of DevOps.
The people and the process requires a lot more convincing. We have to break down a thought pattern that was introduced a long time ago. Agile made it an easier step, but Agile has only seen much adoption recently, and now we are “changing” again (Talk about being agile about Agile).
The easiest things to change are the things you have direct control over. When all these blocks are in place, convincing a non-techie that DevOps has value won’t take much. It all boils down to TRUST. We need to trust our software, we need to trust our process to deliver the correct changes and then only will your Customers/Stakeholders TRUST a dev to make changes to a production system as they see fit.
As part of the journey to DevOps nirvana, the developer can start with these nine things to ensure that we build confidence and TRUST among the team and ultimately building TRUST with the customer.
9 Things a developer can do to kick-start a DevOps conversation:
- Unit testing — the confidence currency.
We need to know our changes aren’t breaking any of our other code. - Continuous Integration — Let’s break and fix faster.
Our team needs to know that our code plays well with others. - Autonomy — We know what we want.
A monolith application may not be the best project to run with DevOps especially if you have multiple teams. Let’s talk MicroServices. - Continuous code quality — No project too small to do right.
We need to make sure that our pursuit of speed does not compromise the code quality. - Monitoring / Instrumentation — Let’s see what’s happening in Production.
We need to know what’s going on, as if we were debugging in a code editor, we need to see everything. - Continuous Deployment — The code is there, you want to use that feature?
If we feature flag correctly, the code can live in Production and only be made available when required (After signing off elsewhere). - Understanding the environment your code runs in — It works on my machine.
One if the most common issues found, the environments are configured differently, works in these environments but fails in production. - Automated integration testing — Working closer to your testers. We know for a fact that our code is still working as expected because our unit tests have proven this. Do we still play well with the other integration points?
- Dev and Ops together — We are one team, with one goal.
For a long time, it’s been about who throws the most things over the wall. With DevOps, let’s remove the wall. We can then use the throwing energy on some beers after work!
Once we have bedded down these nine things, we can have the conversation with the customer, where they tell us they didn’t even know we had implemented the DevOps approach — They just know it works.
Finally, DevOps is about bringing people together to focus more on delivering value and creating awesome software. Sounds impossible? It’s not.
If you have any questions or comments, please leave them in the comments below.
Get in Touch!
