Some popular DevOps quotes and what I learned from it using in my day-to-day development
“Simply put, things always had to be in a production-ready state: if you wrote it, you darn well had to be there to get it running!” — Mike Miller
I purposefully kept this as first. We usually create some awesome features in our projects and we will have a date to release it to end-users. More precisely, we will not be releasing just one feature. We will have a bundle of features in the pipeline waiting to be released for our sprint. If you are into the waterfall SDLC model, you will wait a whole lot more than a month. The delivery is just the tip of the iceberg. What follows next is what we will be most interested in. How did it go? Did it have defects? Did it match the end user’s expectations? Will we get positive feedback and positive feature updates?. Our mind will be running on haywire at a release. The problem with these types of bulk releases is that we might not know the outcome exactly. If something goes wrong, the path to backtracking and making the changes will be huge.
Following one of these patterns has backfired a lot of time in my previous projects and one I came across. We will get reports of unusual bugs, a sudden drop in performance and the most important thing is that it is not like what the end-user expected. That's strange!! we collected those requirements and delivered it exactly. Yes, but what we collected is what the end-users thought they wanted but not what they needed. The point is we never know — until we get a piece of working software directly to them while we are developing. So we updated our methodology of software delivery. We went full-on Continuous Integration and Continuous Delivery. Every single functionality developed was immediately moved to the staging environment(or our UAT environment). This improved collaboration with the end-users, to make sure if the product is going as expected and catch bugs as early as possible. This also gave us a vision of how it will grow and how can we align ourselves to the growth. So yes, the first step is to get our idea as fast as possible to production and see if it works as we thought.
“A phased approach to continuous delivery is not only preferable, it’s infinitely more manageable.” — Maurice Kherlakian
When we initially started with the Continuous delivery model, people were a bit skeptical. There were all sorts of questions and discussions running around.
- Will it work? And how will we manage it in long run?
- What will be the learning curve? What if we across some roadblocks?
- How long it will take us to create a good working model? And if there is some rapid change in it or if it is not working as expected how fast we can expect an upgrade?
- How to break the organizational culture of manual delivery? How to migrate existing projects to a continuous delivery model?
- How to migrate the people working in a different approach to this? And how to do it with minimal confusion and conflicts?
First, nothing will work if we just stopped attempting. We never know what kind of potential benefits we will unlock down the road without trying. Come on!! it is already a buzz word. There must be a reason it's widely praised. There must be a way in how products are successfully delivered using it. We just need to experiment and find.
We will definitely have a learning curve and we will hit a roadblock. I did get stuck up several times initially. If you are already an operations engineer and know in and outs of server configurations and deployments, this must be piece of cake for you. We are just automating what we are supposed to do manually.
It took nearly 3 months for others to see the benefits when i first started using it. The immediate benefits were visible within weeks of implementation but long-term benefits were a bit like a side effect. It was there, the stakeholders and end-user were experiencing a faster and good delivery. For me personally, having continuous integration and delivery made my code and design pattern much more manageable. Yes, as we start using it, we will find it to be an easy implementation of the next set of projects. We find more ways of improving it and make it productive as we might have already hit roadblocks and we will start exploring the alternatives. Continuos delivery was much more enjoyable and manageable as we proceed on.
If you think it’s expensive to hire a professional, wait until you hire an amateur — Red Adair
I was an amateur in DevOps at the beginning of my career. Because I was fresh into the part of development, more importantly, I was new to moving a web application to production all by myself. I just started to pitch these ideas just a few months after joining. Previously I had a lot of theoretical exposure to DevOps practices. So it saved me in most instances. If these methodologies were immediately moved to all our live projects, I might have been overburdened. I might have hit a wall and might have struggled.
The organization might have seen a rise in the expense of time and quality and delivery. But I became a sort of professional in the meantime, where I explore and improve the pattern, implement it in multiple projects that I have worked upon voluntarily at least at infra and code level. I started as an amateur and become close to a professional when we start rolling out to all projects. The journey ahead is already bright. So yes being an amateur is risky based on the volume and depth of projects. Don't expect an amateur to do flawlessly on day one. But it is purely based on what kind of freedom you have in your org and what kind of impact you can create if you are positive and keep experimenting.
Programmers don’t burn out on hard work, they burn out on change-with-the-wind directives and not ‘shipping’. — Mark Berry
I feel this doesn’t need much in-depth analysis as we are already aware of the consequences of it from the first quote itself. Each of us developers- we all can agree on one thing, we burn out when we see our work has become something that is not necessary or completely useless. All of our efforts go waste because we missed some crucial bugs and it's not what the end-user expected. We would have given anything if we had known beforehand how it's going to end up. We have more thresholds on accepting more work than required, rather than accepting that our code is useless in the end.
“The most powerful tool we have as developers is automation.”
I don't have enough words to express this. What initially started as a way to automatically move code from local to development server grew upon on me very fastly from several perspectives. Be it in improving our continuous integration model, automatically roll back to the previous deployment on failures, automating the configuration and provisioning of servers, environments, and databases with Ansible, containerizing small app stacks and make it readily available in any server, automatically move logs and visualize it with Loki and Grafana, setting up Sentry to capture errors on-demand and notify, automatically monitor our IoT devices with Prometheus and Grafana… The list keeps growing. Just automate whatever you can in your day to day development. Some might seems very tiny and minimal, others might not be necessary at the moment. But the more you start exploring the automation, a whole new set of ideas and methodologies will rise from the wisdom you acquired from developing it.
The key in such a transition to continuous delivery is to expect things to get worse before you’ll be able to make them better — Matthias Marschall
When I first pitched the idea of continuous delivery to our manager, there was a little bit of doubt and risk associated with it. But based on my POCs and work I got a green signal to use it in one of my projects. It was not very smooth at the start. The pipeline was running a long time, my configuration looked very basic and naive even to me. In one case, I didn't get notified of a database migration failure. The job status was shown as a success. This was due to how the integration server handled the exit codes. In my case, the migration has happened(means the script was running and the model creation process had occurred). but it was incomplete or failed. And it returned an exit code that the CI job considered that as a success. So I manually handled it using a shell script to respond with a custom exit code to fail the job on migration failure. But every effort is a one-time workaround. Once you cracked it, you will reach there faster each time you come across similar problems.
“Lack of trust in an organization is really expensive. You can’t villianize others if you know their kids.”
I got a few words for it. Our team attempted the model, we are aware of failures. We were more inclined to achieving it rather than being doubtful. The team effort of backing up each other and our higher management support to start using it pushed us forward. Trust is really expensive to earn. One that can be earned by being honest, having integrity, and maintain a calm demeanor in face of trouble. And lastly, taking responsibility for our failures. Which brings us to the next one.
“Showing a strong success and visible benefits is key to getting others to agree to try your way of doing things.” — Frederic Rivain
No one will follow us if we keep saying something that we are going to achieve. Just like taking a working software immediately to end-users hands, we need to showcase a working model of our efforts. When we implemented DevOps in our projects, I would say it took 8 months for people to recognize its potential. The longer time-period was because of the Covid19 pandemic and minimal transparency between teams. The word of mouth is powerful. People started feeling interested in it suddenly because it is no longer in tutorial videos or educational articles. It is there working successfully for a fellow team and a fellow project.
“To successfully implement continuous delivery, you need to change the culture of how an entire organization views software development efforts.” — Tommy Tynjä
So we can say that we need to change the perspective of our engineers and management on how they view software development. One that will need a strong proof of concept.
“Currently, DevOps is more like a philosophical movement, not yet a precise collection of practices, descriptive or prescriptive.” — Gene Kim
This is one very truthful message. The implementation of DevOps is going to different for each organization and team using it. Your team might never need Sentry like tools to capture errors. Your organization might have yet to start with a containerization platform. You never had a need for continuous monitoring or security or testing as these were handled by third-party services for you. You need to figure out what is the most essential transformation that your team needs. What impact it will bring to people around you and how smoothly you can transition the solution between teams. How automation is going to help the work environment you are in. It's a philosophical movement. If you are going to initiate it, make sure you are backed up by a strong POC and essential facts with working implementations. And most important of all, be ready to increase your perseverance
“TDD creates consumption awareness: when you create a unit test, you are creating the first consumer of the code under development.” — Neal Ford
Although we are yet to push code coverage fully. The moment we started using unit testing in our development, we got very good quality improvement. Bugs are one major thing that we will be able to capture before moving to production. But due to the need for time and efforts, we still can't standardize it. We are not stopping it though. At least the basic functions related to the Smoke test or BVT test in QA can be unit tested(the essential functions of working software). It can be minimal even in the API world. It is not about validating all boundary cases of API at first. But rather the basic function on if it does what is intended to do. I humbly accept this. Unit testing is one of the difficult parts to start and continue.
“If you adopt only one agile practice, let it be retrospectives. Everything else will follow.” — Woody Zuill
If we want to stay fit, we just need to start an exercise and be consistent with what we do even if we are doing only 3 exercises. This goes for any other thing. I started with only creating and defining user stories, mapping it to the milestone, or sprint. Making estimation and tracking how much time I spent on a particular user story. That’s it. No matter the task, I still keep doing it. Being comfortable in one of the Agile methodologies, all other things will fall into place eventually.
The last quote doesn't need any more special mentioning, our own evolution is a stark example of it. From Charles Darwin,
“It is not the strongest of the species that survive, nor the most intelligent, but the one most responsive to change.”
What is your interesting take on the implementation of DevOps? How was the journey? What were your roadblocks? If you had stopped?Hope this post gives you some inspiration to keep pushing your limits.
👋 Join FAUN today and receive similar stories each week in your inbox! ️ Get your weekly dose of the must-read tech stories, news, and tutorials.
Follow us on Twitter 🐦 and Facebook 👥 and Instagram 📷 and join our Facebook and Linkedin Groups 💬
