Announcing nScale 0.16 – now with AWS Auto Scaling group support

By: Matteo Collina

I am pleased to announce that the new version of nScale, 0.16, has been released today! This new release includes several new features and improvements, including: AWS Auto Scaling groups support, deployment of multiple versions of the same microservice, and a clean start/stop cycle. Update it with:

npm install nscale -g

nScale logo

How nScale Auto Scaling support works

Auto Scaling is one of the most powerful, but complex, features in AWS. Thanks to Auto Scaling, AWS can automatically adjust the number of instances depending on the traffic your application is facing. However, setting up and configuring these new instances is tricky, and different solutions have been developed along the years. The problem is that AWS spins up a freshly-minted instance based on an AWS Machine Image (AMI) you specify. In order to deploy a new version of your application, one has to create a new AMI, and change it in the Auto Scaling group. nScale and Docker simplifies all that flow, thanks to a clever usage of the AWS SDK for Node.js.

nScale creates a few things for you: an Auto Scaling group, a launch configuration, a Simple Notification Service (SNS) topic, and a Simple Queue Service (SQS) queue. These new entities are added to one already supported: Elastic Load Balancers, Security Groups, and bare instances.

nscale Auto Scaling

Flow diagram of nScale Auto Scaling support

The diagram above shows the message flow that allows us to support Auto Scaling: nScale sets up the Auto Scaling group to publish new Auto Scaling events into the SNS topic, and connect the SQS queue to receive the notification from the SNS topic. Then, it starts listening for new messages on the SQS queue. When a new Auto Scaling event occurs, nScale performs a fix cycle: it redeploys the current version. Thanks to the homeostasis property, nScale detects that the instances run no containers, and it deploys the containers you have specified.

Auto Scaling loop

Event, Analyze, Fix: The nScale Auto Scaling loop

nScale is becoming more intelligent, and in fact it is now similar to a robot. My background is on the Internet of Things, and I studied the basics of automation control: the system works as a loop, where some events happen in the real (or virtual!) world, then nScale detects these events, and finally acts on them. So, nScale will soon be part of Skynet :-)

Setting up an Auto Scaling group with nScale

You can start using Auto Scaling groups right now inside your nScale system, you just need to add some definitions (if you are not familiar with nScale, check out the docs):

exports.webAutoscaling = {
 type: 'aws-autoscaling',
 specific: {
  ImageId: 'ami-xxxxxxxx', // AMI with Docker installed 
  MinSize: 2,
  MaxSize: 5

exports.autoMachine = {
 type: 'blank-container'

And then use them in your system.js: = 'sudc-system';
exports.namespace = 'sudc'; = '62999e58-66a0-4e50-a870-f2673acf6c79';

exports.topology = {
 autoscaling: {
  awsWebElb: [{
   awsWebSg: [{
    webAutoscaling: {
     autoMachine: ['web', 'doc', 'hist', 'real']

You can use as many Auto Scaling groups you want, and nScale will manage them accordingly.

nScale leaves you in charge, so it does not enable any scaling policies for you. However, you can enable them very easily from the AWS console. In order to enable an Auto Scaling policy, you need to associate it with an alarm, associated with Auto Scaling metrics, ELB metrics, or SQS metrics. For Auto Scaling metrics, you can do this editing the scaling policy in the AWS console, by clicking action and then edit. If you want to use ELB metrics of SQS metrics, you will have to first create an alarm from the Cloudwatch interface and then set the Auto Scaling policy to react on it.

Cloudwatch interface


Then, you need to click on the create new alarm and fill in the relevant details.


New alarm


You should repeat these settings for both the nscale-scaling-down and nscale-scaling-up policies.

The development of this feature was lead by me (Matteo Collina), with a great help from Luca Lanziani, without which this would not be possible. If you want to help contributing, check out this guide.

New  startup process

One of the major culprits of nScale was the messy start/stop commands, which might leave some processes running even in case of stop, if you tried out the development workflow.
The start/stop commands were entirely rewritten by Darragh Hayes, and he also added a fantastic logo on startup. You can now start nScale via an ‘nscale start’ and stop it with ‘nscale stop’. Finally, he added an nscale status command.

nscale start/stop/status commands

The new nScale start/stop/status commands

Running two versions of the same service

nScale now fully supports running two versions of the same service, one alongside the other. The only catch is that you need to specify two different names in the definitions, and add the ‘checkoutDir: “path-in-workspace”’ inside the specific block, like so:

exports.doc = {
 type: 'docker',
 override: {
  process: {
   type: 'process'
 specific: {
  repositoryUrl: '’,
  processBuild: 'npm install',
  checkoutDir: 'doc-v1',
  execute: {
   args: '-p 9002:9002 -d',
   process: 'srv/doc-srv.js'

This feature was ideated by Richard Rodger and Peter Elger.

Improved development workflow

The development workflow using bare operating system processes has been drastically improved, and we added support for rolling back and forward, as well as analysis, and some more clarity in the codebase. Peter Elger championed this work in the last few days at an impressive pace!

Breaking changes

Unfortunately, I have to announce that we introduced a breaking change in 0.16. Due to the way we define containers, e.g. web-abc1234, we assumed that on AWS these names will not clash with each other, so you could deploy more than one environment per region. Unfortunately, this is not true for the Elastic Load Balancer. Thus, we had to change the algorithm for generating that hash so that it includes the environment too. In practice, this means on AWS nScale will recreate the security groups, ELB and instances that you previously created.
Luca Lanziani spotted this bug, and proposed a change.

About nScale

nScale is a toolkit that makes deployment and management of distributed software systems easy. Try it on your software system today and let us know how you get on. Visit to download and install. If you want to get involved in nScale development, please check out the new guide.

nScale represents nearForm’s ongoing commitment to helping node become a mainstream technology and open source is one of the ways that we support that.
If you’d like to know more about nearForm, get to know us here and the team here.

Want to work for nearForm? We’re hiring.


Twitter @nearform

Phone +353-1-514 3545

Check out nearForm at



By: Matteo Collina

Matteo is a software engineer and Internet of Things (IoT) expert with a passion for coding, distributed architectures and agile methodologies. He has worked with a wide range of technologies (Java, Ruby, Javascript, Node.js, Objective-C) in a variety of fields. Matteo is the author of the Node.js MQTT Broker, Mosca, the LevelGraph database, and co-author of the book "Javascript: Best Practices" (FAG, Milan). In 2014, Matteo completed his PhD with a thesis entitled 'Application Platforms for the Internet of Things: Theory, Architecture, Protocols, Data Formats and Privacy'. Matteo is also an experienced conference speaker on the above topics. In his spare time, he builds and contributes to open source software (see his github profile and sails the Sirocco.