This Day on #WindowsAzure Will be Back Shortly

February 18, 2014 — 5 Comments

seismic-events-earthquakes 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

This Day on WindowsAzure V1 

Lessons Learned

5 responses to This Day on #WindowsAzure Will be Back Shortly


    Guessing that you have to use or build an abstraction to protect your application’s secrets from the repository.



      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?



        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.


Trackbacks and Pingbacks:

  1. Reading Notes 2014-02-24 | Matricis - February 24, 2014

    […] This Day on WindowsAzure Will be Back Shortly – This post is announcing a really promising series about the re-editing of a cloud application. […]


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.