Why I Am Thankful for DevOps
In one of five Thanksgiving-based articles, a Zone Leader provides aspects of DevOps for which he is thankful to utilize on a daily basis.
Join the DZone community and get the full member experience.Join For Free
In the United States, the end of the month of November is when time is taken to perform a retrospective-like event called Thanksgiving. What started out as a dedication to give thanks for the blessing of harvest and the preceding year has transformed into a time to simply be thankful for one's blessings.
Since Thanksgiving is recognized on the fourth Thursday in the month of November, I thought I would introduce a five-part technical twist with the following Thanksgiving-focused articles:
Thankful for DevOps (this article)
I hope you find time to check out the other articles, as well!
The Missing Link
I call it "the Missing Link," because for years (if not decades) there were some things missing from the development lifecycle:
The manner in which code was delivered was not consistent.
Complexity was always higher than it probably should have been.
The accountability was non-existent when code was pushed across environments.
Because of these challenges, often the code that was delivered for the testers to use was not the same code that was delivered to the production instances. The complexity was far higher, due to human-based actions which could introduce differences and/or errors. Most of the time, the individuals performing such tasks were simply following a script and lacked the skills to understand the operations and development aspects at play.
When the DevOps role became a reality, that missing link become connected in my mind. As mostly a feature developer with my career in Information Technology, I could not be more thankful.
Making CI/CD a Reality
The DevOps engineer is far more than someone who simply pushes a button to kick off an automated build because of some financial/security/audit requirement. Instead, they become part of the development lifecycle, with a focus on making sure the feature code is not only reaching the target destination, but doing so with the right design in place. They also focus on automation and migrate away from anything driven by an individual's actions.
DevOps often brings continuous integration/continuous delivery (CI/CD) pipelines into an application's lifecycle. A DevOps engineer’s strong understanding of application frameworks and design can build the necessary chain of events to build and deploy instances of the application in an automated fashion. In most cases, such pipelines are triggered following a certain commit (like a pull-request merge), initiating the flow using logic which is stored in the very same repository.
As a result, the CI/CD approach allows for that same version of code to be delivered to any target environment — including production. Thus, eliminating the potential for one set of code to be tested, while another set of code is deployed to production.
I cannot stress how thankful I am for role application containerization has played for so many of my recent projects.
On one instance, our team was informed that we would be introducing seventeen new feature teams to work on our project. Thinking back years ago, I had visions of the amount of time that was required to ramp-up a new developer and get system ready for use. Depending on the project, we were lucky if only a couple weeks was required.
Only a subset of those tasks was required when the services changed, in order to take advantage of updates from other feature teams. This was quite nice.
In fact, those same containers can also be utilized in the CI/CD section noted above.
* as Code
It is something I have referred to as "* as Code" which talks about defining as much as possible declaratively. The concept is to finally get away from more manual-driven tasks and replace them with functionality that can be described and captured in a repository, like git.
The benefits from being able to create an application server automatically not only gives the ability to automate scaling up and down as needed, but it removes the human element from the equation. This approach avoids those scenarios where the root cause of an incident is tied to an incorrect or missed step from an individual manually completing a task list.
The concept of application containerization implements this "* as Code" concept, as does a CI/CD pipeline. The idea of GitOps builds upon this same concept and I truly believe this concept is going to continue to advance.
For that, I am grateful and thankful.
With this article and the other articles listed in the introduction, I was inspired by realizing just how fortunate I am to be employed in an industry that has so many wonderful facets that can be employed on a daily basis. Since Information Technology is an industry of constant change, I fully believe I could revisit this topic on a yearly basis and provide another series of articles for which I am thankful.
As a kid growing up in the United States, there were two Thanksgiving television specials that I looked forward to watching each year: A Charlie Brown Thanksgiving and the Brady Brunch Thanksgiving episode (The Un-Underground Movie, season two, episode four). While most have likely seen A Charlie Brown Thanksgiving, I thought I would include a link to Greg Brady's school project, "Our Pilgrim Fathers," from that episode:
My hope is that you can take time this month to reflect on the things by which you are thankful. While I am blessed to work in such an amazing field, I am truly blessed that each of you has taken the time to read my article.
Have a really great (holi)day!
Opinions expressed by DZone contributors are their own.