Part 4: Going on with alternative deployment options
This is the fourth of at six articles about how an IoT project with certain constraints and prerequisites was implemented. In recent article I described why it was not possible to create the docker container for OSISoft AKSDK lib and that is was not possible to leverage old-school Azure Classic Cloud Services. This article goes on with the alternative deployment options:Azure Service Fabric, Azure Functions and Windows Services.
- Part 1: Analysis & Design
- Part 2: Let’s go with containers
- Part 3: What about alternative deployment options?
- Part 4: (this one) Going on with alternative deployment options
- Part 5: Final architecture & learnings
Again move the code.
As the code against needs to adopt to a different cloud service, let’s first have a look onto how the code has been structured for docker containers and Azure Classic Cloud Services. In previous article I already stated, the main areas for adoption are Configuration, Logging and Bootstrap. Let’s have a look onto the Bootstrap part.
Bootstrap for Docker
Actually there are always three parts. A bootstrapper and the actual start up class. Additionally one-to-n installer classes. Using dependency injection, all of the services are captured in modules / installers. An installer looks like this, implementing an interface:
The installers are topic related. As the overall size of the program is rather small, there are only two installers. One for configuration, the other for the whole program. With that installer, the Bootstrapper class is implemented. It collects all necessary installer and registers the contained services to the dependency injection framework.
As you may have seen, there are more installers used than provided by the Reader implementation. Obviously there are parts in other assemblies for separation of concerns or due to reusability. A common area provides logging/ configuration functionalities. The cloud common assemblies provide abstractions for Blobs, Service Bus and CosmosDb. These both parts will not change when moving from one Service to another. They will just be used differently. Coming to the Docker implementation of the .net framework executable:
The program file does not need to do too much. It uses the bootstrapper class to register all necessary services then it does it actual job: Initialize the services that are needed for startup.
Bootstrap for Azure Classic Cloud Services
Following the structure above, let’s focus on Bootstrapper and start up class. As stated before, the Bootstrapper class doesn’t change at all. It is only the start up class that needs to be changed. This is for Azure Classic Cloud Services a so-called “WorkerRole” or “WebRole”. This is an unattended service without any user interface or public contract. Therefore it is a WorkerRole. Let’s have a look onto the class.
It is in fact longer than the program.cs in docker container implementations. There is a certain interface/ inheritation that needs to be followed. At least OnStart and Run methods need to be implemented. If you wonder why exception are caught, this is due to the nature of this implementation. If OnStart or Run method fail, the service is directly restarted, even when deploying from Visual Studio. Deployment will not end. So I tend to have a look onto the log and fix things, if necessary.
Having the code prepared for change makes live pretty easy
Okay, we all know, that’s not the full story. Logging and Configuration also need to be taken in consideration. But it works pretty much the same. Some sensible interfaces in common area of the assemblies allow for adapter-like usage. So the effort is pretty low.
Bootstrap for Azure Service Fabric
Going on, let’s have a look onto the necessities of Azure Service Fabric. Again a different approach, different configuration items, logging and startup.
So far so good. Code is under control. But the infrastructure? Let’s see.
Going for Azure Service Fabric
I did skip Azure Functions. I didn’t want to go with the very old 1.x version of Azure Functions which would be the only choice for .net framework.
Service Fabric can be compared to AKS from a functional point of view. It is a self balancing, multi node system. It comes with a out-of-the-box user interface for administration of all nodes. Containers can be deployed but it feels like they are not first-class citizens. Keep in mind, it’s all more windows focussed. There are a couple of comparisons out there, you may want to have a look onto this stackoverflow question.
Due to Service Fabric has a lot of capabilities, configuration and maintenance is a pretty big task. Anyway it comes with pretty much the same functionality like Azure Classic Cloud Services. It is possible to configure a start up batch file that will install the necessary setup.
To make a long story short: I didn’t make it.
Exceptions from a batch file when running a setup are very hard to dig up and understand. From cost point of view, Service Fabric is way to huge for the size of implementation that I planned to do. So I stopped pretty soon with trying. All of these tasks also cost money, due to I spend my time. So I need to speed up this.
Any other options?
What now? I had a lot of options and I don’t get it running. This was one of the most frustrated moments in my developer life. I never needed to go for so many options and still didn’t have a solution at hand. Additionally, time’s flying and I need a solution for making this system run. What do I need?
- Have a system where I can install this setup seamlessly
- There is need to scale, in best case horizontally. If that doesn’t work, vertically would be fine, but Availability still needs to be considered.
- Deployment of sources shall be done automatically
- Deployment of services shall be done automatically
Okay, last exit for the lost: I need a VM. I can scale with single processes vertically. Sources can be deployed on this vm. VM could be hosted in Azure as well. Certainly there are some constraints. For reaching out to OSIsoft, the VM needs a two-cross vnet and read data via VPN inside of the companies’ network. I do not like this solution. But it is a solution. And one that I can do immediately.
Going for a Windows Service
This has been quite some time that I created a Windows Service. I needed to dig it up. Startup is a easy as for all the other variants.
There is a certain procedure that is necessary to be followed to actually install or uninstall a windows service. On the executing machine nobody should use the SYSTEM user for a service due to security considerations. But the code itself is still pretty easy.
Why do I think that infrastructure is going to be more important than coding?
Considering the time that I needed for implementation, latest in that point in time, trying to find the right infrastructure was more time consuming. And I didn’t even start to automate the infrastructure with Terraform and Ansible.
The windows service will just be a keeper service. It will not read on its own. Rather than this it is responsible for starting executables for reading data from OsiSoft. Each executable can read 1-n messages in parallel. In this way I have two different ways of adjusting the vertical scaling.
Again coding was easy. But deployment?
Let me put it like this: At my company it is not possible to automatically provision an VM and deploy code on it from Azure DevOps. VMs are only allowed as Build machines. This is not what I want.
Anyway, the code and the approach works. Let me go even deeper in the next article.