Inviting Microsoft Account users to your Azure AD-secured VSTS tenant


I’ve done a lot of external invite management for VSTS after the last few years, and generally without fail we’ll have issues getting everyone on-boarded easily. This blog post is a reference for me (and I guess you too) to understand the invite process and document the experience the invited user has.

There are two sections to this blog post:

1. Admin instructions to invite users.

2. Invited user instructions.

Select whichever one applies to you.

The starting point for this post is that external user hasn’t yet been invited to your Azure AD tenant. The user doing in the inviting is also not an Azure AD Global Admin, but I has rights in an Azure tenant.

The Invite to Azure AD

Log into an Azure subscription using your Azure AD account and select Subscriptions. Ideally this shouldn’t be a production tenant!

Select Subscription

I am going to start by…

View original post 721 more words

Azure Functions: Build an ecommerce processor using Braintree’s API


In this blog I am continuing with my series covering useful scenarios for using Azure Functions – today I’m going to cover how you can process payments by using Functions with Braintree’s payment gateway services.

I’m not going to go into the details of setting up and configuring your Braintree account, but what I will say is the model you should be applying to make this scenario work is one where you Function will play the Server role as documented in Braintree’s configuration guide.

My sample below is pretty basic, and for the Function to be truly useful (and secure) to use you will need to consider a few things:

  1. Calculate total monetary amount to charge elsewhere and pass to the Function as an argument (my preference is via a message on a Service Bus Queue or Topic). Don’t do the calculation here – make the Function do precisely…

View original post 398 more words

Azure Functions: Send email using SendGrid


Prior to Azure Functions announcing their General Availability (GA) I had previously used SendGrid as an output binding in order to send email messages.

Since GA, however, the ability to use SendGrid remains undocumented (I assume to give the Functions team time to test and document the binding properly) and the old approach I was using no longer seems valid.

As I needed to use this feature I spent some time digging into getting this working with the GA release of Azure Functions (version ~1). Thankfully as Functions is an abstraction over WebJobs I had plenty of information on how to do it right now thanks to the WebJobs documentation and extensibility :).

Here’s how you can get this working too:

1. Register your SendGrid API key in Application Settings: you must utilise the documented approach of setting your API key in an App Setting called “AzureWebJobsSendGridApiKey”. Without this your…

View original post 151 more words

Azure Functions: Access KeyVault Secrets with a Cert-secured Service Principal


Azure Functions is one of those services in Azure that is seeing a massive amount of uptake. People are using it for so many things, some of which require access to sensitive information at runtime.

At time of writing this post there is a pending Feature Request for Functions to support storing configuration items in Azure KeyVault. If you can’t wait for that Feature to drop here’s how you can achieve this today.

Step 1: Create a KeyVault and Register Secrets

I’m not going to step through doing this in detail as the documentation for KeyVault is pretty good, especially for adding Secrets or Keys. For our purposes we are going to store a password in a Secret in KeyVault and have the most recent version of it be available from this URI:

Step 2: Setup a Cert-secured Service Principal in Azure AD

a. Generate a self-signed…

View original post 423 more words

Continuous Deployment of Windows Services using VSTS


I have to admit writing this post feels a bit “old skool”. Prior to the last week I can’t remember the last time I had to break out a Windows Service to solve anything. Regardless, for one cloud-based IaaS project I’m working on I needed a simple worker-type solution that was private and could post data to a private REST API hosted on the other end of an Azure VNet Peer.

While I could have solved this problem any number of ways I plumped for Windows Service primarily because it will be familiar to developers and administrators at the organisation I’m working with, but I figured if I’m going to have to deploy onto VMs I’m sure not deploying in an old-fashioned way! Luckily we’re already running in Azure and hosting on VSTS so I have access to all the tools I need!

Getting Setup

The setup for this process…

View original post 426 more words

Deploying to Azure VMs using VSTS Release Management


