Build 2016 Keynote day 1

Here’s a great Build 2016 day 1 and the keynote – nicely curated David Burela !

Burela's house-o-blog


Day 1 (today) will be about Win 10 and devices, like HoloLens, Xbox, and ‘conversations as a platform’ (NUI) and AI/bots
Day 2 will be about Azure, IoT, data platform with @scottgu. And Qi Lu will talk about O365 as a platform, Office/MS Graph

More below.

View original post 941 more words


Awarded Microsoft Azure MVP – 2016

I am delighted to share with you that I have been awarded the 2016 Microsoft® MVP Award for Microsoft Azure.

The Microsoft Most Valuable Professional (MVP) Award is our way of saying thank you to exceptional, independent community leaders who share their passion, technical expertise, and real-world knowledge of Microsoft products with others. It is part of Microsoft’s commitment to supporting and enriching technical communities. Even before the rises of the Internet and social media, people have come together to willingly offer their ideas and best practices in technical communities.

I feel very privileged to have received this award. Being recognized for what I have done this past year for the cloud computing community means so much to me.

I’d like to say a big “thank you” to all my blog readers and to everyone in the community especially here in Ireland for their support and collaboration over the past year.

Receiving the MVP Award inspires me even more to give back and pay it forward, to keep learning and sharing my knowledge, to help grow the Azure community both here in Ireland and around the world.

It also gives me NDA access to upcoming Microsoft products and technologies allowing me to help shape the technology and to network directly with the product teams and other MVP’s around the globe.

Congratulations to all new and renewed MVP colleagues – I’m looking forward to working with you and to some great community events in 2016.

Learn more about the MVP program here:



I’ve won 2 free tickets to the Web Summit 2016 for my contributions to open source projects

Well Christmas arrived early for me this year ! recently I won 2 free tickets to the Web Summit 2016 in recognition of my open source contributions on GitHub.  I’m really looking forward to attending next year, here are the vital statistics – 21 summits , 1000 speakers and 41,000 attendees the mind boggles !


It’s a real shame that we couldn’t manage to hold on to this jewel of a conference in Dublin, it really helps to put Ireland on the world stage in the tech community. Hat’s off to Paddy Cosgrave for growing the conference from 400 odd attendees in 2010 to these new these lofty new heights.

I’m really looking forward to Lisbon, thanks again to the kind folks at @WebSummitHQ for the free tickets !

For those of you less fortunate  you can buy tickets here


Guiding Principles for an Evolutionary Architecture



Back in the dark days of waterfall projects we invested heavily in big upfront architecture and design. Systems were well thought out and documented within an inch of their lives. All this happened before anyone cuts a single line of code. There was little or no room to change once things were in flight. Twelve months later we’d go through a horrendous regression test cycle and finally release a product only to find out that our clients needs had evolved and we’d ended up building something that nobody wanted, but hey at least it was well architected!

Thankfully, those days are gone my friend and big upfront design has no place in Agile. With Agile, teams still complete architectural work, but it’s done very differently. Instead of a big up-front design where decisions are made about the architectural needs for an entire system, Agile teams take an incremental and evolutionary approach. However, designing, building, and maintaining a robust architecture doesn’t come for free. You need to maintain focus on architecture throughout the entire process and stick to some guiding principles.

Evolutionary architecture gives us most of the benefits of enterprise architecture without the problems caused by trying to accurately predict the future. Here are a number of useful techniques and principles that will help you to maintain a clean architecture through the lifetime of your product.

“The best architectures, requirements, and designs emerge from self-organizing teams.”  Agile Manefesto Principles

Last responsible moment

The last responsible moment isn’t about encouraging procrastination, it is saying that you should delay decisions as long as you can but no longer. The longer you can afford to wait to make a design decision the more  information you’ll have on hand and the better placed you are to get it right. Decisions made too early in a project are hugely risky. These decisions often result in work that has to be thrown away. Even worse, those early decisions can have crippling and unavoidable consequences for the future of the project.

Early in a project you should make as few binding decisions as you can get away with. Start small with a few critical stories but aim for working end to end software. Establish a skeleton architecture or ‘steel thread’ with an end to end data flow and establish your test approach.The driving technical requirements for a system should be identified early to ensure they are properly handled in subsequent designs and implementations. Choices like the programming language and the database technology need to be made at the start of a project but deciding on the right level of services decomposition will emerge later on. The last responsible moment makes sense for decisions which are costly to reverse and it will keep you from over architecting and designing for functionality that may never arise.

Establish lightweight documentation

