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

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!

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.

“A Pass on PaaS”–Strategy That Won’t Last


Today I noticed a @CloudBlogs tweet along the lines of “Taking a Pass on PaaS.”  My first thought was, “That’s not a good idea!” Then I thought, “This must be a reverse psychology tweet crafted to make you take a look.”  So, in I went; hook, line & sinker.

To my surprise, however, the tweet was true (forward psychology?). William Louth’s article actually proposes that it is foolish to build on Platform-as-a-Service.  To wit:

…it is becoming clearer to me that for the time being it is much wiser for customers and vendors to Pass on PaaS….

Mr. Louth goes on to recommend that customers and vendors should

…focus on consuming and building AWS like cloud services that scale, perform and are themselves far more resilient than any of todays technologies, frameworks, libraries, components and most importantly operational processes.

The article doesn’t seem to specify what “AWS-like cloud services” means.  At the very beginning of the article, the author indicates that Amazon’s ElastiCache launch may have triggered him to write the article, so maybe readers are expected to use ElastiCache as a prototype for “AWS-like cloud services.”

Furthermore, the author seems to confuse PaaS with some specific implementations he has in mind.  In particular, he refers to “containers”

Coming from a CORBA/J2EE/JavaEE background I can very well understand the allure of a container like approach (or glorified process launcher aka CloudFoundry) to architecting and deploying a new cloud application or service. But the problem I have with this is that I’m not convinced that an integrated container is the best option and should be the interaction point for services. [Emphases added]

The author seems to be saying that PaaS is (or is based upon) a “container like approach.”  This characterization is far afield of PaaS, and the explanation by different colored telephone booths is more confusing than clarifying.



To be clear, Mr. Louth is not completely off-base. The problem is that he has too broadly painted all PaaS as unwise.  We can all agree that PaaS is no panacea, but neither is it unfit (technologically or in current implementations).  Mr. Louth’s article argues that solutions built on’s Force PaaS are misguided or foolish.

Although not anathema to Infrastructure-as-a-Service (IaaS), Platform-as-a-Service is geared toward abstracting infrastructure.  Among other benefits, this approach provides for:

  • Shorter delivery time-frames
    • Requiring fewer developers
      • Less monitoring and maintenance
        • All reducing overall costs

NIST provides a fairly good definition of PaaS:

Cloud Platform as a Service (PaaS). The capability provided to the consumer is to deploy onto the cloud infrastructure consumer-created or acquired applications created using programming languages and tools supported by the provider. The consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, or storage, but has control over the deployed applications and possibly application hosting environment configurations.


IaaS providers – such as Amazon Web Services or OpenStack – and PaaS providers – such as or Microsoft Azure – offer differing capabilities for different application requirements.  These layers of cloud computing are often more complementary than competitive.  Application architects and designers must take these differences into account as they consider how to best deliver application requirements.

What Happens When an Azure Role Starts?


Cory Fowler (SyntaxC4) has a good post on Windows Azure Role Startup Life Cycle. Notable aspects of the post include:

  • Synchronous and Asynchronous Startup TaskType and problems to watch for
  • A good, step-by-step diagram of how the Azure Fabric Controller turns the Cloud Service Package (.cspkg) and Cloud Service Configuration (.cscfg) files into a running role instance
  • Suggestions on avoiding Role Startup race conditions

Azure 1.4 SDK and Tools

Yesterday (3/9/11) Microsoft announced updates for the Windows Azure SDK and Tools (VSCloudService.exe).  As the download page indicates, this SDK release’s primary purpose is to address stability issues.  Other improvements include:

  • Azure Management Portal – Improved responsiveness
  • Azure Connect – Multi-admin support and installation for non-English Windows
  • Azure Content Delivery Network (CDN) – Provides for delivery of secure content via HTTPS

Be aware also that the 1.4 SDK installer automatically uninstalls previous versions.  So, if you need 1.3 for a while still, you’ll need to keep it safe.

Download the SDK & tools here.

Amazon CloudFormation – BYO PaaS?

Amazon Web Services (AWS) recently announced the addition of CloudFormation to their offerings. With this addition, AWS continues to grow from an IaaS provider toward becoming a PaaS provider.  Will AWS will become a PaaS provider in terms a consistent programming interface (API) that abstracts the underlying cloud resources?  It not likely; certainly not soon.  Microsoft’s approach with Azure – start with the platform and then open the infrastructure – is better for true PaaS.  AWS offers so many divergent resources that building a consistent API for PaaS is near impossible.  From a technical perspective, their best approach might be to adopt (and heavily influence) OpenStack which has been experiencing good growth and adoption recently.  That direction is not good for business, however, since applications would be inherently portable to other providers.

So what’s the point of CloudFormation?  Amazon’s announcement states that CloudFormation aims to provide “an easy way to create a collection of AWS resources and provision them in an orderly and predictable fashion.”  Is this an IaaS or PaaS capability?  CloudFormation primarily falls into the Systems Management space which is definitely IaaS.  (The fact that AWS does or may expose programmatic interfaces to CloudFormation reaches into the PaaS arena, but it isn’t Cloud Formation’s raison d’être)

This new AWS functionality will certainly benefit SaaS providers.  I worked with a SaaS provider a year or so ago which hosted its own servers.  Their clientele were Fortune 500-types, so the company hosted a new set of hardware for each new client.  If the company were able to host its SaaS in AWS, it would save on capital outlays for new customers. CloudFormation would further cut costs on administrative personnel, freeing people to stand up temporary SaaS environments in AWS, for example, which would facilitate the sale process.

Interestingly, companies wanting to build special purpose (niche) cloud platforms should be able to leverage CloudFormation into their own PaaS.  As an example, companies could use AWS to host OpenStack and use CloudFormation for provisioning and management.  Such a company may gain enough customers and attention to be gobbled up by Amazon itself.

When Free Is Not Enough

Beginning today, Microsoft is offering developers free access to Windows Azure through the end of June.  The offer includes compute time, storage space, SQL Azure database and AppFabric features for Access Control and Service Bus.  See the announcement for details.

This offer should be very appealing to many, many developers and ISVs.  Interestingly, it is not a compelling offer for us.  Why not?  Well, I think the answer is worth passing on.

Microsoft’s free Azure offer is not valuable to those already developing on Azure.  Two perspectives on this fact are:

  • Microsoft has carefully crafted the offer in order to keep paying customers paying
  • Cloud computing is so cheap that the transition cost to “free” is too expensive

I don’t see much value in arguing one way or another about the first point.  Our speculation on this point is no more (or less) valuable than anyone else’s.  We are living proof of the second point, however.  Our monthly Azure expenses are so low, that it’s not work the effort to temporarily switch to “free” and switch back when it runs out.  In this case, the opportunity cost (of lost development work, etc.) is far higher than “free.”

Sometimes free just isn’t enough!