Telecom workforce adjustments needed for devops
Just as workforce adjustments will be needed for telecom’s move to software-defined networks, changes will also need to take place in order for devops to be fully realized. In our article How telecom operators should approach devops we talked about some best practices for telecom companies switching to the devops model, and in 3 challenges facing telecom operators in shift to devops we detailed a few difficulties with that transition. We will now talk about some workforce changes that need to be made in order to get everyone on the same devops page.
Moving away from the silo
It is the premise of devops: getting developers and operations staff working together. This means breaking down the wall of the isolated silos they have, for so long, been working in. Those teams were almost always created as a response to some need or problem, and have always been better at resolving issues than making sure they do not occur in the first place. The earlier a company can get its developers and operations staff communicating with each other, the higher the rate of success it will have in deploying a successful devops environment.
It’s not about consolidating, it’s about flexibility
The prospect of “merging” departments might make some weary about the potential for job loss, but that isn’t what devops is all about. It is about flexibility and visibility; getting devs and ops to learn new skills so they can exchange their knowledge with someone who could benefit from it. Of course, some employees struggle with change more than others, so it should be taken on a case by case basis where and whether they fit within the organization’s new operating strategy.
A change of mindset: Agility is the key
Telecom operators should follow the agile principle of “everybody all together from early on,” to begin the process of moving to a more software-friendly work model. One major features of devops is continuous integration (CI) and continuous delivery and/or continuous deployment (CD). CI is about continuously and automatically running tests against a code branch. It means continually merging source code updates from all developers on a team into a shared mainline. Whereas CD automates the process of getting code into production after testing and approval. Teams produce software in short cycles in order to ensure that the software can be reliably released at any time. This means devops workers no longer focus on projects with definite start and end times, and should no longer be working on projects catered to their own, often incompatible, development styles.
Getting your pieces together
Of course, you still need structure within each devops teams, each individual having a defined role and set of responsibilities.
Puppet, a machine and software automation company designed for devops, provides some recommendations as to what members should be present and what roles they should take in a devops team:
- IT manager: Build trust with counterparts on other teams; create a climate of learning and continuous improvement; delegate authority to team members
- Dev manager: Build trust with Ops counterpart; bring Ops into the planning process early.
- Systems engineer: Automate the things that are painful.
- Quality engineer: Provide input into scale and performance; provide feedback on staging environments.
- Devs: Plan for deployment as you’re planning new features; get feedback from Ops and work with them on deployment process.
Software to the rescue
Change is tough on everyone. It is difficult for companies, which are required to determine and spend money on the correct resources for turning legacy equipment into agile, adaptable software. It is tough on workers who have been potentially doing their jobs for decades, and now must learn an entirely new system with a new set of colleagues. And the change to devops requires everyone in telecom to learn new skills, and use new tools.
Thankfully, software exists that help bridge the gap between developers and operations staff. HashiCorp’s Atlas, for example, provides visibility into infrastructure, including servers, containers, and virtual machines, in addition to configuration management and service discovery. Services like Chef help automate complex processes, and popular Docker provides a platform for applications to run within self-contained units that can be moved across platforms.
Table of Contents
