Creating Self Signed Certificates on Kubernetes Welcome to 2020. Creating self signed TLS certificates is still hard. Five (5) years ago I created a project on github …

Creating Self Signed Certificates on Kubernetes

Bitbucket Pipelines vs .NET Core

There are many things to like about Atlassian’s Bitbucket, but .NET support in Pipelines is not on the list.

BitBucket’s Pipelines are for “Integrating CI/CD for Bitbucket Cloud,” and are “trivial to set up” using a YAML file for describing actions.

from 3/8/2019

Here’s an example of a pipeline file:

    - step:
          - dotnetcore
        script: # Modify the comma`nds below to build your repository.
          - export PROJECT_NAME=hello.csproj
          - export TEST_NAME=hello-tests.csproj
          - dotnet restore
          - dotnet build $PROJECT_NAME
          - dotnet test $TEST_NAME

Pretty simple, right? Yep, nice and simple. Executing the pipeline is pretty easy, too. The problem is that this pipeline will fail, and the failure has little to do with the code.

Bitbucket Pipelines only accepts the JUnit XML format for test output. Since your standard .NET project does not use JUnit tooling, the Bitbucket Pipeline doesn’t find any test results.

You could fix this problem by using the JUnitTestLogger. Or you just use a hosted CI/CD solution which handles .NET better. Azure DevOps anyone?

Avoid Shared Assemblies with Azure Functions

Keep Azure Function assemblies monolithic, or be prepared to work deal with mismatching Azure Storage assemblies.

Azure Function projects which attempt to share common code via other assemblies will fail to compile with:

CS0433: The type 'CloudBlob' exists in both 'Microsoft.Azure.Storage.Blob, Version=, Culture=neutral, PublicKeyToken=31bf3856ad364e35' and 'Microsoft.WindowsAzure.Storage, Version=, Culture=neutral, PublicKeyToken=31bf3856ad364e35' <Assembly with Azure Functions and including shared assembly which includes Azure Storage assembly>
AzFnTrials Solution Hierarchy

The mismatch occurs due to the Azure Storage versions included in the Azure WebJobs extensions and more general Azure Storage.  The nearby AsFnTrials Solution Hierarchy screenshot highlights the mismatched versions.  
The easiest way to avoid this compilation error is to keep all of the code in a single assembly – e.g., move BlobHelper.cs to SharedAsmb and remove CommonLib (or remove it from dependencies).

The downside with this approach is that sharing code gets more complicated, particularly when existing shared code exists.

The Beginning of the End of OS’s

Who cares about operating systems anymore? Microsoft’s recent moves toward Linux, along with their emphasis on Azure, should make it clear that OS’s are diminishing in importance.  (cf. Red Hat on AzureSQL Server on LinuxBash on Windows)  Breaking with Steve Ballmer’s (misbegotten) approach to Linux, Nadella’s Microsoft realizes that Windows isn’t the center of their universe anymore (and can’t be considering their inability to convert desktop dominance to mobile devices).

Developer sentiment is another indicator.  Fewer and fewer developers care about the OS.  OS just doesn’t matter as much in a world of Ruby, Python, Node, MEAN, etc.  This trend will accelerate as PaaS providers continue to improve their offerings.

OS’s aren’t going away, but their importance or mind-share is waning broadly.

Perils of Async: Introduction

As application communications over lossy networks and “in the cloud” have grown, the necessity of performing these communications asynchronously has risen with them. Why this change has been occurring may be an interesting topic for another post, but a few simple cases demonstrate the point:

  • Web browsers make multiple, asynchronous HTTP calls per page requested. Procuring a page’s images, for example, have been asynchronous (“out-of-band”) operations for at least decade.
  • Many dynamic websites depend on various technologies’ (AJAX, JavaScript, jQuery, etc.) asynchronous capabilities – that’s what makes the site “dynamic.”
  • Similarly, most desktop and mobile applications use technologies to communicate asynchronously.

Previously, developing asynchronous software – whether inter-process, multi-threaded, etc. – required very talented software developers. (As you’ll see soon enough, it still does.) Many companies and other groups have put forward tools, languages, methodologies, etc. to make asynchronous development more approachable (i.e., easier for less sophisticated developers).

Everyone involved in software development – developers, managers, business leaders, quality assurance, and so on – need to be aware, however, that these “tools” have a down-side. Keep this maxim in mind: Things that make asynchronous software development easier also make bad results Ibugs!) easier. For example, all software involving some form of asynchronicity

  • Not only has bugs (as all software does), but the bugs are much, much more difficult to track down and fix
  • Exhibits higher degrees of hardware-based flux. Consider, for example, a new mobile app that is stable and runs well on a device using a Qualcomm Snapdragon S1 or S2 (single-core) processor. Will the same app run just as well on a similar device using (dual-core) Snapdragon S3 or above? Don’t count on it – certainly don’t bet your business on it!

