First Steps in Embracing DevOps
Written by: Sam Linehan, Engineer Manager, TribalScale
The growing adoption of DevOps has helped digital organizations deliver software products and services faster to end users, all while maintaining high quality. At its core, DevOps not only decreases the lead time from when a software developer commits code to that code being run in production, but also transforms digital organizations to be customer-centric and a healthy place to work. The path to becoming a strong DevOps adopter is an investment that can’t be overlooked and can’t be solved by simply adding a continuous integration pipeline or moving to the cloud. When developing a plan for bringing DevOps to an organization, there are a number of considerations that need to be addressed and strategies that can make the transformation run more smoothly.
- First, knowing how to mitigate risks involved with a DevOps transformation can help identify common pain points that many organizations have already experienced.
- Second, organizations should consider embracing an Agile mindset, creating DevOps communities from within, and laying an initial foundation as ways to support this undertaking.
- Third, building a team of DevOps engineers and software developers with a wide range of skill sets and experiences in different tools, programming languages, and industries can reduce the possibility of groupthink in order to build the best strategy for your organization.
- Lastly, if working with an outside consultant, it’s crucial to pick one that is invested in teaching the team the hows and whys instead of just delivering a working solution so that the organization is primed to succeed after the engagement is completed.
Mitigating the risk of transformation
Continuing from my previous blog on DevOps during and after the COVID-19 pandemic, there are a number of benefits that come with a strong adoption of DevOps. To be fair, undergoing a transformation such as this certainly comes with risks that need to be addressed:
- Any changes to the deployment process could negatively impact end users;
- Security concerns with new technologies, many of which are open source;
- People unfamiliar with new tools causing unintended mistakes; and,
- Culture shift that isn’t supported by current team members.
I believe with the right approach to adopting DevOps many of these risks can be minimized, or eliminated.
Embracing Agile
It’s crucial for DevOps transformations to embrace Agile because the very nature of DevOps is working to deliver high quality software faster to end users, while empowering team members to make the best decisions, as opposed to following a strict process. This culture shift and way of working may strike some hesitation for current team members. It’s completely understandable for a team of operations engineers and administrators who have only heard scary stories of the many methodologies of agile, especially Scrum. On the DevOps teams I’ve worked with, I’ve found that the Kanban methodology worked well. Kanban allows the DevOps team to have the flexibility to work on items that need to be reprioritized quickly, and not be locked into work that has been rigidly defined in iterations, if following Scrum or XP.
Creating DevOps Communities Within the Organization:
Only starting with a small community instead of rolling out DevOps organization-wide will increase the effectiveness of adopting DevOps. Smaller communities can work faster as opposed to applying new DevOps guidelines across the entire organization. Starting this initiative with only the most motivated team members will result in a better investment.
Laying the Groundwork:
Organizations looking to adopt DevOps for the first time or need to tweak their current implementation should start by laying the groundwork. A few recommended practices to do this include:
- Looking at who can advocate for DevOps and start building a culture that fosters learning and taking smart risks. Once a small team of engaged DevOps engineers is established, start implementing some quick wins;
- Working on proofs of concept rather than diving in headfirst;
- Automating something such as executing acceptance or integration tests, chatbot or generated email to notify team of a deployment;
- Moving infrastructure configurations to source control; and,
- Creating internal sources of information to share within the organization.
To draw again from my personal experiences, one engineering team I was on was the first team to break away one of our many services from the monolith by implementing our new microservice pattern. While we worked in close collaboration with the DevOps team, we made the incorrect decision to use an important money-making service to our organization instead of a low to no end-user impact service. Of course, no matter which service we chose we were going to run into barriers. There wasn’t clear ownership of the CI/CD pipelines, no automated testing, and insufficient monitoring to name a few. As microservices were new to our team, these mistakes were amplified with the service that we chose. We experienced some data corruption and increased calls to our customer care team. Both of which could have been avoided if we instead laid the groundwork to first identify the pain points in our implementation then iterate to improve the process of our important services.
Take advantage of diverse skill sets and experience
The DevOps implementation from one organization often looks different from another. These factors include the size of the organization, industry, and existing software tools and methodologies. Like most software problems, there is normally more than one way of solving something and building with a diversity of experiences can help decide which solution works best for your team.
One example of the strength of building a diverse team is being able to utilize the vast knowledge of tools and experiences in picking the best tools for the job. Tools that reduce cognitive load and a DevOps engineer’s time are crucial to the success of your initiatives, and today’s technology environment leaves no shortage in the number of tools available. This high variety can be both a positive and potential burden for the team. Debates over which tool is best can project images of gladiators fighting in Ancient Rome in a winner-takes-all stakes. Although it may prove difficult, try to avoid falling into potentially endless debates on which tool versus another. A spirited debate is healthy however make sure that decisions are driven by how much more productive the team will be by using such a tool. Along with leveraging experience in different tools to make better decisions, try running proof of concepts to benchmark tools against each other.
DevOps transformations aren’t products, so don’t pick a “Dev Shop”
If your organization has decided to invest more in DevOps and are considering bringing in outside help, it’s important to pick a company that is looking to build a relationship with you rather than just delivering a solution at the end of the engagement. By working together continuously throughout the engagement, the consulting organization will be able to transfer knowledge and get feedback on the engagement’s progress thus far.
As an example of this philosophy working successfully, TribalScale engaged with a client to help build out their DevOps practices. This included advising on new technologies and DevOps patterns while simultaneously gaining a better understanding of their current systems in order to better manage their deployments of containerized applications. One of the patterns that we investigated was GitOps, which is the idea that the entire state of a running software system can be seen within a version control system. We built a proof of concept side by side with their DevOps engineers in a test environment that mirrored their production environment and demoed our POC to the project stakeholders each week. The benefits of working with the client team’s engineers were twofold:
- The client engineers were becoming as familiar with GitOps and tools as our TribalScale engineers, meaning once TribalScale left they knew exactly how to best follow this practice.
- The proof of concept was able to address concerns related to deep system knowledge only known by the client DevOps engineers, which would have likely been missed by TribalScale.
Demoing our progress weekly was a great opportunity to get regular feedback on our implementation to ensure we were hitting both technical and cultural goals of the engagement. By the end, both the client and TribalScale left feeling confident on what was delivered and in the future success of their DevOps team.
Key Takeaways
When your organization has decided to embrace DevOps, it’s important to focus on:
- Mitigating risks associated with transformation;
- Taking advantage of your organization’s diverse skill sets and experiences; and,
- Choosing an external team that seeks to work side-by-side with your organization, rather than only delivering something at the end of an engagement.
Although this may seem like a daunting undertaking (which it is!) remember that DevOps and the process of adopting it is a journey that can result in re-energized employees and a sharper organizational focus on delivering high value software solutions quickly to your customers.
Have questions about DevOps? Click here to speak to one of our experts.
Sam is an Agile Software Engineer who enjoys working with organizations on digital transformation and DevOps best practices. He also enjoys sitting on his couch like most people these days, binging the latest tech TV series.
TribalScale is a global innovation firm that helps enterprises adapt and thrive in the digital era. We transform teams and processes, build best-in-class digital products, and create disruptive startups. Learn more about us on our website. Connect with us on Twitter, LinkedIn & Facebook!
