How to deploy Node.js microservices to Azure Service Fabric without Docker Containers

Why would anybody want to deploy Node.js microservices to Azure Service Fabric? What is Azure Service Fabric? Why is it not a good idea to use Docker Containers sometimes?

The short answer is: Scale.

Slightly longer answer is: Scale, Reliability, Resilience, Self-Healing, Service Management, Monitoring, Rolling Upgrades and Roll-backs. And did we mention Scale? Hyper Scale. Out-of-the-box, with little efforts from your side.

We love Node.js, we want to use TypeScript for everything: front-end, server-side, for the whole enterprise. And of course, we want to do microservices-oriented architecture. Can we build a real-life business system that we would be proud of?

Let’s imagine this scenario:

We are building a big new ERP system, connecting corporate accounting to multiple warehouses, partner fulfillment systems, parent company archaic monstrosity system, and a bunch of corporate departments. We are planning to build dozens and dozens of microservices communicating to each other and to various external systems. We want performance and reliability - the system must work even during holiday season. And it must be programmed and supported by IT personnel whose main area of expertise is JavaScript.

From this description we can start extracting some architectural requirements:

• Reliability and performance mean that we must run multiple instances for every microservice.
• If a microservice saves local state, that data must be replicated across virtual machines, and special algorithms for writing to those replicas, retrieving data, and failover should be implemented.
• We need a special manager service to monitor health of each microservice instance/replica and replace failed ones.
• Communication between microservices, each having multiple instances becomes a separate problem, so we need to implement a service discovery to figure out an endpoint to which to send a particular message.
• We need a way to quickly deploy any or all of our microservices without system downtime, and roll back the deployment if something goes wrong.
• And we need a management UI to see the state of the whole system, to start, stop, update, or query any microservice, as well as scale the system up and down.
• etc.

Sounds like a lot of work even before we start developing actual business logic. This is exactly the reason why we need Azure Service Fabric - it does all this and more out-of-the-box. We just need a way to put all our JavaScript microservices into the Service Fabric cluster.

The bad news: Azure Service Fabric does not natively support services written in JavaScript.

The good news: SupercondActor gives Service Fabric the ability to run services written in JavaScript.

With SupercondActor you will have all the benefits Azure Service Fabric has to offer, and will be able to keep working in the familiar Node.js development environment. Just navigate to the SupercondActor repository on GitHub, get the deployment scripts, and work on your business logic - most infrastructure problems are taken care of.

Here is what you need

First, you need to have a Service Fabric Cluster. There are options:

• Service Fabric cluster in Microsoft Azure Cloud
• Service Fabric cluster deployed on-premises using Azure Stack
• Service Fabric Development cluster installed on local computer

Second, you need to deploy SupercondActor Application to the cluster. After that you will be able to use SupercondActor Service Manager UI to, well, manage your microservices.

Third, you create Node.js microservices using your favorite development environment, compile everything into JavaScript bundles, and package together with configuration files into the SupercondActor Code Package (just a zip file). Upload the Code Package to the cluster using the Service Manager and see your hyper-scalable system up and running.

Getting Service Fabric Cluster

You can create a Service Fabric cluster in Azure cloud using the Azure portal. See instructions here.

Another way is to use PowerShell script CreateNewCluster_DeployApps.ps1 in this GitHub repository.

Deploying SupercondActor Application

The SupercondActor deployment is really simple, just run corresponding script and wait several minutes.

Find all necessary deployment scripts in the SupercondActor repository on the GitHub: https://github.com/SupercondActor and documentation at https://www.supercondactor.com/documentation/deployment/

There is even a script which creates new Service Fabric cluster in Azure cloud and deploys SupercondActor application for you in a single step.

What kind of services?

All microservices in your system can be split in three categories:

• Scheduled Service - runs your JavaScript code on a predefined schedule, for example every 15 seconds retrieves data from a Database and sends messages through an external Email Server.
• API Service - a JavaScript code responding to an HTTP request.
• Long-running Service - covers all other types of services - runs your JavaScript code during the lifetime of the service. This service, for example, can process external events, like messages arriving through a queue or IOT data stream.

You specify the type of a particular service and necessary parameters in the configuration JSON file.

See examples in the SupercondActor repository on the GitHub:

https://github.com/SupercondActor/platform-app-helloworld

https://github.com/SupercondActor/platform-app-hostfunctions

https://github.com/SupercondActor/platform-app-mailer

https://github.com/SupercondActor/platform-app-angular

Creating Node.js microservices

Using Service Manager UI

The easiest (primitive) way to create and register your business service is to use SupercondActor Service Manager UI. All you need to do is to click a button to create a service, enter a name for the service, and type or paste JavaScript code into a form field.

Of course, for any serious processing you would need more than several lines of code. You would need to load third party libraries, create multiple code files, etc. So, for a real-world process you would deploy your code using Code Package - a set of folders and files packed in a zip file.

Using Code Package

Whether you are developing a single business service or a complex application containing multiple services of different types, the best way of deploying your code to the SupercondActor Business Platform is to use Code Package - a set of folders and files packed in a zip file.

Structure of the Code Package

You can create a Code Package manually, or you can take advantage of sample projects from the SupercondActor GitHub repository which all use webpack script generating package when you run npm run build command.

If you want to create a Code Package manually, you need to know several simple rules and pre-defined folder names.

The name of the package zip file can be anything, but inside there can be five folders (each folder is optional, but if present those folders must have exactly these names):

• ApiServices
• LongRunningServices
• ScheduledServices
• Scripts
• Files

ApiServices, LongRunningServices, and ListeningServices folders contain configuration and job script files describing your business services.

Scripts folder contains common JavaScript libraries for all services in the current application.

Files folder can contain any additional files you want to be deployed and accessible by the services in the application.

BusinessScriptBundle.zip
|
├── ApiServices
|  ├── myService1.config.json
|  ├── myService1.job.js
|  |
|  └── myService2.config.json
|
├── LongRunningServices
|  ├── myService3.config.json
|  └── myService3.job.js
|
├── ScheduledServices
|  ├── myService4.config.json
|  └── myService4.job.js
|
├── Scripts
|  ├── bundle.js
|  └── another.js
|
└── Files
   ├── index.html
   └── styles.css

You upload this zip file using SupercondActor Service Manager UI.

See detailed documentation at https://www.supercondactor.com/documentation/