SLC

Written by David Banham

This is a response to the Strongloop post on nodeJS deployment.

SLC looks like a really interesting tool. Bear in mind that I haven’t dug through the code yet. strong-build seems well thought out. The kinds of things it deals with are problems that bite you really hard at the times you can least afford to be bitten. When writing Serious Business applications you simply cannot let a third party registry (npm, github, etc) going down affect your builds.

I would say that running your own registry is a perfectly acceptable way to deal with this, though. What you’re trying to do is put all the important things inside your locus of control. Not everything has to be files on disc.

strong-deploy seems fine, a little bit of sugar to abstract away deployment commands.

strong-pm sounds good. A thing that instruments and manages your node processes. Great!

After that, though, the blog post ended and I got really confused. What orchestrates the strong-pm processes across different machines? This setup seems to assume that you will only deploy processes to one computer at a time. Not only is that a bad idea for availability, it’s not going to work very well at scale.

In drawing analogies to my own system, strong-pm is Cavalry and Field-Marshal and Quartermaster are missing.

Also, it’s good that SLC is built of composable interfaces but it’s unclear whether or not strong-pm can handle languages other than NodeJS. I am hopeful they’ve made it agnostic, but the docs are strangely silent on the issue and it doesn’t get a mention in the blog post.

So, great start, but like so many other open source PaaS’ish tools it completely misses the point, in my opinion. There is still the opportunity to make it great by adding an orchestration tool.