February 08, 2017 / by Ian David Rossi / In devops
DevOps Empowerment - Part 2
by Ian David Rossi
Almost an entire year ago (time flies!), I wrote an article on LinkedIn entitled “DevOps Empowerment or Augmentation?”. There, I expressed my views on how tech organizations can meet the challenge of getting the all-important skill set of cloud engineering into their teams by using a training and mentoring service like the one my firm, __aim__theory, offers. It’s a huge challenge today because finding engineers with all the desired skills that are actually available is like working a miracle.
I’m writing this follow-up to further refine this idea and approach as well as report on what I have discovered over the past year. In short, what I have found is the answer to the question which was the title of my original article: Both. When asking “DevOps empowerment or augmentation?”, the answer is, both.
The Dilemma
Organizations desperately need to put senior-level expertise to work on their most difficult challenges. At the same time, they also desperately need those same people to impart skills to their existing development and operations teams. With the move to microservices and continuous delivery, this sharing of skills and best practices becomes even more crucial. To compound this dilemma, recent government laws/restrictions are making it more difficult to procure talent outside of the U.S. The tech sector has relied heavily on foreign pools of talent.
If all that doesn’t make it hard enough: When saying that DevOps augmentation and empowerment are both needed, we have to remember that it’s not always the case that both are even possible. One organization may already have folks on their existing teams that can be mentored while others don’t; their only option is to augment their team. The downside of this is that it’s very hard to get from the aforementioned situation to a place where you can start to gain your own in-house DevOps expertise, which is the goal of many companies today.
You may be hoping to read on in this article and find a solution that I’m proposing to this industry-wide dilemma. Well, sorry to burst your bubble, but I’m not–there is no great solution at the moment. Trying to procure the skills to (a) automate your infrastructure, (b) complete your microservices project (c) continuously deliver you app, etc., etc. is just plain difficult. However, I can make some suggestions.
Outsourcing DevOps and Continuous Delivery Can Help
Yes, you can outsource your DevOps needs to my company, that’s why I’m writing this article. But of course there are many service providers to choose from. A strong case can be made for outsourcing in this area. Management knows that retention of tech talent is key to success and I totally agree with this. That’s why most companies I talk to today are primarily looking to hire, as W-2 employees, people that have the needed skills. And of course, a key driver is cost. But a macro view of this notion reveals a very important point: Not all tech talent can and should be valued the same way. When you ask the question, “What is our most valuable technical asset?” there is no doubt about the answer, your product (or product code). The tubes that your product gets delivered through also have great value, but they should never be valued as highly as your product. Of course, your delivery processes do provide great value by making your development teams agile and, therefore, innovative, resulting in a high-quality product.
A product delivery pipeline does not and should not change as frequently as your product. Not because you don’t want your pipeline to change–it should change as needed–but your product should be changing at a much higher frequency with new features and stability enhancements, all for user happiness and therefore success.
This is where the case for outsourcing your delivery pipeline/processes starts to become clear. Solid, ongoing efforts are not necessary to maintain a delivery pipeline. This mitigates the cost of a DevOps consulting firm. Clarifying even further the case for outsourcing DevOps and continuous delivery are the many tools and services now available. Several years ago when continuous delivery was being born out of continuous integration, the keys to this kingdom were held by tech wizards. Now, many of these techniques have been wrapped up into reusable open source projects or even services, like IaaS and PaaS.
Contracting a DevOps services company to create a _continuous delivery pipeline__ using the available tools and services could possibly be the fastest route to (finally) continuously testing and delivering your precious product properly–in a reliable and repeatable way. It is also the most cost-effective, since an expert-level team or consultant will have it implemented much more quickly than an existing development team that is trying to figure it out and simultaneously maintain their focus on feature development.
The Impact of Third-Party DevOps on Development Practice
Another aspect to consider here is the impact that a third-party DevOps consultant can have on the quality of your overall development outfit. DevOps is defined in different ways depending on (1) what organization you’re part of or (2) where your organization is in the DevOps maturity model. The essence of DevOps is collaboration and two-way feedback between developer and operations teams. But many times, people and/or teams in a DevOps function end up relegated to merely supporting developer processes, no matter what they are, even if there are improvements to be had in process and best practice. Instead of becoming a catalyst for continuous improvement, the DevOps function is reduced to a cloud operator/deployer. When developers are averse to feedback in this way (familiarity breeds contempt) this is ill-boding for any type of effort to continuously improve development and delivery processes.
When you introduce a third-party DevOps consultant, they will first evangelize best practices and process improvement from the beginning, with tools only fulfilling those processes and practices. Then suggestions and direction around improvement may be more easily accepted coming from a third-party. A good DevOps advocate will not mandate new processes or process changes, but will spend time to understand processes and teams. Many organizations today understand this cultural aspect of DevOps and how important it is, but struggle to find the right path. A third-party DevOps service provider may be just the ticket.
Conclusion
To summarize, my experiences over the past year helped me to answer the question, “DevOps augmentation or empowerment?” The answer is a resounding both. Core teams need to be augmented with the DevOps expertise that will get them where they need to go. This includes implementation and engineering, but it’s centered around practice and process. These collaborative experiences will then empower them to mind-shift appropriately, progress in the DevOps maturity model and carry on with the production of core business assets.
I’m starting a conversation once again. This is, of course, my perspective. Please weigh in with your thoughts, I would love to hear them.