The Agile Manifesto prefers “working software over comprehensive documentation”. This doesn’t mean that you can ditch documentation entirely.Technical documentation is valuable  but it needs to be kept at the right level if it has any chance of being kept up to date and surviving the duration of your project. Documentation becomes much more valuable  when it takes on a collaboration nature. Wikis are a great way to socialise designs and to communicate both within your team and externally. The act of writing or sketching out a diagram helps you to think something through properly and increases your own understanding. You  should focus on keeping things lightweight and relevant – make sure there is value in what you are documenting and make sure there is an audience that finds it useful. In general, system diagrams,  design decisions , operational instructions and requirements should be documented to help you team understand what they are building and to help the others that come along after them.

Establish continuous integration and automation right from the get-go

Nothing builds or destroys agility more than a team’s commitment to continuous integration. Automated tests gives you a safety net that lets you refactor and change your code quickly knowing that you haven’t broken anything.

In order to  evolve an architecture over time you need to maintain and grow all your automated tests –  unit , integration, contract and end to end tests. Don’t get hung up on code coverage metrics but pay attention to tests that fail frequently, these will point you to the problem area’s in your code base that need your attention.

Without adequate automated tests your architecture won’t evolve freely. Making wholesale changes and restructuring existing code will becomes too risky and you’ll end up in a cycle of maintaining and extending poor code that compromises your architecture.

End to end tests are the slowest to run and the most brittle to maintain. When choosing the scenarios for an end to end test you should focus on the key workflows through your software. As the system grows don’t be afraid to throw away some of these tests and replace them with more valuable scenario’s. Your tests like you architecture need to evolve and sometimes that means they need to be deleted.

Simple code and simple designs are always best

Writing code is easy, writing code that is easy for others to understand is not so simple. Striving for simplicity when building complex systems should always be front of mind. Don’t let team members work alone, pair programming and code reviews help to make code more understandable and readable. When it comes to design, the easier things are to understand the better. Simple code and simple designs takes less time to understand, have fewer bugs, and are easier to modify. Beware of shiney new frameworks and abstractions for abstractions sake!

Remember Conways laws 

Many years ago, Melvin Conway wrote a paper that proposed that the way an organization is structured would have a strong impact on how a system is created. He wrote

“Any organization that designs a system (defined more broadly here than just information systems) will inevitably produce a design whose structure is a copy of the organization’s communication structure.”

It is all too easy to focus purely on the technical challenges when architecting a system  but you need to think about your organisation structure and assign the right work to the right teams. Having a single team work on and own an individual service is far better than having joint ownership across teams. Coordination and communication across teams is hard and all too often people find ways to avoid this altogether and you end up with large hard to maintain codebases with duplicate functionality added per team.

Finally, a word on robustness

Postels Law also known as the robustness principle is a great guideline when it comes to designing message contracts

“Be conservative in what you send, be liberal in what you accept”

As soon as you publish an API either internally or externally other systems will start to rely on it. Once it is the wild your API’s become much harder to change. When it comes to exposing data you should expose the bare minimum and no more and you should version all message contracts. Conversely when consuming an API its best to ignore parts of the message you aren’t interested in, you don’t care if these change over time.

Evolutionary architecture works but only when you focus and continually works through these guiding principles.

Hope this helps

Blue-Green Deployments with Azure Web Apps

Blue-green deployment is a technique that reduces the downtime and risk of releasing new versions of an application by running two identical production environments called blue and green. At any time, only one of these environments is live, with the live environment serving all production traffic. For example, blue is currently live and green is idle. To release a new version, you deploy and test in the green environment . When you testing is completed you switch the routing so all incoming requests now go to green instead of blue. Green is now live, and blue is idle, now wash, rinse and repeat..

There are many benefits to adopting this technique – you can release to production as often as you like with zero-downtime and you can easily rollback your changes and swap from green to blue if needs be.

Azure Web Apps provides an out-of-the box solution for blue-green deployments through the use of deployment slots. When you provision a web application you can create up to 4 additional deployment slots. Deployment slots are actual live web apps with their own host names, you can push code to individual deployment slots and the content and configurations elements can be swapped through a simple API call. Azure manages all the traffic redirection when you swap your blue-green slots and guarantees that no requests are dropped during the swap.

Azure Resource Manager allows you define all the resources that make up your deployment environment in a single template file. Once defined, you can deploy, monitor and manage these resources as one atomic group.

By combining web apps, deployment slots and  azure resource manager it’s pretty easy to build  a continuous blue green deployment pipeline.

I’ve published a set of scripts and templates to enable blue-green deployments for a WebAPI backed by a azure SQL database, you can grab all the code here


Create a new environment

