Challenges adopting the Azure DevOps SaaS offering in highly regulated industries - Connectivity
In highly regulated industries I see that some enterprises experience challenges when adopting the Software as a Service offering of Azure DevOps.
In highly regulated industries I see that some enterprises experience challenges when adopting the Software as a Service offering of Azure DevOps. The benefits of leveraging a SaaS product are many but in this blog series I would like to address the challenges, some of which are:
- Requires mindset change when leveraging a SaaS offering
- Enterprises don't understand how to meet their Compliance and Security requirements
- Network Connectivity / Line of Sight challenges which are typical when you don't own or run the SaaS services infrastructure.
In this blog post I want to cover the third bullet point - "Network Connectivity", typically enterprises do not have issues if they are leveraging all Azure DevOp's first party services i.e. Azure Boards, Azure Pipelines, Azure Test Plans etc.
The problems typically come in when they attempt to integrate with third party/Self-Hosted solutions which require inbound communication originating from the Azure DevOps service and these services are running on their private networks. Some examples are:
- Azure Pipelines can automatically create web hooks for Azure Pipeline Artefacts which support triggers, one example of this is a CI/PR trigger on a GitHub repo.
- Azure Pipelines can also query for the latest Artefact version, for example in the case of GitHub the current commit at the head of the ‘master’ branch.
- When storing Azure Pipeline YAML definition files in a GitHub repo, the Azure DevOps service requires connectivity to query the repository contents to discover & manage these YAML files.
- Azure Boards can integrate with GitHub (Enterprise Server & github.com), this would require connectivity to the GitHub instance.
Not all communication originates from the Azure DevOps Service, for example the self-hosted Azure Pipeline Agent requires only outbound traffic be allowed to the Azure DevOps Service. Below we can see diagram which shows some of the communication which is occurring when interacting with GitHub Enterprise Server which can be self-hosted with-in an enterprises on-premises network.
The challenge is typically related to connectivity required for integration between the Azure DevOps Service and GitHub Enterprise Server, you will also run into issues if you are looking to leverage Microsoft Hosted Agents and wish to connect to your local GitHub Enterprise Server to clone a repository for example.
In my experience highly regulated enterprises typically do not feel comfortable making changes to their firewalls to allow inbound traffic originating from Microsoft managed network where their Microsoft managed Azure DevOps Service is running.
We have multiple options for addressing these connectivity requirements, for example deploying Azure DevOps Server(formerly Team Foundation Server) the self-hosted version of the Azure DevOps SaaS offering with-in your enterprise network - This solution can be completely air-gapped and no traffic needs to enter or leave your network.
This may be an option for some enterprises but I see a lot of value in leveraging the SaaS offering as it means they are no longer responsible for the infrastructure and operations of the Azure DevOps "software".
Does this mean that Highly Regulated enterprises cannot adopt the SaaS offering of Azure DevOps, No of course not! The Azure DevOps team has built their service in such a way that that integrating with these private services is still possible, although in some cases this may impact the end users experience in small ways.
I will be covering some of these integration scenarios in more details in future blog posts.