I am going to subtitle this post “the missing manual” because I spent quite a bit of time troubleshoothing how this should all work.

Microsoft provides a bunch of useful information how to deploy from Visual Studio Team Services (VSTS) to different targets, including Azure Virtual Machines.

In an ideal world I wouldn’t be using VMs at all, but for my current particular use case I have to use VMs so the above (linked) approach worked.

The approach sounds good but I ran into a few sharp edges that I thought I would document here (and hopefully the source documentation will be updated to reflect this in due course).

Preparing deployment targets

Azure FQDNs

I thought I’d do the right thing by configuring the Azure IP of my hosts to have a full FQDN rather than just an IP address.

As I found out this is not a good…

View original post 530 more words

Migrating resources from AWS to Microsoft Azure

Kloud receives a lot of communications in relation to the work we do and the content we publish on our blog. My colleague Hugh Badini recently published a blog about Azure deployment models from which we received the following legitimate follow up question…

So, Murali, thanks for letting us know you’d like to know more about this… consider this blog a starting point :).

Firstly though…

this topic (inter-cloud migrations), as you might guess, isn’t easily captured in a single blog post, nor, realistically in a series, so what I’m going to do here is provide some basics to consider. I may not answer your specific scenario but hopefully provide some guidance on approach.

Every cloud has a silver lining

The good news is that if you’re already operating in a cloud environment then you have likely had to deal with many of the fundamental differences between traditional application hosting and architecture and that of cloud platforms.

You will have dealt with how you ensure availability of your application(s) across outages; dealing with spikes in traffic via use of elastic compute resources; and will have come to recognise that is many ways, Infrastructure-as-a-Service (IaaS) in the cloud has many similarities to the way you’ve always done things on-prem (such as backups).

Clearly you have less of a challenge in approaching a move to another cloud provider.

Where to start

When we talk about moving from AWS to Azure we need to consider a range of things – let’s take a look at some key ones.

Understand what’s the same and what’s different

Both platforms have very similar offerings, and Microsoft provides many great resources to help those utilising AWS to build an understanding of which services in AWS map to which services in Azure. As you can see the majority of AWS’ services have an equivalent in Azure.

Microsoft’s Channel 9 is also a good place to start to learn about the similarities, with there being no better place than the Microsoft Azure for Amazon AWS Professional video series.

So, at a platform level, we are pretty well covered, but…

the one item to be wary of in planning any move of an existing application is how it has been developed. If we are moving components from, say, an EC2 VM environment to an Azure VM environment then we will probably have less work to do as we can build our Azure VM as we like (yes, as we know, even Linux!) and install whatever languages, frameworks or runtimes we need.

If, however, we are considering moving an application from a more Platform-as-a-Service capability such AWS Lambda we need to look at the programming model required to move its equivalent in Azure – Azure Functions. While AWS Lambda and Azure Functions are functionally the same (no pun intended) we cannot simply take our Lambda code and drop it into an Azure Function and have it work. It may not even make sense to utilise Azure Functions depending on what you are shifting.

It’s also important to consider the differences in the availability models in use today in AWS and Azure. AWS uses Availability Zones to help you manage the uptime of your application and it’s components. In Azure we manage availability at two levels – locally via Availability Sets and then geographically through use of Regions. As these models differ it’s an important area to consider for any migration.

Tools are good, but are no magic wand

Microsoft provides a way to migrate AWS EC2 instances to Azure using Azure Site Recovery (ASR) and while there are many tools for on-prem to cloud migrations and for multi-cloud management, they mostly steer away from actual migration between cloud providers.

Kloud specialises in assessing application readiness for cloud migrations (and then helping with the migration), and we’ve found inter-cloud migration is no different – understanding the integration points an application has and the SLAs it must meet are a big part of planning what your target cloud architecture will look like. Taking into consideration underlying platform services in use is also key as we can see from the previous section.