Our stack consists of Web App and a SQL Azure database. these are defined in the file webapi-deploy.json.  All service specific settings are externalised and defined in a seperate paramters file. To create a brand new stack  invoke the New-AzureResourceGroupDeployment 


 "$schema": "",
 "contentVersion": "",
 "parameters": {
 "siteName": {
 "value": "CustomerService"
 "hostingPlanName": {
 "value": "NewServiceAppPlan"
 "siteLocation": {
 "value": "North Europe"
 "sku": {
 "value": "Standard"
 "serverName": {
 "value": "mydatabaseserver"
 "serverLocation": {
 "value": "North Europe"
 "administratorLogin": {
 "value": "dbuser"
 "administratorLoginPassword": {
 "value": "your-password"
 "databaseName": {
 "value": "CustomerDatabase"

Once the web app has been created you can add a second deployment slot

function Add-StagingSlot([string]$sitename,[string]$location)
New-AzureWebsite -Name $sitename -Location $location -Slot "Stage"

Deploy to a staging slot and hot swap

The Publish-Azure-Website cmdlet lets you deploy a .NET webdeploy package to a named deployment slot on  you running Web App.  When you are ready to hot swap the blue and green enviornments call Switch-AzureWebsiteSlot

function Publish-Website([string]$name, [string]$package)
Switch-AzureMode AzureServiceManagement
Write-Host "publishing " + $name + "..."
Publish-AzureWebsiteProject -Name $name -Package $package

function Stage-Website([string]$name, [string]$package)
Switch-AzureMode AzureServiceManagement
Write-Host "publishing " + $name + "..."
Publish-AzureWebsiteProject -Name $name -Package $package -Slot "Stage"

function Swap-Website([string]$name)
Switch-AzureWebsiteSlot –Name $name -Force

A word on database changes

Handling database changes is the most complex part of a  blue-green deployment. the simplest approach is to have your blue and green applications share the same database. You need to ensure that all schema changes are backward compatible with both versions of the running application. The simplest way to run the database upgrade scripts is to bootstrap it to the Application_Start method in your WebApi project. FluentMigrator is a great open source tool which allows you to define your database schema changes in .NET code.

That’s, pretty much it, one last point about resource groups. When you are done with your stack and you’d like to tear everything down you can delete all the resources in your resource group by calling Remove-AzureResourceGroup

Useful Reading

Martin Fowler on Blue Green Deployments

Quickstart Resource Manager Templates

hope this helps !

Build a Hybrid Application with the Ionic Framework and Microsoft Azure Mobile Services


In this post I’ll show you how to create a hybrid mobile application using the open source ionic framework and how to integrate the application securely to a Microsoft Azure Mobile Services backend. By integrating  with azure mobile service you get to connect to reliable cloud storage via a simple JavaScript SDK.

I’ve made the complete source code is available on GitHub  – feel free to fork the code or use it however you like.

Ionic Framework

Ionic is an open source JavaScript and CSS framework for building cross-platform HTML5 mobile applications. It’s built with Cordova and AngularJS and it comes with a nifty command life interface that lets you build  IOS and Android apps. My experience working with ionic has been really good. It is very easy to get started with ionic and there is a strong community behind with about 200 contributors to the codebase. Work is well underway to remove the dependency on AngularJS which means you’ll be able to plug the inoic framework into your JavaScript framework of choice in the near future.

Microsoft Azure Mobile Services

Microsoft Azure Mobile Services is a mobile backend as a service (MBaaS) offering from Microsoft. Almost every mobile application needs to store some data, deal with push notifications, service monitoring and authentication. With microsoft azure mobile services you get all of this as a “platform as a service” offering. You don’t need to spin up a single server to go live with a mobile app, simply provision yourself a mobile services backend in azure and  and you have access to all of these features along with a a fully programmable node.js or .NET backend.

The todo appapp I’ll take you through the key steps and code needed to build a simple todo mobile app. Users will authenticate with a google plus account. Once logged in they’ll be able to create new tasks and maintain a list of outstanding tasks.

Creating the ionic app

First up install apache cordova and the ionic framework via npm

npm install -g ionic
$ npm install -g cordova

Next,  create a new ionic application using one of the sidemenu starter template

$ ionic start Azure-Ionic-App sidemenu

That’s it! if you run the command “ionic serve” a browser will open running your application.The application we are building consists three simple views and controllers – login, add task, and  view all tasks.

Implementing Google Authentication

Firstly, create a new azure mobile service  via the azure portal. If you don’t have an account you can sign up for a free trial here. You’ll get more than enough credits with a trial account to develop  and test an application.

Once your mobile service is provisioned take a note of the mobile service url  on the dashboard page this is your unique the API endpoint for your mobile app.

create mobile back end

The process of how to register your app for a google login is already well documented here . You’ll need to login to the google developer console, create a new web project and register for “Google +API” OAuth authentication then in the credentials tab, enter the authorization redirect URL for you application. This will be “your-mobile-services-url/login/google” , in my case its “”google console

Now to associate your google application with the mobile service backend. Go back to the azure portal and enter the google client id and secret on the identity tab..

google register

To integrate a google login into your ionic application you’ll need to bundle the mobile services JavaScript client library with your application and add the following AngularJS factory class which returns a mobile service client object .

angular.module('azure', [])
  .factory('client', [function () {
    var client = new WindowsAzure.MobileServiceClient(
    return client;

Using the client object we can take care of the OAuth flow by simply calling client.Login(“google”);

//the login controller calls client.login("google") to perform the oAuth dance
angular.module('azure', [])
angular.module('app.controllers', ['azure'])
.controller('LoginCtrl', function(client,$scope, $state) {
    $scope.login = function() {
      client.login("google").then(function succes(data){
        console.log('logged in succesfully..')
      }, function(error){

        //login failed.

The OAuth flow happens in a separate browser window.You must install the Cordova InAppBrowser plugin from to be able to show the login popup on a mobile device. Run the following command to install the plugin locally

$ ionic plugin add cordova-plugin-inappbrowser

then add the plugin to your config.xml file to bundle it as part of the ionic build process.

  <feature name="InAppBrowser">
    <param name="ios-package" value="CDVInAppBrowser"/>
    <param name="android-package" value="org.apache.cordova.inappbrowser.InAppBrowser"/>

Once logged in, a user context is set on the client object. You can access this at any time by simply injecting the client factory class we created earlier into the relevant controller; client.currentUser.userId

We’ll store the unique userId property as part of each todo item in the data store to make the solution multi-tenanted and to ensure you only get to see your own todo list tasks, I know I for one don’t want to complete other peoples tasks!

Storing Data in Azure Mobile Services

When you provisioned a mobile services on azure  you also provisioned a SQL Server backend but chances are you won’t treat the backend like a relational database. When you provision a new table in the database it gets allocated a dynamic schema by default ( very cool but you can turn this off if you like). As you make API calls to store data in a table new columns are generated based on the properties of the JSON object you send to the API.

Go to the data tab in mobile services and a create a table called “Task” to store the todo items. Set the table permissions for insert, update,delete and read operations to “authenticated users”.  You can now read and write data to this table via the mobile services client factory class we created earlier.

Its worth highlighting that the backend API that writes to the database table is fully programmable and you can write node.js scriptlets to validate and transform your data before it gets written to the data store. If you’d prefer to write your data to a MongoDB or DocumentDB data store its pretty easy to swap out the database completely  – more information here

For the purposes of this post we won’t create any server side scriptlets, we’ll let the data go straight through to the tasks table.To keep the ionic application more modular I created a separate AngularJS factory to class to connect to the azure backend.

There’s a few things worth highlighting in the code

  • when saving data in the addTask() function I tack on a userId property.
  • when reading data in the getAll() function I create a filter expression to filter to return the tasks for the logged in user.
angular.module('', ['azure'])
  .factory('azureAPI', ['client' ,'$q', '$rootScope', function (client, $q, $rootScope) {

    return {
      getAll: function () {
        var deferred = $q.defer();

        var userId = client.currentUser.userId;

        //filter by user id
        client.getTable('Task').&amp;amp;lt;strong&amp;amp;gt;where({userId:userId})&amp;amp;lt;/strong&amp;amp;gt;.read().then(function () {
          deferred.resolve.apply(this, arguments);
        }, function () {
          deferred.reject.apply(this, arguments);

        return deferred.promise;

      addTask: function (task) {

        &amp;amp;lt;strong&amp;amp;gt;task.userId = client.currentUser.userId;&amp;amp;lt;/strong&amp;amp;gt;
        var deferred = $q.defer();

        client.getTable('Task').insert(task).then(function (data) {
          deferred.resolve.apply(this, arguments);
        }, function (error) {
          deferred.reject.apply(this, arguments);
        return deferred.promise;

      updateTask: function (task) {
        var deferred = $q.defer();
        task.userId = client.currentUser.userId;

        client.getTable('Task').update(task).then(function (data) {
          deferred.resolve.apply(this, arguments);
        }, function (error) {
          deferred.reject.apply(this, arguments);
        return deferred.promise;


That’s it. We’ve now hooked up google authentication and our mobile is storing data against a microsoft azure mobile services backend.

All the code is available here :

Hope this helps