Following some uptime issues with my Continuous Service, I have decided that it was time to give it some extra attention. In the upcoming weeks I will write about my lessons learned around building and running a low-cost Continuous Service on Windows Azure. This Day on #WindowsAzure is a personal attempt at capturing a snapshot of the daily community interest in and around Windows Azure.
Being a Windows Azure MVP, I’m quite interested in keeping up with the latest features and announcements made by Microsoft, but I must admit that it’s not an easy task. This is why I turned to the community for some help. I decided to subscribe to Twitter Streams for any tweet that contained a link and that had the words Windows Azure. Using the number of times that a link is shared, I started seeing trends and interests. I also decided to start tracking trending Windows Azure resources to in order to identify topics that generate interest the in community.
As I redesign This Day on #WindowsAzure, I will publish regular updates and try to get the service back online as soon as possible.
At this time, the service uses WACEL to interface with Windows Azure Storage in an attempt at generating the lowest cost of operation possible. The upcoming effort will also concentrate on the same goal. I will explore alternatives to help me work with large amounts of data.
I’m also pondering about hosting the solution on GitHub, but I have yet to figure out how to protect my application’s secrets from the repository.
Interested in my adventure? Feel free to share any insights or feedback as I will start the overhaul very soon.
The Original Design
Lessons Learned
- Lesson 1 – Continuous Services Require Continuous Attention
- Lesson 2 – Be Stateful
- Lesson 3 – Don’t be Afraid to Duplicate Data
Alexandre Brisebois ☁ 
Guessing that you have to use or build an abstraction to protect your application’s secrets from the repository.
LikeLike
Yes, that’s the direction I’m leaning towards, but even with this in place, it’s going to be hard to use continuous delivery because I still need some place to hide my secrets and to keep that place a secret. Any thoughts?
LikeLike
I presume you’re not happy that the connection strings are all over the place in various config files, files that you have to commit in a repository.
I would go for a custom config/settings file and a settings provider on top of it. Store all the secrets in one place — xml/json file, db — then configure your repository client to ignore the sensitive config file at checkin time, but allow a skeleton config to go through.
The settings provider can even include a fallback scenario to check in all known places for connection strings before using your config storage.
LikeLike
im not sure how that would work, as im planning on having my code public on GitHub.
I will write an update post tomorrow talking about the directions I’m taking. I’m probably going to mix and match services :)
LikeLike