Devops isn’t easy. Neither is offshore. Trying to do both can be challenging because a culture of collaboration and new tool adoption is required. Nevertheless, many large global organizations have built devops capabilities across time zones based on follow-the-sun, 24/7 requirements and cost. So after just a few years of experience, some trends have emerged. Some devops processes may not be suited for offshore right away—or at all.
With devops there’s a lot of business culture aspects to consider. It’s not just about tooling. In some offshore organizations people might not think about the cultural aspects of devops, just the tools. Some organizations may just consider devops a nice-to-have and not a core competency as well. It’s difficult to get teams to work together and collaborate, and that’s not always something that offshore teams are considered in the best-of-breed category.
There could be time zone issues as well. The hastily arranged scrums with the development team and an operations team working together to solve site reliability problems often require impromptu availability. There could be problems that come up right away during the day on a shopping or product ordering site that need immediate attention. Additionally, it could be that familiarity with the needs of the other teams makes devops particularly successful is some organizations. It could be as basic as language skills or as complex as shared experiences during early phases of a very large project.
Sometimes, though, having people awake in different times zones could be an advantage for some websites. Some sites are creating a backlog of alert issues, and that could also be handled well and cost effectively offshore.
Some companies have learned through good and bad experiences that employees in a particular location may have stronger software development skills. If it’s a development-heavy shop, doing devops in a different location may pose issues. And language issues seem to crop up more often if the development shop is onshore-heavy.
Nevertheless, most enterprises are currently thinking that the major challenge is still actually culture and understanding of culture. Devops engineers are getting the reputation of really being “can do” and always saying yes to challenges. However, many offshore teams currently still have the reputation of having difficulty saying no. Leaders have to probe their understanding or rationale behind the yes, and see if the yes really is yes and do they actually have the capacity and competency to do what they said that they would do right away. Sometimes devops teams have to push back at the development teams, and they often appreciate it. In the end, application still want to deploy the cleanest code possible, even if it requires rework.
Having a team leader who interfaces well with the development team, the infrastructure team, the operations team, and the business groups is also a requirement. That requires a very strong on-premises person to do that. The very strong leaders often have deep Lean management and tech skills, which facilitates moving some of the work offshore, particularly when devops is done by a large group, and the work is split between locations.
Considerations for doing devops monitoring and automation offshore
One thing that always jumps out for possibly offshoring is 24/7 monitoring. The feasibility of this depends the organization’s devops model. If the devops model is that devops uses standard tools to help the development team, it doesn’t really matter when or where they work. If the devops team is configured so that an SRE is embedded in every development team, like in an agile approach, an organization can’t have part of the in a different time zone than everybody else.
In larger organizations where devops is monitoring, managing, and doing engineering and automation engineering, and its big enough to need a 24/7 shop, or even just some global presence, then some of the devops work can be done very effectively offshore. But, of course with devops, we really want to have the tooling and the technology take over monitoring as much as possible, ultimately obviating the need for an extensive offshore presence.
Most of the more mature devops shops are asking the engineers do a lot of automation. If the automation upgrades can wait overnight, it makes a lot of sense to go to a different time zone. Of course, the best devops shops are well aware of the best alerting practices and are constructing automated highly-available services that don’t need a lot of human intervention.
Applying global teams to devops where they are needed most
When it comes to offshore the best thing to do is to find out the enterprise’s greatest needs. Use a Lean template and methodology to find the biggest drivers of success. Typically, they are costs, leadership, management in business issues, containerization, testing, or monitoring and automation. It may be two or three of these as well.
The core premise with devops is that collaboration increases automation, velocity, and quality. Leadership that is taking devops offshore should know how to build a collaborative team in a global environment. The big benefit here is that the concepts that apply to managing a global team, also apply to building a successful devops team.
Some shops may have the CI servers set up, may have some of the tools and some of the practices set up, and may call it devops, but true maturity is not there. This is particularly true of very old school, monolithic organizations. The best way to get started is to set up a skills matrix to see where the knowledge gaps are, and where the competencies are for the organization. A good template to use includes the skills of the people who are in place and the capability of the tool chain. There are several other aspects of devops that can be measured, including the communications tools and the Lean processes. Then do a value chain mapping and work back from that on what you want the future state to look like. It’s no surprise that many enterprise are struggling in all those areas.
With an offshore group, the process changes can be challenging because the group has to consider the multiple business cultures, and because each does things differently. But most of the biggest cultural challenges are right here at home. Most of the time when large clients are trying to do a transformation, it’s an ops organization trying to become devops-capable, so leadership input really matters.
Summary
The bottom line is that if a shop needs devops, and it calculates that for 50 percent of the price it is willing to delay deployments by 24 hours, it is a good candidate for offshore devops. If an enterprise needs to deploy in an hour before close of business, it may have a problem with offshore. However, if it can build it during the day and deploy it overnight, offshore may be worth considering. That may be worth paying and engineer $50 per hour instead of $120 per hour.
Good things to consider offshoring are possibly automation, improvement, and deployment that can wait, and nonurgent alert work. It also may make sense to have devops near where the applications are being built if they are not in the US. Leaders need to decide what can wait and be done more cost-effectively. Architects are generally able to figure this out, and a principal consultant will definitely be able to figure what’s going to get done offshore on a good timetable and also be able to deploy staff onsite to do engineering real time and right away. Leadership has to have a collaborative model where the onsite group communicates with the offshore team, which is core to devops anyhow.