Lessons from the DevOps Front Lines

Lessons from the DevOps Front Lines

By Flux7 Labs
July 29, 2020

While it may be difficult to imagine yourself as working on the DevOps front lines when you work from home, I’ve learned as a DevOps engineer at Flux7 that indeed that is the case. Here, I have had the opportunity to work on incredibly rewarding projects, the most recent of which is no exception. Recently I have been fortunate enough to be a part of the team that developed and deployed a proxy cluster setup for one of our customers. I learned several things over the course of the project that in the spirit of continuous learning (and improvement in the greater DevOps community) I share with you today. I’ll start with my takeaways about the project and working as part of an Agile team and conclude with my thoughts on specific technologies.

  1. “Stop Starting, Start Finishing”
    It’s in our very nature as developers to jump from thing to thing before actually completing any one item — I know it’s certainly exciting for me to start new things. However, I’ve learned that the adage, “stop starting, start finishing,” coined by Arne Roock in his book of the same name, is spot on. You make more progress by completing the task at hand before moving on to something new. By following this rule of thumb, you’ll accomplish more, stay on your Agilist’s good side, and act as a role model for the rest of the team, helping keep everyone on track.
  2. Agilist is a Metaphor
    Whether your company has an Agilist role or not, your team needs someone who is adept at translating and applying Agile principles to solve problems, while gaining team consensus. An Agilist who embodies agile traits like adaptability, flexibility, and willingness to learn and change, helps keep the team moving forward with a bias to action that continuously delivers value.
  3. Don’t Overthink It
    As engineers, it’s easy to overthink things, like testing. It’s in our nature. Yet, as I work from the serenity of my home office, I realize that overthinking leads to unnecessary stress. While I can’t say I’ve mastered this developer paradox, as it takes years of practice to overcome it, recognition is half the battle.
  4. Agile Communication & Teamwork
    While I encourage you not to overthink, I will encourage you to over communicate. Communication is indeed the key to success. In this vein, each Sprint takes a village. I am lucky to have that village to support me as I support them. Extending the metaphor, a few of the neighboring villages have stepped in to help us from time to time. With everyone exercising Agile practices, a unified team effort gets you to the destination with higher quality outcomes. 

Technology Insights

We used several technologies over the course of this project for which I had new insights or new appreciation. Specifically: 

  1. HAProxy
    HAProxy (the open source proxy server tool for high availability load balancing) is a new favorite. You can build a simultaneously strong and stable cluster of proxy servers around HAProxy, which is especially helpful if you’re grasping at straws for effective network load-balancing.
  2. Puppet for CD
    Every project needs a Continuous Deployment (CD) strategy in one way or another. While I wasn’t privy to why the team chose Puppet, the customer team was well acquainted with it. I found it took me some time to gain velocity with Puppet, but once I did, I could really get things done quickly. I’ve found this to be the case with other CD tools as well. I encourage you to use one — Puppet or otherwise — as the framework is helpful and once you’ve overcome the learning curve, is a powerful productivity tool. 
  3. Testing Code With Python
    For this particular project, we used Python for a majority of the development. As proponents of automated testing, we tested the code again with code, which really made it evident to me how Test-Cases boost developer confidence.
  4. Clean Code
    Most importantly, I’ve learned that it actually takes more effort to code sloppy than it does to write clean, quality code the first time. Frankly, it’s not worth it to write anything other than clean code.
  5. Pull Requests
    In the spirit of continuous learning and improvement, I leave you with this recommendation: always presume that pull requests are more about developer’s learning than anything else. As I said earlier, engineers are by our very nature inquisitive, and on a mission to learn something new. Pull requests are a natural path to this goal. 

Let’s keep the learning going.  For additional insights on building and managing successful Agile teams, please check out our blogs:

 

Written by  Nikhil Araga, Flux7 Labs

Flux7, an NTT DATA Company, is the only Sherpa on the DevOps journey that assesses, designs, and teaches while implementing a holistic solution for its enterprise customers, thus giving its clients the skills needed to manage and expand on the technology moving forward. Not a reseller or an MSP, Flux7 recommendations are 100% focused on customer requirements and creating the most efficient infrastructure possible that automates operations, streamlines and enhances development, and supports specific business goals.