If you’re re-platforming an application you’ve built or maintain in-house, make sure to review your existing deployment processes to leverage features available to you for modern Continuous Deployment (CD) scenarios which are certainly a strength of Azure.

Data has a gravitational pull

The modern application world is entirely a data-driven one. One advantage to cloud platforms is the logically bottomless pit of storage you have at your disposal. This presents a challenge, though, when moving providers where you may have spent years building data stores containing Terabytes or Petabytes of data. How do you handle this when moving? There are a few strategies to consider:

  • Leave it where it is: you may decide that you don’t need all the data you have to be immediately available. Clearly this option requires you to continue to manage multiple clouds but may make economic sense.
  • Migrate via physical shipping: AWS provides Snowball as a way to extract data out of AWS without needing to pull it over a network connection. If your solution allows it you could ship your data out of AWS to a physical location, extract that data, and then prepare it for import into Azure, either over a network connection using ExpressRoute or through the Azure Import/Export service.
  • Migrate via logical transfer: you may have access to a service such as Equinix’s Cloud Exchange that allows you to provision inter-connects between cloud and other network providers. If so, you may consider using this as your migration enabler. Ensure you consider how much data you will transfer and what, if any, impact the data transfer might have on existing network services.

Outside of the above strategies on transferring of data, perhaps you can consider a staged migration where you only bring across chunks of data as required and potentially let older data expire over time. The type and use of data obviously impacts on which approach to take.

Clear as…

Hopefully this post has provided a bit more clarity around what you need to consider when migrating resources from AWS to Azure. What’s been your experience? Feel free to leave comments if you have feedback or recommendations based on the paths you’ve followed.

Happy dragon slaying!

Creating Azure AD B2C Service Principals with PowerShell


I’ve been lucky enough over the last few months to be working on some cool consumer-facing solutions with one of my customers. A big part of the work we’ve been doing in building Minimum Viable Product (MVP) solutions to allow us to quickly test concepts in-market using stable, production ready technologies.

As these are consumer solutions, the Azure Active Directory (AAD) B2C service was an obvious choice for identity management, made even more so by AAD B2C’s ability to act as a source-of-truth for consumer identity and profile information across a portfolio of applications and services.

AAD B2C and Graph API

The AAD B2C schema is extensible which allows you to add custom attributes to an identity. Some of these extension attributes you may wish the user to manage themselves (i.e. mobile phone number), and some may be system-managed or remotely-sourced value associated with the identity (i.e. Salesforce ContactID) that…

View original post 480 more words

Understanding Azure App Service Plans and Pricing


Like many things in Azure, Azure App Service has a multitude of consumption options available that can sometimes make it hard to determine what option suits your use.

In this post I’m going to walk through App Service, and for simplicity’s sake, I’m going to stick to deploying just Web Apps.

So, what do we have available and how does it best fit what I want to do?

Firstly, you can deploy more than a single app into a Plan at no additional cost. New apps will be deployed alongside existing apps and share the resource allocation available in Plan Tier (this is how the old Azure Websites worked, so not much has changed here).

Beyond this there are nuances that it’s worth exploring.

Free Tier (F1)

Charge Model: free

Does what it says on the tin – gives you some Azure App Service capacity for free.

Your application runs…

View original post 828 more words

Any device, any platform, one Microsoft

Only a few years ago you’d have been hard pressed to have mentioned the following four words in a single blog post where you weren’t arguing for / against a way of doing things: Microsoft, iOS, Android and development.

Unless you’ve been living under a rock you will no doubt have seen Microsoft’s announcement on their intent to acquire Xamarin, a business very much about cross-platform application development.

For those of us working in this space this has really been a case of
“what took you so long?” rather than “why?”.

So why should you care? Let me explore this for you…

Please note I don’t have any more insight than you in what the acquisition means. However, based on Kloud’s experience building real business and consumer solutions using Xamarin, I’m going to give you what I think it means to those of us who develop platform-specific applications.

