As developers or anyone involved with deploying applications, we're all aware of configuration settings. Settings allow apps to change their behavior without changing the application code. The old standby example is database connection strings. You can easily change which server and database the application connects to just by editing the config file. Once upon a time, in the Windows world, you'd put the connection string in an ini file. That's ini for initialization.

Then, we started using XML config files, and more recently, JSON app setting files. The same config file principle applies no matter what operating system or programming language you work with. And for the most part, this has worked well in the single app on-premise environment. However, looking just at the connection string example, there are a couple of aspects that aren't ideal.

Firstly, the password is there in plain text. This will give anyone with access to the config file access to the database with the application login, So that's access with all the privilege of the application and consequently, no way of tracking that any changes made were not made by the app or that sensitive information has been unlawfully taken. Secondly, and not immediately obvious, is that cloud-based applications often run as multiple instances, widely distributed on virtual machines or containers, possibly spread over multiple regions.

Supporting this scenario with a traditional configuration setup would require multiple config files. This would fly in the face of the one version of the truth best practice that is make maintenance a headache and prone to errors. These issues, along with a myriad of other challenges posed by cloud deployment, led Azure to introduce the App Configuration Service. The App Configuration Service provides centralized and secure configuration management that offers many more features than just storing connection strings. At the moment, Azure App Configuration has good SDK support for .Net Core and Java's Spring framework.