.NET Software Architecture for Remote Workers

With more people going remote due to the current pandemic it’s brought up a lot of thoughts about how to make .NET work environments more friendly to remote workers. Traditionally, .NET has been tightly coupled with corporate infrastructure. There will be a lot of challenges with taking a team that is in-house to fully remote. The main goal of this article is to demonstrate through software architecture how to write code that is the least dependent upon using a VPN connection to corporate infrastructure. The main goal of this article is to demonstrate how to be less dependent upon a corporate VPN and internal infrastructure.

(I’m hoping to expand this post with samples and a video…)

Challenges Remote Workers Face

.NET software developers are working from home and it’s truly amazing. Being dependent upon a corporate VPN is cumbersome if the remote worker experiences network latency or intermittent Internet issues. Sometimes, it’s not even the remote worker’s Internet it could be the VPN is out.

Convert from TFS to Git

Traditional Team Foundation Server (TFS), an aging technology, is dependent upon a centralized server. Without an Internet connection or VPN access to the TFS server, the remote worker is unable to check-in or branch code. Git is a decentralized version control system that allows developers to branch and create commits without being connected to a server. Once an Internet connection becomes available to the remote worker they can then push and pull their changes. By switching from traditional TFS to Git-TFS or just Git, a team can be liberated from the constraints of a centralized source code server. There are many other benefits to switching to Git as well but that’s beyond the scope of this blog post.

Upgrade to .NET Core

.NET core performs far better than ASP.NET and should be upgraded if possible. Being that .NET Core is cross-platform it can run in Linux environments and this leads to more portability. .NET core applications can be published as self-contained and run anywhere without installing any additional libraries. This benefits remote teams because they can run it in different environments with fewer requirements. This can also be run in Docker.

Vagrant

Vagrant could also be used to spin up portable virtual machines in Hyper-V to create mock environments for infrastructure. This means it’s easy to distribute Active Directory, SQL, and DEV/TEST mock servers to developers to run locally.

Run MSSQL Server Locally in Docker

The majority of the work I’ve done in my career has been internal business applications that interface some databases. This typically requires a connection to the intranet through a VPN to gain access to the SQL server. Using Docker, there are currently Microsoft SQL Server images that can be pulled and ran locally. By using a local version of the SQL database a remote worker can continue working during Internet outages. This is much more efficient. The changes can be synced or checked into a SQL Project.

Database Seeding

If the environment permitted the use of Docker or a local SQL server then it’s only practical to have a database with data. Instead of cloning very large databases locally, it’s more efficient to write code that seeds that database. This can be done through C# or SQL scripts. This is very practical in the sense that you can create specific data used in individual test cases for development.

Unit Testing Architecture

This takes a significant amount of work to bring a team that isn’t familiar with unit testing up to speed. Unit testing architecture means the code must be fully decoupled to work effectively. Developers must really understand SOLID principles, decoupling, and how to split code apart for this to be effective. I’ve worked in Test Driven Development (TDD) environments before and this is second nature to me now. Unit testing allows for using mock data sources to run code. This is one less dependency upon a SQL server or other data source.

Bridging Internet Connections

If none of these can be done and a remote worker is still experiencing intermittent Internet issues another solution could be to use a bridged Internet connection between their cable modem and an LTE modem. In theory this would combine the two Internet sources to become one. This can be done with certain wireless routers. I’m going to attempt a blog post on this.

Wrap Up

Remote work will certainly change the landscape for software developers in the .NET sphere. It’s important that we as developers be aware of these pitfalls and strategies to overcome the challenges of remote work. In the long run, I believe Microsoft is very aware of this direction and is aggressively working towards maintaining a modern platform for developers.