.. title: What About DevScale?
.. slug: what-about-devscale
.. date: 2016-04-05 05:24:05 UTC
.. updated: 2016-04-05 05:24:05 UTC
.. tags: devscale
.. category:
.. link:
.. description:
.. type: text
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.
.. TEASER_END: Read more
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.