Some background

Microsoft has been working independently of Xamarin to produce its own toolchain for cross-platform application development for the past few years. You’ll note the majority of these are about enabling solutions on any platform which, again, is very different to Microsoft of years gone by.

Portable Class Libraries (PCLs)
A great enabler that unlocks transportable .Net code. These are a big part of the success of Xamarin as they have allowed popular .Net libraries to be made available for use off-Windows, even prior to Microsoft open sourcing the .Net Framework.

Visual Studio Tools for Apache Cordova
Cordova is a great tool for facilitating rapid delivery of cross-platform applications where you are prepared to forgo some aspects of native capability. If you have a bunch of web-centric developers then the foundation components for Cordova will seem very familiar. The Visual Studio tooling is some of the best you’ll find and is actively maintained.
Azure – Mobile Apps, Notification Hubs & Mobile Engagement
Probably the most mature mobile back-end platform about. Integration with APNS and GCM just works and the quick-starts are a great way to dip your toes into mobile application development. The addition of Capptain in 2014 (now Mobile Engagement) bolstered this offering.

Windows Bridge for iOS (formerly Project Islandwood)
There’s no denying iOS and Android are leading platforms, so how do you allow existing applications to run on Windows? You use a Bridge.
Windows Bridge for Android (formerly Project Astoria)
This one’s an interesting one. Unlike the iOS Bridge, Astoria isn’t moving ahead. What happens here? We’ll have to wait and see, though no doubt Xamarin plays a part.

So, C# is the future?

If you’re an experienced iOS and Android developers using Objective-C, Swift or Java you don’t need to drop everything you’re doing and pick up C#.

Chances are you aren’t particularly interested in it… but… you are in an extremely good position to pick up and run with development in this space using Xamarin and C#. Also, you can always import those native libraries you are already using anyway if you find a gap (which is unlikely).

C#’s syntax should not hold a lot of surprises for many iOS and Android developers, and as you already know a lot about the UI constructs on each platform you’re ahead of the pack. While it’s true that a C# developer can quickly deliver solutions using Xamarin, the nearer you get to the UI experience the more platform-specific knowledge you require, even if you leverage something like Xamarin.Forms.

APIs ahoy!

Existing C# developers also get benefits here as they can quickly build cross-platform solutions and only leverage specific skills for certain aspects of the applications (typically the UI). Write it once, deploy on any platform (where have I heard that before???) really comes true here in many cases.

Many great apps are let down by terrible APIs, either through poor performance or security. Imagine a world where your API implementation experts can also write the client libraries that will consume those APIs? C# and Xamarin unlocks this scenario.

But I already have an app for X

When I spoke about Xamarin at TechEd Australia 2013 the number one question I got after the session was along the lines of “I already have an native app on X, why would I use Xamarin?”

This is a fair question and to suggest that you simply re-implement the application in C# with Xamarin is not the answer you want to hear.

No doubt, though, you are eyeing at least one other major mobile platform in the market and wondering how your existing application can reach that platform.

You have two choices: go native or go cross-platform.

This is your sweet spot – go cross-platform. Eventually you will find a smaller incremental change will deliver you the same cross-platform application on your existing platform of choice.

Yeah, but a native app’s so much better

In the smallest of circumstances you may be right. As I said, Kloud has successfully built and deployed heavily used enterprise and consumer applications that I would dare you to pick as having been developed using Xamarin.

Xamarin has spent a lot of time documenting real-world use of their technology that I’d recommend you go and digest.

But it’s Microsoft!

Yes it is.

The one that has the leading productivity apps on iOS and Android platforms, supports Docker, has its own OpenSSH port, open sourced the .Net Framework, its JavaScript engine and works in the open on GitHub.

Microsoft’s strength has always been its understanding of the developer and the tools they need to do their work. Now with Xamarin you get this benefit regardless of your platform of choice.

Happy Days! 🙂