This series of posts, Perils of Async, aims to discuss many of the powerful .NET capabilities for asynchronous and parallel programming, and to help you avoid their perilous side!

azureQuery vs. Azure SDK for Node


One of our recent projects involved using JavaScript to access Windows Azure data and features.  When considering the overall design, we discussed client- or server-side execution models (where the “meat” of the code will execute).  In this post we hope to expose what we learned in this process to others.  Although quite a few JavaScript libraries exist for accessing parts of Azure, the two we’ll analyze here are azureQuery and Azure SDK for Node.

First, a little context about each library:

azureQueryAzure SDK
PublisherDavid Pallman – NeudesicWindows Azure – Microsoft
URLazureQueryWindows Azure Node.js Developer Center
Code URLazureQuery on CodePlexazure-sdk-for-node on GitHub
Initial ReleaseJuly, 2012September, 2011


Next, some characteristics of the libraries:

azureQueryAzure SDK
Execution LocaleClient-side (browser)Server-side (node)
Fluent (chaining) language support?YesNo
Storage Support?




*Not YetYes


*Not YetYes
Service Bus Support?^NoYes
Identity & Access Control?NoNo
* As of 9/12/12, azureQuery only provides access to Windows Azure Blob Storage^ We are not clear whether azureQuery plans to support Service Bus integration.


The table above highlights that, in its current state, azureQuery is very limited in its support of Azure features.  Actually, that’s to be expected. azureQuery was first published in late July, 2012; Azure SDK for Node was 10 months old at that point. We expect azureQuery will deliver support more areas of Azure, especially as the level of developer contribution improves (David Pallman has a full-time job, after all!).


Which should you use?

So, which of these libraries should you use for projects now?  If you’re thinking, “That’s not even the right question!” you are right!  Decisions regarding which code runs client-side or server-side has a great deal more to do with application requirements, scale expectations, data change rates, etc.

However, it is pretty clear at this point that azureQuery is still in its infancy.  If your goal is to rapidly deliver a solution using Windows Azure (beyond Blobs), then you should use Azure SDK for Node.  This decision will change as azureQuery fulfills its (assumed) mission. If solution demands client-side execution (e.g., rich visualization of changing data), then we encourage you to invest in azureQuery and contribute to its advancement.

Windows Azure Management Portal in Firefox, Moonlight on Linux


We have Arch Linux running on a 7 year old Dell desktop. It’s an oldie, but a goodie.  The combination of Arch with LXDE makes for a good administrative machine – email, web browsing, bittorrents, etc.  We had tried using the Silverlight-based Windows Azure Management Portal on this machine – using Mono’s Moonlight as the the Silverlight for Linux – but found enough hiccups that we stopped wasting our time.  When Windows Azure began offering its HTML5-based management portal, our interest in managing our Azure systems from Linux was renewed.  Here’s a brief review of our experience:

Using Firefox 13.0.1 on Arch Linux, we opened After signing in, we were left on what appeared to be a blank page.  On right-clicking the page, we learned that it was actually trying to use Silverlight, and the Moonlight implementation didn’t seem to be rendering correctly.  We wondered why we hadn’t been given a choice between Silverlight and HTML5 – we seem to remember that in Win7+ IE.

We uninstalled Moonlight in hopes that the portal’s page code would opt for HTML5 when no Silverlight support was detected. Unfortunately, the portal’s entry page just showed the familiar “To view this content, please install Silverlight….”

Disappointed, again.  The management portal doesn’t seem to detect the lack of Silverlight support and redirect to the HTML5 version.  The user is not presented a choice of which to use. And either the Moonlight implementation or the portal implementation in Silverlight don’t work correctly.

UPDATE: After tweeting that the portal wasn’t working in our config, we quickly received a response from @ScottGu saying that we need to use for the HTML5 portal. (Whether the tweet came from the real Scott Guthrie or a ghost tweeter, we don’t know). We were immediately pleased to find that the HTML5 portal worked very well in our non-Microsoft config! Kudos to Microsoft and the Windows Azure team for delivering cross-platform, cross-browser management tools – well done!

UPDATE 2: The portal link/button on navigates to (which requires Silverlight).  If you want to use the HTML5-based management portal, be sure to open directly.

Azure: Flex on IaaS, Keep PaaS Pure

I recently commented on Mary Jo Foley’s post Can Microsoft Save Windows Azure?  The key point of my post was that IaaS is good for Azure because it is good for adoption rate.

This change does raise concerns for software developers, however. On the topic of increasing IaaS in Azure, Mary Jo wrote:

This means that Microsoft will be, effectively, following in rival Amazon’s footsteps and adding more Infrastructure as a Service components to a platform that Microsoft has been touting as pure PaaS. [highlight added]

