.NET, code, personal thoughts

  • Sitecore on Azure

    This is old news, but still worth sharing. I have shared my architecture with folks from The Azure Podcast for discussion and suggestions. It was a good review and worth listening to.  In case you're interested, Episode 32 has the discussion from minute 20:30. This architecture is now running 3 of our production sites, with another one on its way for international support with multiple regions. 

  • Interview is a Job

    An interview process should not end up in a situation of a cat in a bag. A friend of mine is going through an interview process, and I observed his line of thought and decision making. These are my observations along with what I think about technical part of interviewing process in particular. 

  • Windows Phone 8.1 – New Life for my Old Nokia 920

    If every future 0.1 update will be like this, I don’t dare to imagine what 1.0 update will be like. So far it was a very pleasant experience. In the past updates where more of a roller-coaster: you expected a lot, got some of that, and eventually found that there’s still a lot that was missing. For the first time that I have windows phone an update contained more than I have expected to see.

  • Azure Automation – Reducing Cost

    The idea behind this is extremely simple: to run a deployment machine in Azure that will be used to deploy updates to production. In my environment we get everything packaged on build server, but deployment has to happen in a controlled environment and from a manual kick-off. Deployments are not performed at night, hence compute time is wasted. To save 50% (at least) of compute time, VM has to be down.

    Plan for solution: get a single instance VM down during night and up at work hours. My initial thought was to use Azure Cloud Services auto-scale feature.


    - Defined under Cloud Service VM instance belongs to

    - Scaling is a property of Cloud Service


    - Requires Availability Set to be created and associated with VM instance

    - Requires at least 2 VM instances to run Auto-Scaling (deal breaker!)


    Fortunately, with the new release of Azure Automation, this can be done with Runbooks (a Runbook is a workflow that contains a PowerShell script, that can also call child Runbooks).


    - Doesn’t require multiple instances of VM (hence saving money)

    - Runs under the context of subscription, therefore has access to all resources


    - Scheduling is not as flexible as with Auto-Scaling and needs to be associated with a Runbook


    What I ended up doing was quick and dirty, but it does the job for now.

    1. Create an automation object (Virtual-Machines)


    2. Imported two Runbooks into automation (Start-AzureVMsOnSchedule and Stop-AzureMVsOnSchedule)


    Note that “import” is as simple as importing PS script wrapped in workflow name_of_workflow { #powershell script }

    3. Published imported runbooks


    4. Associated a schedule with each runbook


    5. Specified for each schedule to execute on a certain time daily (for Start runbook to run at 7AM, for Stop runbook to run at 7PM). BTW, parameters can be passed to individual runbooks, so that job (executed runbook) becomes a parameterized job. Also, resources can be used from all


    6. Once a job (schedule runbook) was executed, it’s logged (you can drill into details of each command – can see Bruce`s eyes light up)


    7. Job executed (spike at 7AM) and VM is up and running. Big Success *Borat accent* :)



    Note that when you edit Draft of your runbook, you can run (test) it before publishing. Also, you can import existing modules (Azure module is imported by default) using command toolbar at the bottom, add settings that can be shared by multiple runbooks, and insert Activity (powershell command) / Runbook / setting.


    Azure Automation is a great feature to leverage. Excited to see all of these things shaping up and making work easier, allowing to cut down costs at the same time.

  • Azure Pays Off

    A year ago I have started looking and evaluating cloud options. AWS and Azure were two options. I have decided to go with Azure for a couple of reasons that are still valid today (even more than a year ago)

  • Early Testing

    Early testing is amazing. I am not talking about TDD and developers testing their own creation. I am talking about testing performed by professional QAs with mindset to hack the heck of your system (code, server, deployment, you name it). The value of early testing vs. late testing in SDLC is very easy to show to those that deal with with software on a daily basis and live it everyday. But how do you translate it to the business? Visualize it. One is high level – show one approach vs another and start asking questions.