The Sidecar Pattern

It has been a while since I have written anything here. I need to pick up writing again. I started this blog to keep reminders for me. If others have gained knowledge from it as well, then great. Technology is ever changing. I want to keep my skills up to date. So I wanted to start to incorporate containerization into my arsenal. In doing so, I decided to start where I always have started (after “Hello World” that is), with patterns. There is no use in reinventing the wheel. Also, patterns establish a common vocabulary, allowing you to communicate with others. To get my feet wet again I decided to start with a simple pattern that I have seen, the Sidecar Pattern.

The Sidecar Pattern

The Sidecar Pattern is a pattern that allows you to deploy, in isolation, a component of an application. It also allows applications to be composed of different components regardless of technologies used to create those components. This pattern doesn’t necessarily require containerization, but containerization definitely helps.

Sidecars live and die by the component they are “bolted” to. Some ideal candidates for Sidecars are monitoring, logging, configuration, and networking services. These tasks can be developed in a container and then bolted on to an application. Sidecar allows you to develop this functionality in isolation of the original application; this also removes the need to tightly couple the functionality within the application and allows you to develop reusable components that can deploy bolted onto other applications. This is where containers come in handy. Put the Sidecar functionality into a container and expose properties to configure the functionality and you have a reusable container. When it comes time to deploy your application you can bolt your Sidecar onto your application and deploy them as a container group.

Pros and Cons


  • Applications and Sidecars may be written in different languages
  • Application code should not have to change
  • Because of proximity (same container group), latency should be low
  • Even if applications don’t provide extensibility, you can add functionality through a Sidecar


  • Maybe overkill. If your app is small, you may want to bake in the functionality
  • If the Sidecar functionality needs to scale differently than or independently from the main applications, you may want to make it a separate hosted service
  • When interprocess communication needs to be optimized, you may not want to use the Sidecar Pattern.


Here I will highlight a couple of real-world examples:

Networking Services

