What About DevScale?

The word DevScale has been rattling in my head for a while now. With my increasing interest in Raspberry Pi, FreeBSD, and Erlang -- combined with the rise in Internet of Things (IoT) -- the word DevScale has started taking a bit more shape.

The past few years have been all about scaling up easily and cheaply. Cloud scale is often bandied about as a marketing mantra for future success. It was preceded by web scale, as in, "Is your database webscale?" That was the time of NoSQL hotness. Now it's all about IoT hotness. Tomorrow something else.

In all this ruckus has the tech community forgotten about scaling down? What about embedded devices, the real IoTs? Or smart phones? Things are moving rapidly in these areas but they're not red on the hotness scale. It appears these are now considered commodities and not worthy of massive web journalism ink.

I think that scaling down is even more important today than it ever was. There are signs of this if you really look. The Atom editor is a scaled down version of a complete web application. Go language has aimed to scale down the sprawl of an application's deployment with a single statically-compiled binary as its artifact. The popularity of Raspberry Pi and its kin in education, robotics, and other uses I'm not even aware of is also not to be overlooked. Nevertheless, movement in this direction is not as hyped as scaling up appears to be.

I define DevScale as making things relevant to a small group of people or devices. Any device or software application that appeals to a single developer is devscale.

Unikernels are kind of devscale; they focus on only one task and trim down any fat around it. Containers -- when used properly -- are also devscale; they're supposed to be one process per container, a much smaller scale than a VM running multiple processes. Microsoft's trimmed down versions of Visual Studio and SQL Server are devscale.

Why is devscale important? Unless the tech community builds and markets things to an individual it will never be able to entice the same individual to then scale up with its offerings. The immediate needs of a person must be met first.

One example I recently found interesting was the availability of a continuous integration (CI) system. Jenkins, Buildbot, Snap CI, Travis, Concourse, etc. all run an organization's CI pipelines at bigger scale and faster speeds. But if I -- as a developer -- wanted to have a simple, scaled down CI to run on my laptop I'd be out of luck. The best I could think of was to use Invoke along with a couple containers to run a tiny CI system for building my branches. There's no popular product out there that does this for me.

I could of course use Travis CI (and I do) but that's not the point. There are times when I don't want to use a service provided by others and to instead use something under my complete control. That is devscale and it's not available to me today.

Configuration management and orchestration tools like Chef, Puppet, Ansible, SaltStack, Terraform, etc. also scale up really nicely but are very hard to scale down. Instead of mucking around with Ansible I could probably get going at a much smaller scale with Fabric. All I need is to run SSH commands and Fabric is eminently sufficient.

The idea of devscale was also inspired by the fine folks at suckless.org. Their mission is to build "quality software with a focus on simplicity, clarity, and frugality." musl libc, busybox, runit, and others are also working with these principles.

It is great to see plumbing projects like these value the same ideals that devscale aspires to. I just want to see this idea expand to other applications. Then maybe we'll have a bunch of tiny tools that do the same job as their cloud scale kin but can easily be wielded by a single developer short on time.