As companies around the world have moved to all-remote work, many engineering teams are actually in a privileged position: Software engineering is something that can be done remotely. There are already examples of all-remote technical teams—though it is far from the norm, most engineers do know that all-remote collaboration is possible.

This makes engineers well-positioned to thrive even as many workplaces continue working remotely indefinitely. But it doesn’t mean that working remotely is the same as working in the same physical space as colleagues. Even engineering teams have to overcome certain barriers and adjust how they work to succeed with all-remote collaboration long-term.

Here are some of the challenges that DevOps engineers, particularly those who work with Kubernetes and cloud native apps, can encounter as they move to all-remote work — and how teams can solve those challenges. 

Learning curves

Centralized operations teams are often responsible for helping application developers learn how to use containers and Kubernetes, including helping them understand any changes to the organization’s infrastructure, training them on new tools or processes and answering questions when needed. As organizations move to containers and Kubernetes, the complexity of the application stacks increases and everyone finds themselves on a continual learning curve. 

When everyone is remote, however, it’s harder to share knowledge between operations and development teams as well as among individual developers. In the office, it’s easy to get a colleague to come over to and take a look at your machine. When everyone’s remote, it’s more challenging to get help when you need it or to proactively share knowledge about how systems work.

Coordinating communications

There’s no way around it: it’s harder to communicate with people who are not sharing your physical space. When teams move to all-remote work, they lose the ability to easily see whether or not a colleague is available, the ability to ask questions or throw ideas around during coffee breaks and all of the other informal avenues for communication and collaboration that take place in person. 

Solving communications for all-remote teams requires formalizing the informal. There has to be a formal way to share knowledge among team members, a clear way to know if your colleague is available for questions or assistance, and formalized avenues to replicate the informal collaboration that takes place over coffee or lunch in an office. 

Reducing friction

Companies move to DevOps and cloud native to improve development velocity. Doing so, whether it’s in an office or remote scenario, requires removing as many sources of friction in the application development process. Examples of friction might be:

• Overly complex systems
• Inability to self-serve
• Lack of visibility
• No single pane of glass view across systems
• Lack of activity logs to see who did what
• Inefficient testing or deployment procedures

Because of the communication challenges, friction in the development workflow can increase dramatically in an all-remote environment. 

Handling remote access

There’s also the technical problems that remote work can present, often around networking and VPNs. Particularly for enterprises with using a hybrid cloud approach, with some resources in data centers and others spread across one or multiple public clouds, keeping the VPN access secure as well as performant can be a challenge. Related to Kubernetes, developers need access to container logs, status, and consoles, but should not have access to hosts and clusters.

Solving the remote work challenges

There are two main ways that organizations can reduce friction for developers as we all work remotely. They are:

Improve self-service

The more that teams are able to give developers the ability to self-serve, the less friction they’ll experience. Taking the central infrastructure team out of the loop for tasks like provisioning a cluster is a best practice all the time, but becomes even more important when teams are working remotely and communication is more difficult. 

Self-service should also be applied to knowledge sharing. There should be a way for developers to access information without reaching out to a human for assistance. Doing this successfully involves both using tools to abstract away some of Kubernetes’ complexity to reduce the learning curve as well as creating more formal knowledge-sharing avenues in the organization. 

Centralize access management

Working remotely requires more attention to the company network, both around capacity management and secure access. Using a central platform that solves the remote access management problems lets organizations avoid the expense of a massive network upgrade while still ensuring that the network doesn’t become either a source of friction (due to low performance) or a security risk. 

Summary

Teams working remotely with Kubernetes need the right tools and processes in place to give developers the simplest way to self-serve while also allowing central teams the visibility and control they need to ensure everyone works inside the organization’s guardrails.

Nirmata’s unified Kubernetes management platform helps teams get the technical resources they need to reduce friction in the development process. Watch this video to learn more.