Running Non-containerized Microservices

Whenever someone says orchestration for microservices, the first thing that usually comes to mind is Kubernetes. I believe that’s normal. I used to think the same but then I came across an interesting scenario that changed the way I used to think about microservice orchestration completely.

Usually, people think microservices mean containers, hence they build their application in a cloud-native approach so that it can easily run on any platform using the containerized approach. I agree that containerization is a decent way of designing a cloud-native application, especially when integrating it with orchestrators like Kubernetes or OpenShift. It takes away a lot of overhead from us like:- scaling, failover, deployment, etc but it doesn’t imply that microservices can only be managed inside a containerized ecosystem. Microservice is an ideology or mindset for designing the application and containerization is a power-up that supports the ideology.

Now, I believe you guys must consider the possible scenario that containerization cannot support. Well, the kind of application I was dealing with was .net-based which can only run on the Windows platform. Now, obviously, we could use windows containers and we did try it but it’s still in the development phase and will take time to mature. Another way was to use static VMs but that will be a wastage of resources. Therefore, we didn’t go with those options and went with another option i.e. “Nomad”.

Why Nomad?

Kubernetes is an orchestration system that is designed to manage the container ecosystem but, as we discussed, here we wanted to orchestrate a windows process (mainly windows IIS web server-based process). It means we can say that Nomad is an orchestration engine that supports not only containerized but virtualized and standalone applications as well including Docker, Java, IIS on Windows, etc.

Nomad works in a plugin-based model in which you can leverage the existing plugins like Docker, Java, IIS or you can write a custom plugin as well using Golang-SDK.

Nomad doesn’t support Windows IIS webserver by default, to achieve this we need to install the plugin on the Nomad client nodes. We decided to go with the IIS plugin developed by Roblox Developers.

Roblox/nomad-driver-iis

Implementation using Nomad

While using the IIS plugin, we evaluated that there’re some gaps that needed to be filled. So we decided to add those features by ourselves. Additional features which we have added are:-

• Resource Limit on IIS
• Recycle Parameters
• Environment Variables

Basic features of an orchestration engine were already supported by Nomad like:-

• Scaling/Autoscaling
• Failover
• Metrics Monitoring
• Service Discovery
• Service Mesh

The plugin is available here.

Since we are assuming Nomad and Consul are already part of the setup, we can directly jump to the configuration part of the IIS Job. If you haven’t and want to setup Nomad quickly, please refer to this document:-https://learn.hashicorp.com/nomad

Once the job configuration is complete, we can create the job using the Nomad UI in our cluster.

Now, if you try to open the service on your browser, the content will look like this:-

So as we can see the application is working fine here, now let’s see the service health on consul as well.

As we can see the service looks healthy. Further, we can still try the orchestrator’s functionality, like, scaling. Scale the iis-test count and see what changes have been made by Nomad and Consul.

Once we have scaled the application count to 2, the nomad has started another IIS process for the application and the consul registered it as a second replica of the service. If we try to kill the process as well, the nomad will create another replica of the process just like Kubernetes ;).

If you want to access the code of the blog, please check this repository https://github.com/iamabhishek-dubey/nomad-driver-iis. All the configuration files for nomad and consul are present inside the repository. Also, if you want to test out this setup quickly, there is a Vagrantfile in the repository. To execute the vagrant we simply need to run:-

vagrant up

Conclusion

By thinking out of the box, we solved the issue for non-containerized-based applications as well and we have achieved some basic functionalities of an orchestration engine like- scaling, failover, management, service discovery, etc. for Windows-based applications.

But again, it doesn’t mean that this approach is restricted for Windows-based applications only, by using this plug-n-play method of Nomad we can solve a lot of issues.

I hope you guys have enjoyed the reading but if you have any feedback or suggestions, please reach out to me. In my upcoming blog, I will discuss the production parameters for Nomad and Consul and how we can integrate autoscaling in nomad.