For software architects and developers, Microsoft PaaS approach with Azure has been a boon. Many non-developers would be surprised to know how much “infrastructure impact” creeps into system architectures and implementations. The (historically) pure PaaS Azure, however, provides us with the ability to implement highly available, scalable and performant systems with almost no infrastructure concerns.

Many consider Amazon to be the top cloud computing provider.  Amazon Web Services (AWS) provides a very good set of building blocks which (increasingly) work well together. From a developer’s perspective, however, these building blocks require too much “IaaS overhead.”   Determining which building blocks will be needed is the first hurdle. But then come the “which to use in what?” hurdles. Which distro and version of one of the Linuxes, which database type (SQL, NoSQL), how will the various systems communicate with each other, etc., etc., etc.

With Windows Azure, however, a developer can implement code on a developer workstation (using the Compute and Storage emulators).  When ready, the developer can deploy code to Azure directly from Visual Studio.  Relative to just about every other cloud provider, Azure developers start out much further down the road (= saves a lot of time).


In PaaS, Purity Matters

So how does Azure’s IaaS push impact developers?  Developers will be negatively impacted by letting IaaS pull in PaaS impurity.  In other words, if Microsoft muddies the existing Azure development platform (code interfaces), the level of “IaaS Overhead” increases.  As the level of IaaS Overhead increases, the time and cost benefits of PaaS erode.

Consider the Win32 days: Microsoft’s progressive push toward a standard set of API’s for Windows created a competitive advantage.  Although there were gaps (e.g., API’s supported on Windows NT, but not Windows 95), Win32 was far more pure than any other API at the time.  Companies that developed software for the myriad Unix systems encountered far more platform related costs than companies developing for Windows.  If Microsoft had tried to support Sun, IBM, HP and other Unix libraries, the advantages of Win32 would have vanished.

Hopefully Microsoft plans to keep the PaaS side of Azure pure, while letting the IaaS side flex.  Otherwise, they will undermine one of their most significant competitive advantages – a pure PaaS.

Periodic Table of Cloud Computing

David Pallmann, General Manager at Neudesic has published one of the best explanations of Cloud Computing in Windows Azure Design Patterns.  The title is a double misnomer – it isn’t just about Azure, and it is far more than Design Patterns.

Pallmann’s Periodic Table of Cloud Patterns is one of the best tools for visually capturing the various components and facets of Cloud Computing.  He uses these elements very effectively to touch on Infrastructure-as-a-Service (IaaS), Platform-as-a-Service (PaaS) and Software-as-a-Service (SaaS) before delving into Windows Azure’s PaaS offerings.

Although the slides cover Windows Azure, Pallmann’s points are easily abstracted to Cloud Computing in general.  And he provides a very solid foundation for digging into areas such as:


  • Claims-based Security
  • Service Bus (resilient queue)
  • Storage – Blobs, Tables, Queues
  • Database – SQL Azure
  • Compute Instance Types


Overall an excellent presentation for Cloud Computing and well worth reviewing!

Is More IaaS Good For Azure?

Mary Jo Foley recently posted Can Microsoft Save Windows Azure? on  Obviously the title is geared more toward grabbing your attention, but the article has some good content.

One paragraph caught my attention in particular:

Starting around March this year, Microsoft is slated to make some very noticeable changes to Windows Azure. That’s when the company will begin testing with customers its persistent virtual machine that will allow users to run Windows Server, Linux(!), SharePoint and SQL Server on Windows Azure — functionality for which many customers have been clamoring. This means that Microsoft will be, effectively, following in rival Amazon’s footsteps and adding more Infrastructure as a Service components to a platform that Microsoft has been touting as pure PaaS. [highlight added]

Why is Microsoft pushing more IaaS into Azure?  In a word: Adoption.  Microsoft needs to increase the Azure adoption rate.  Far more people in IT organizations know how to participate in IaaS than PaaS.  They already know to install and configure Windows Server, SharePoint and even some of the myriad Linuxes.  Many already contract out their power and internet access to hosting companies, etc.  Running a VM on Azure (or RackSpace, Amazon, etc.) is a natural next-step.

Stepping into PaaS, however, is a much larger step.  Designing and implementing software for any platform always requires more time, and almost always involves more people.  By way of analogy, consider two word processing applications: Microsoft Word and Apple Pages.  Pages only works on Apple operating systems.  To run Pages on the Windows operating system (if Apple so desired) would require a great deal of time and cost.  Microsoft has developed Word for both Windows and Apple operating systems – at great expense of time and money.

So, companies IaaS uptake tends to be faster than PaaS.  In fact, some companies will only engage in IaaS and SaaS, but that’s a separate story. In order for Azure’s adoption rate to continue, it needs to open the door for more IaaS adopters.