Experimenting with Remote Config Management
As someone who is always exploring new ways to tackle software development challenges, I often find myself working on projects outside of the standard work context. These experiments provide an excellent opportunity to explore new ideas and see how they pan out in a practical scenario. One such project that I’ve been working on recently is called Spox, a fun experiment designed to tackle the challenges of remote config management in an agile environment.
Why Spox? #
When working in an agile team, the need to adjust application configurations on-the-fly can often be a bottleneck. Even minor changes like adjusting an email sender due to company rebranding can involve creating a new task, making code changes, and deploying the application. With Spox, I wanted to experiment with a system that simplifies this process, making it more accessible for non-technical team members and reducing the dependency on developers for minor adjustments.
The Elixir Backend #
For the backend, I chose to use Elixir, a language known for its robustness, low latency, and concurrency. By using a combination of HTTP REST APIs (rw) and TCP interfaces (ro) for better latency, I was able to ensure optimal performance while maintaining high compatibility across a variety of use cases.
Handling Configuration with JSON Schema #
One of the main ideas I explored with Spox is the use of JSON schema to define the contract of the configuration schema. By defining this contract, developers can ensure that the configuration matches the required specifications, ensuring the smooth running of the application. To create an intuitive user interface for these configurations, I used the react-jsonschema-form library, enabling non-technical team members to modify the configuration as needed.
Versioning and Composability #
In addition to handling configurations, I also integrated versioning support into Spox. This means that every change to the configuration is versioned, allowing for easy rollback to previous states if necessary. I also experimented with composable configurations, defining configurations in a fine-grained manner and composing them into collections. This approach helps tackle common issues in microservice systems where multiple services may share subsets of uniform config items.
Future Steps #
Spox is an ongoing experiment and there are many more features I want to explore. For example, I’m planning to add features for A/B testing configurations and managing secret configs with encryption. I’m excited to see how these additions will further enhance the functionality and usability of the Spox project.
Conclusion #
Spox is a fun experiment that’s providing valuable insights into handling remote config management in an agile environment. It’s helping to explore new ways to make configuration management more streamlined and less of a bottleneck, leading to faster deployments and improved overall productivity. I’m looking forward to continuing to work on Spox and seeing how these ideas develop further. If you’re interested in seeing Spox in action, feel free to check out the project here and share your thoughts!