Welcome to Opinionated Pattern Picking (OPP), a monthly session we run at Arinco to foster an environment of discussion and learning for our application developers and anyone else interested. Each month the team discusses a topic and attempts to elect a “best default” pattern for developers to use on future projects.
View the rest of the blog series here.
What solution are we designing for?
Instead of looking to build an enterprise solution, we take the approach of starting with a straightforward solution: we create a solution that involves an API and some data that can be retrieved either in response to an end-user request or by a daemon service running in the background. This simple approach is still quite detailed, providing us with enough substance to delve into before adding further complexity.
October – Local App Settings
This month’s topic was app settings for local development specifically. Primarily the discussions on the day were about three different methods of managing local app settings:
- Local appsettings.json
- Azure App Configuration
- A hybrid approach
The primary goal of the discussion was to determine the most suitable configuration method for local development. The selection criteria for the selected pattern would be:
- Simple
- Secure
- Scalable
Pattern Picking
Local App Settings: Balancing Simplicity and Security
To begin, we discussed local app settings with the conversation focusing on the combination of app settings.json and .NET secrets for our development environments. We discussed how this dual approach provides an effective way to separate standard configuration from sensitive information, with .NET secrets offering a secure location for storing confidential values during local development. The team liked this solution as it aligns well with our need to keep certain values protected while maintaining easy access to common configuration items, therefore meeting our two selection criteria: simple and secure.
During our discussion, we identified several advantages of local settings. The immediate visibility and accessibility of configuration values with the ease to modify settings directly in files without requiring Azure App Service configuration access. The team particularly valued how this approach supports offline development and quick iterations. Additionally, using .Net secrets made it easier to maintain proper security boundaries, which can assist in not accidently adding secrets to an online repository.
Throughout our discussion of this approach the team consistently noted a concern around accidentally committing secrets to Git. Additionally, we found that sharing settings between team members presents ongoing challenges – without proper repository management, updates often go uncommunicated, leading to broken development environments. The scalability limitations became obvious as we discussed how local settings become unwieldy when dealing with more than roughly 20 configurations. These limitations sparked a debate about the appropriate project scale for continuing with local settings before considering more scalable solutions, with this options meeting two selection criteria: simple and secure.
Azure App Configuration: Cloud-Native Settings Management
Next up was our discussion of Azure App Configuration and its integration points, particularly focusing on its relationship with Key Vault. We discussed how user permissions work with the services, noting that our consuming service will need permissions for both App Configuration and Key Vault access, rather than App Configuration managing permissions as a middleman.
There are several key points that surfaced. The ability to share settings across multiple applications, additionally the tagging and labelling capabilities that enable environment-specific configurations. We discussed how the centralised management of settings streamlines updates, with the ability to modify configurations without redeploying applications standing out as a key benefit. The versioning capabilities also provided an appealing safety net for configuration management. While these benefits are a great addition to a project, it is worth noting that for the discussion topic of ‘local appsettings’ it isn’t necessarily relevant, it is however, worth considering what impact introducing it into the solution would have. As any relevant or irrelevant additions to an option will still have an overall impact and should be considered.
The discussion revealed several practical challenges we need to consider:
- Internet connectivity requirements
- Security access management can complicate local development scenarios.
- When changes are pushed, they affect all users simultaneously, removing the flexibility of local overrides
The team also raised concerns about how this approach might impact microservice autonomy and whether the solution could be overkill for simpler projects. These considerations led us to debate the appropriate scale at which Azure App Configuration becomes the right choice for the project. Again, this option met two of our selection criteria, secure and scalable.
Opiniated Pattern Picked
Having noted that both patterns matched two thirds of our selection criteria, we tried to design a hybrid approach to local configuration management, discussing how we might effectively combine local app settings with Azure App Configuration. We discussed starting projects with local settings files for development and basic configuration, then strategically introducing Azure App Configuration as projects grow or require more sophisticated configuration management.
The discussion revealed several strategic advantages to this flexible approach. We found it particularly valuable for scenarios where developers need to work offline or haven’t yet received cloud access, while still maintaining the ability to leverage cloud-based configuration for shared or sensitive settings. The team liked how this approach allowed us to evolve our configuration strategy alongside our application’s complexity, using local settings for project-specific configurations while leveraging Azure App Configuration for shared resources and cross-application settings.
Our exploration highlighted some practical considerations for implementation. We debated the threshold for when to transition certain configurations to Azure App Configuration, acknowledging that this decision point isn’t always clear-cut.
The team discussed how maintaining two configuration sources requires careful planning to avoid confusion about where specific settings should reside. However, we found this hybrid model particularly compelling for its ability to support both rapid local development and robust production configurations, especially in scenarios where we need to start development before cloud infrastructure is available or when working with clients who might need different levels of configuration complexity.