Say you have a web application that uses HTTP to host it and you want to secure it with SSL. You could dig into the application and make the necessary changes; perhaps resources were hardcoded. That may be too much work, or maybe you don’t even have the source code. What can you do then? First, host the web application in a container and expose a local host endpoint ( Now host the NGINX service in a Sidecar container. Configure NGINX to terminate the SSL connection and forward the requests to the web application. Because the Sidecar is on the same host, it can access the local endpoint. The web application didn’t have to change to support this new functionality.

Configuration Management

Now let’s say that your application reads configuration data from a local store (file system, database, etc.). In the future, you want to hand configuration management from the cloud. You could go back to retrofit your application but that may take too long or may be complicated. One way you can achieve this is by creating a Sidecar with a configuration manager service. This service can talk to the cloud service, download the configuration or any changes, and write them to the local store. The local configuration manager can then signal the application container to perform some action that will trigger the application to fetch the new configuration information from the local store.


This post was just a quick look at how you can use a simple distributed system pattern to add functionality to an existing application. It also serves as a kick in the pants to keep writing and learning.

Posted in Distributed Systems | Tagged | 1 Comment

The State of Enterprise Applications – Where We Came From


Enterprise applications used to be these huge monolithic silos (ERP vs CRM vs LOB) that took expensive equipment to support it and took eons to add features. They were hard to adapt to the ever changing technology landscape. Integrating them, with other applications within the enterprise, usually took a PhD months to years accomplish. Since they were usually slow to evolve, maintaining them meant career suicide for the developer assigned the task and when that developer left for green pastures finding someone new, with the required skillset, was hard and expensive. Then along came mobile and everyone scrambled to shoe horn in their silos so that their executives can carry around a tablet and feel productive. Further and further behind these apps fell as cloud technologies grew. Not to mention, as these legacy apps grew, features were implemented and forgotten, till these apps became bloated, behemoths.

Silos are bad. What more do I need to say. Enterprises of old gathered all this data within the silos marking it hard to make strategic decisions. Getting the whole picture required the data team performing data acrobatics to get all the data into a common taxonomy so that it could be analyzed. These processes were usually time consuming so it took a while for the data to become “actionable”, usually too late for rapid action. It then took a data scientist to make the data, and thus the applications, smart. Again, another time-consuming process to create, train and deploy data models. Changing any assumptions required the whole process to start over again. “Actionable” back then meant days, weeks, months or sometimes years. Granted in the beginning there was little data to analyze but that is no longer the case.

In the beginning, there were no user names and passwords. Then we had to log on to the computer. Next came the first enterprise app that needed access control and another username and password. Your boss asks you to do some of his work in the new systems and under penalty of death they give you their username and password and heads to the golf course. “Hey, we are using this new third-party system in addition our app.” Another username and password. “We are integrating with our new vendor….username, password!” “We got acquired, we are rich, our systems are not compatible, here’s your new username and password.” Pretty soon that sticky note under the keyboard is full and you have to switch to a college ruled note book using single spacing to keep track of all the usernames and passwords.

Green screen comes up, you type “Global Thermonuclear War” and you were off and running. Then came the GUI. How many textboxes, check boxes, buttons, graphs and other widgets can we fit on the screen. Oh, and the tab order is never convenient. Web is popular…gotta love it when you hit the backspace button, the page navigates back and all your work is gone. The user experience was never a concern when developing for the enterprise, who cares about users. The workforce gets younger, growing up with iPads in their hands, they see the forms over data interface and want to crawl up into a ball and cry. Not to mention the early mobile adaptations of these enterprise apps.

Developing these apps usually means spending months gathering requirements, a year building the requirements, more time testing, finally getting it into the hands of the users, only to find out the assumptions made last year are no longer valid. Not to mention throwing the “finished” product over the wall to the engineers that are going to support it without giving them any tooling to help them assess what is going on with the app. What you do give them is hundreds of pages of documentation that someone, who doesn’t want to do it, wrote. Of course, they don’t want to read it.

That pretty much describes where we came from. There are details that I skipped but you get the picture. So why do we look back at the horrors (first world issues) we had to endure? Obviously, it is important to understand the pain so that we don’t doom ourselves by repeating the mistakes of the past. I wanted to do it to marvel at the technological advances that have been made over the past 20-30 years that have made these early enterprise apps obsolete. The point is technology is change and rapidly. Enterprises, that were slow to adapt to change, have had to change the way that they look at the world. If they don’t adapt they will go the way of Woolworth, Border Books or any number of business that have gone under or are about to go under (looking at you Sears) because they did not adapt to the change. In the next post, I will look at where we are and then I will look at where we are going.

Posted in Architecture | Leave a comment

My First Hologram


When Microsoft first announced the HoloLens, I was interested in the possibilities that this device opened up. When I tried it a few months later at Build 2015, I knew I had to get my hands on it and start to developing for it.  This past winter, Microsoft announced that they were going to start selling developer devices so that developers could start getting apps into the store. Microsoft wants a vibrant app store before these devices go to consumers. Of course I had to sign up to get one. Since there is a limited number of devices being manufactured, Microsoft set up distribution in waves.  Developers in each wave could order 2 device when their time came.  They also said that it would take 2-3 months for each wave to be served. I was in wave 2, so the wait was on.

Last week I received my notice that it was my turn.  I ordered the device and got it a few days later. That was last Thursday. So I did what everyone does when they get one, I played.  There are some pretty cool apps already available for the device including the community suggested, Microsoft built, Galaxy Explorer. You can even get the source code if you want to see how the magic is done. Once I got the playing out of the way it was time to get down to business. I don’t want to just play with holograms I want to build them.

Lately Microsoft has been building great developer resource websites to help get developers started on their technologies. That is true for HoloLens. I encourage you to pop over to the Holographic Developer Center and check all the resources available. There are two types of apps you can build for the HoloLens, 2D and 3D (holograms). 2D apps are just Windows 10 Universal Apps. So if you can build a Universal Windows App then you can build a HoloLens App. To load the HoloLens tools and emulator you will need Visual Studio 2015 Update 2. If you want to build 3D apps you will need a different tool.  The easiest way is to use Unity3D but not just any version of Unity3D, a special beta version. Note the word special, more on that in a bit.

hololens errorThe SDK, the emulator and the special beta version of Unity were released at this years Build conference in San Francisco. I was downloading the tools before the keynote announcing the was done.  I wanted to start to play. I got things up and running with relative ease. If you don’t have a device the emulator is pretty good. Fast forward to this past weekend when I wanted to start developing for the device. I figured I would use the app I got running in the emulator. No Joy! Try it in the emulator again. No Joy! So I Google’d it with Bing and found that other people were having similar issues but not just with HoloLens apps with Win 10 apps as well. The solution reinstall the tools.

Keep in mind there are a lot of beta bits/special configurations required to develop for HoloLens. We are early on in the process, on the cutting edge so not all of the tooling is locked in.  If you are like me and develop for many different platforms and experiment with many beta bits, your Visual Studio can get out of whack. I did not want to reinstall Visual Studio so I went about tweaking, big mistake. Come to find out I couldn’t even build and deploy UWP apps to my local machine. Step one fix UWP. Step two deploy 2D UWP app to HoloLens. To accomplish this I ended up having to repair my Visual Studio instance. Not as bad as reinstalling but still time consuming. Mission accomplished.

Now onto holograms. I decided I would not try to wing it so I took a step back and visited Microsoft’s Holographic Academy.  While I was out at Build this year I got to do a half day Holographic Academy session and it was a great way to get into developing for the HoloLens. More specifically I visited Holograms 100: Getting Started With Unity. This tutorial walks you through setting up Unity for HoloLens development. At the end you have a cube floating in your environment (the Hello World for holograms). I had the special version of Unity so I was ready to go.  I started the tutorial. I try to deploy to the HoloLens….No Joy! Back to Bing.  It seems that the special version of Unity has been updated since Build.

Ok time to uninstall and reinstall Unity and people on Bing said beta 16 is the flavor of the month. Get it on my machine. Let’s get this cube floating…! Now what? I go back and walk through the tutorial again and realize that the virtual SDK is not set correctly.  It should look like this:


Come to find out it is not beta 16 I need it was beta 16-HTP.  Lesson learned: follow the links on the Dev center page to ensure that you are using the latest bits.

Ok time to uninstall and reinstall Unity……again!! Right! Here we go. Redeploy and…..a 2D app running the Windows 10 unity player. There is my cube but it is not 3D.  Why can’t I get a cube to float in front of me? I am going on 2 days of this. All I want to do is see a floating cube. Is that too much to ask for?  Come to find out I skipped a step in the tutorial:


This seems important. Don’t you think? So after 2 days of tinkering and uninstalling and reinstalling Unity and repairing Visual Studio a couple of time….success (see picture above).  A floating square!

Why am I excited about a floating square? I have no Unity experience so I am learning as I go. This exercise has taught me a few things.  First Don’t be afraid to reinstall the tools if they weren’t working. I think that my initial reaction to having to do that kept me going down a path of try this/fail to the point where the time I wasted tinkering could have been spent developing. On the plus side I did learn about all the different settings that I need to troubleshoot in the future. Next, it is early on in the development cycle and the tooling is still being developed. So things that you would expect to be done for you may not be done for you. Case in point the manifest change that you need to make. Finally there is not a lot of help outside of the community page for HoloLens development.  It is that early so start there.

So where do I go from here.  I want to do the other tutorials in the Academy.  They address the capabilities of the SDK.  Next I will spend some time poking around the documentation to get a better feel for what is available. To me the compelling enterprise examples will require getting external data in to my apps. So I will look into/develop some best practices around that. How do I get data into my Unity app? How do I make it interactive? Finally I need to learn how to really use Unity beyond floating cubes. I see Unity training/tutorials/experimentation in my future.

I am excited about where HoloLens is taking computing.  I can only imagine where we go from here.  In the mean time I get to build holograms and I think that is pretty cool.


Anyone who has visited the Magic Kingdom in Disney World, will recognize this sign that hangs above the entrance.  I believe that this can applies to the world that HoloLens opens.

Posted in HoloLens | Leave a comment

The World of Holograms Approaches!


Yesterday Microsoft announced the availability of the HoloLens Developer Kits.  The kits are available to developers who registered and were approved to get them. They will be shipped in waves with wave 1 shipping on March 30th.  These kits are going for $3000 and are only available in the US and Canada. Making a real hard decision on whether or not you should buy or not.

Microsoft HoloLens is the world’s first fully untethered holographic computer. HoloLens redefines personal computing through holographic experiences to empower you in new ways. HoloLens blends cutting-edge optics and sensors to deliver 3D holograms pinned to the real world around you. Microsoft Hardware site

Microsoft’s goal with this release is to get devices into the hands of developers in order to build up a supply of applications in the store. To that end they made the developer site available yesterday as well.  Keep in mind that this is still early on in the process so there are a lot of placeholders throughout the documentation, including the additional SDKs and HoloLens Emulator. It looks like more information will become available March 30th, which, coincidentally is the first day of Build 2016. Since all of the content is usually made available online and some even streamed live, like the keynotes, I would tune in to see what happens. 

The Hardware

Amongst the details released yesterday were the hardware specifications.  There are some pretty cool breakdown photos on the Hardware site. Here is what we know taken from the hardware site:


  • See-through holographic lenses (waveguides)
  • 2 HD 16:9 light engines
  • Automatic pupillary distance calibration
  • Holographic Resolution: 2.3M total light points
  • Holographic Density: >2.5k radiants (light points per radian)


  • 1 IMU
  • 4 environment understanding cameras
  • 1 depth camera
  • 1 2MP photo / HD video camera
  • Mixed reality capture
  • 4 microphones
  • 1 ambient light sensor

Human Understanding

  • Spatial sound
  • Gaze tracking
  • Gesture input
  • Voice support

Input / Output / Connectivity

  • Built-in speakers
  • Audio 3.5mm jack
  • Volume up/down
  • Brightness up/down
  • Power button
  • Battery status LEDs
  • Wi-Fi 802.11ac
  • Micro USB 2.0
  • Bluetooth 4.1 LE


  • Battery Life
  • 2-3 hours of active use
  • Up to 2 weeks of standby time
  • Fully functional when charging
  • Passively cooled (no fans)


  • Intel 32 bit architecture
  • Custom-built Microsoft Holographic Processing Unit (HPU 1.0)


  • 1.28lbs (579g)


  • 64GB Flash
  • 2GB RAM

This is a pretty impressive set of hardware considering it is all contained in headset that weighs less than 1.5lbs. Keep in mind that this is the developer kit.  The final release hardware (believed to be a couple of years away) will be different/better

The Developer Kit

So for $3000 dollars, what do you getMSHoloLens_GroupShot_wAcc_WhtBG_V2_RGB-1024x444

  • HoloLens Development Edition
  • Clicker
  • Carrying case
  • Charger and cable
  • Microfiber cloth
  • Nose pads
  • Overhead strap

The Developer Experience

To develop for HoloLens you are going to need the following:

  • Windows 10 PC (64bit)
  • Visual Studio 2015 Update 1
  • Unity (5.4)

You will build Universal Windows Apps with Visual Studio, using Unity to build actual holograms. You can find all the details, along with guidance,  in the developer documentation. Remember this is early on in the process and not meant for production so there are some limitations in the APIs that are available.  Microsoft has said that they are currently working to close those gaps and will make additional APIs available in future updates. The goal is to have the majority of Windows 10 UWA run on HoloLens. 

My Thoughts

After a quick run through of the available documentation one thing jumped out at me, only one application can be running at a time.  Holographic applications can’t interact with each other. This seems like a limitation that they will work to reduce as most of their promotional videos show more than one app running at the same time. I hope they are able to fix this in the future.

What does all this mean? The way we interact with computers is about to change.  Will this breakthrough become the norm? Only time will tell. Microsoft is building a platform the allows developers to explore the future of computing and is changing how we think about what experiences we want our users to have.

Posted in HoloLens, Windows 10 | Tagged , | Leave a comment

Azure Event Hub REST API

imageI was recently worked on a project where I had to use a mobile device, specifically Window 8.1 phone/tablet, as a hub for an external sensor. The mobile device then needed to pass the data to an Azure Event Hubs endpoint. The data was then going to be sent through Azure Stream Analytics to various storage solutions. Normally you would fire up a project, go to NuGet package manager, install ‘Microsoft Azure  Service Bus’ SDK, set your endpoint URL and send key, and be off and running. There is one slight problem with that in my architecture. One of the SDK dependencies is not compiled against WinRT so you are out of luck there.

Luckily Azure Event Hubs exposes a REST API that is fairly straight forward except for one thing. How do I assure the service I have the appropriate authorization to send messages. The REST endpoint expects a Shared Access Signature in the header of the request. Here is some sample code for creating that token:


Basically it is a string containing the base URL a hash of the base URL and expiration (using the send key as the hash key) and the key rule name.  You can go to the MSDN documentation for more information on Shared Access Signatures.

I created a little proxy class that encapsulates the generation of this token and handles sending the message:


My Event Hub expects all messages to be formatted as JSON. My proxy method takes the serialized object and packages it up as the content of the HTTP request. It also sets the SharedAccessSignature header value.

UPDATE: I recently got asked what [PATH TO MESSAGE ENDPOINT] is,  So here is a little explaintion. In the EventHubProxy you have [BASE SERVICEBUS URL] which should look something like this:, where xxxxxxxxxx is the name of your services bus namespace. On the portal website you should see you EventHub Url which looks something like this, where zzzzzzz is the EventHub name.  So  [PATH TO MESSAGE ENDPOINT] is ‘zzzzzzz/messages’. I hope this clears it up.

Sending and event to the hub is as easy as:


One thing to note in this architecture is that mobile devices tend to be on metered connections. So be aware that sending loads of data will count against the devices data plan. You may want to restrict sending data only when the device is not on a metered connection.  You can get the code and play with it.  I put TODO statements where you have to provide you environment specific values.

Posted in Architecture, Azure, Cloud, IoT | Tagged , , | Leave a comment

My Visual Studio 2015 Review


Recently I was asked by SDTimes to write a review of Visual Studio 2015.  I had been using it since early previews so I was more than happy to give my two cents.  Check out the article Visual Studio 2015: An insider’s review and tell me what you think.

Posted in Uncategorized | Leave a comment

A Universal Example

In my last post What Does It Mean to Be Universal, I talked about Microsoft’s new Universal Application Platform (name may be changing to Universal Windows Platform), coming in Windows 10. This new application platform allows you to build one application and run it on different platforms.  In that post I told you how Microsoft was doing that. In this post I want to look at an example of what a single app running everywhere, might look like.



Let’s say you were building an application for manufacturing company. They want to deploy IoT sensors running Windows 10.  These sensors would gather telemetry data from the machines on the factory floor.  This data would be transmitted to the cloud where it would be analyzed and reported through machine learning (out of scope for this post).  The data then can be accessed on Windows PC, Tablets and Phones. They also want to take advantage of augmented reality technology to give their plant manager real time access to the data while they are walking around the plant.

The Old

imageIn the past you would probably create a project that looks something like this. You would have multiple projects for each head you want to support. Plus you would have some libraries for code that you want to share across each of the heads. After compiling, you end up with an application for each head. Although not too complex, there is the potential for major code duplication. This is especially true when it comes to the interface and platform specific code (where API differ). There was less of an opportunity for reuse.

The New

imageUnder the system you can create one project, compile into one application, and have it run on all the devices. The APIs are pretty much the same.  When they do differ for a device, Microsoft has a way for that code to still live in the same project (see my last post for a sample). There may be times when you want to separate out code. For instance code that can be reused in projects that are not part of the new platform, server code comes to mind.  That should still be possible.  I say should because we don’t know for sure. We will have to see what comes out at Build next week. Hopefully we will have more clarity on this.


So one project or many projects?  This universal platform is going to make us rethink how we architect our solutions going forward.  Does it make sense to have everything in one project or do you want to keep things separated? I can definitely see creating utility projects that get reused between different solutions but does it make sense to have a .dll for Services or Models?  You used to be able to replace those components just by swapping out dll’s but now everything gets wrapped up into an apex package that is signed.  Swapping out dll’s would invalidate the package so a new build is needed. I am interested in hearing what people have to say about the new universal platform.

Posted in IoT, Software Architecture, Universal App Platform, Windows 10 | Leave a comment