I agree that the post does not offer a generally applicable solution for the rotation of configuration. Unfortunately, it looks like in this moment of time there is no such solution available (at least not that I'm aware of).
On the other hand, the reason for writing this post was not to solve this issue but to help developers of Spring applications to use Hashicorp Vault for generating dynamic database credentials.
A solution for the more generally applicable, but also much more complex problem of configuration rotation without downtime would likely also solve the issue of the blog post. But as long as this solution is not available a more specific approach could at least address the challenges for some of us. The quite narrow scope of the blog post is bound to relational databases and HikariCP and I hope that I could point out that this still addresses a lot of use-cases (at least as long as SQL databases are not dead ;) ).
Additionally, I would like to increase the awareness that Spring itself is currently not automatically addressing the issue of rotating expiring secrets provided by Hashicorp Vault. Because Spring provides so many out-of-the-box production ready solutions for a lot of use-cases a lot of developers don’t know and even think about the edge cases which could still create pain.
I’m really interested in more details about the proxy-based approach you were writing about. If I’m able to build a more general solution with this approach I would be really happy to share this approach in another blog post.
Or do you know if it there already something planed in the Spring backlog to make this easier?
Traffic is of course nice but in the end not the goal, just a tool. Traffic by itself even increases costs.
In the end, you usually want to have customers, not traffic.
To be even more precise, you want HAPPY customers, because then they will remain customers and also bring new ones.
That means you still need good content and a good product more than a lot of traffic.
The reboot option is definitively not the right choice for all use cases but could be an option, depending on your constraints. At least it is still better then just not handling the expiration at all.
I think the follow-up post fits your needs better because no restart and so no downtime is needed. Hopefully I can finish it the next days.
I totally agree with your analysis. All the options only work if you have the right constraints and prerequisites.
Option three can be a valid use-case if you already have multiple (stateless) replications of your application running in parallel. For instance in a typical microservice architecture this is usually the case. A restart of one of the replications should then not impact the SLA.
In a real-life scenario it could of course be a bit more complicated. If all the replications where started at roughly the same time, the expiration could still result in an outage.
The next blog post has more restricted prerequisites (HikariCP as connection pool, which only supports JDBC), but solves the problem more gracefully. I hope I can finish this blog post soon.
Interesting analysis. I especially like your personal goals and the "Raise prices, even if nobody's buying". This is a really valuable insight. Thanks for sharing that.
I have one question:
Do you have a feeling about the market size you are in and how does this influence your planning?
I'm really looking forward to this. Is there I way I can be kept up to date about the progress or how I could potentially participate?