If you’ve built a production API before, you’ll know that they tend to
evolve over time. This evolution is not only unavoidable, it is a natural
state that any active system will exist in until it is deprecated.
Realizing and designing to support this kind of evolution in a proactive
way is one of the aspects that differentiates a mature API from the thousands
that litter the Wall of Shame.
At the same time, it is important that your API remains easy to use and
intuitive, maximizing the productivity of developers who will make use of it.
It’s a poorly hidden fact that I love Kubernetes. After spending months running everything from
Marathon DCOS and CoreOS to Rancher and Docker Swarm in production, Kubernetes is the only
container orchestration platform that has truly struck me as truly “production ready” and I
have been running it for the past year as a result.
While functionality when I first started using it (v1.4) was somewhat patchy and uninteresting,
some of the more recent updates have been making sizeable strides towards addressing the operations
challenges we face on a daily basis.
With v1.8, Kubernetes has introduced the CronJob controller to batch/v1beta1, making it
generally available for people to play with. Sounds like the perfect time to show you how we
use CronJobs to manage automated, scheduled, backups within our environments.
One of the most interesting discussions to have with people, notably those
with traditional database experience, is that of the relationship between
an off the shelf RDBMS and some modern NoSQL document stores.
What makes this discussion so interesting is that there’s invariably a lot
of opinion driven from, often very valid, experience one way or another.
The truth is that there simply isn’t a silver-bullet database solution and
that by better understanding the benefits and limitations of each, one can
make vastly better decisions on their adoption.
Docker is become an incredibly prevalent tool in the development and
operations realms in recent months. Its combination of developer friendly
configuration and simple operational management make it a very attractive
prospect for companies and teams looking to adopt CI and CD practices.
In most cases, you’ll see Docker used to deploy applications in much the
same way as a zip file or virtual machine image. This is certainly the
most common use case for Docker, but by no means the extent of its
functionality.
In this post I’m going to discuss some of the more interesting problems
we’ve used Docker to solve and why it serves as a great solution to them.
Aurelia is a modern web application framework in the spirit of Angular,
with an exceptionally concise and accessible developer experience and
standards compliant implementation. It is hands down my favorite web
framework right now and one I’d strongly recommend for most projects.
One of Aurelia’s greatest claims to fame is the incredible productivity
you can achieve, enabling you to build a full web application in just
days, if not hours.
When building the application becomes that fast, spending a day putting
together your deployment pipelines to roll out your application becomes
incredibly wasteful, so how can we avoid that?
Well, Docker offers us a great way to deploy and manage the life-cycle
of production applications. It enables us to deploy almost anywhere, with
minimal additional effort and in a highly reproducible fashion.
In this post I’ll go over the process of Dockerizing an existing Aurelia
web application built with WebPack, however the same process applies to
those built using SystemJS.
With the increasing popularity of Git as a tool for open source collaboration,
not to mention distribution of code for tools like Go, being able
to verify that the author of a piece of code is indeed who they claim to be
has become absolutely critical.
This requirement extends beyond simply ensuring that malicious actors cannot
modify the code we’ve published, something GitHub and its kin
(usually) do a very good job of preventing.
The simple fact is that by adopting code someone else has written, you are
entrusting your clients’ security to them - you best be certain that trust
is wisely placed.
Using Git’s built in support for PGP signing and pairing it with
Keybase provides you with a great framework on which to build and
verify that trust. In this post I’ll go over how one sets up their development
environment to support this workflow.
Anybody who has worked in the development world for a significant portion of
time will have built up a vast repertoire of abbreviations to describe how
they solve problems. Everything from TDD to DDD and, my favourites, FDD
and HDD. There are so many in fact that you’ll find a
website dedicated to naming and shaming them.
I’m not one to add another standard to the mix… Oh who am I kidding, let me
introduce you to Chance Driven Development.
Inki is a small proof of concept project I’ve been working on which is
designed to manage transient, single-use, SSH keys for an automated remediation
tool our team is in the process of building.
In this blog post I’ll go over some of the design decisions motivating
a tool like Inki, some of its interesting implementation details and
the questions we’re hoping it will allow us to answer.
Bash’s ability to automatically provide suggested completions to a command
by pressing the Tab key is one of its most useful features. It
makes navigating complex command lines trivially simple, however it’s generally
not something we see that often.
Bash CLI was designed with the intention of making it as easy as possible to
build a command line tool with a great user experience. Giving our users the
ability to use autocompletion would be great, but we don’t want to make it
any more difficult for developers to build their command lines.
Thankfully, Bash CLI’s architecture makes adding basic autocomplete possible
without changing our developer-facing API (always a good thing).
If you’re just looking to hop straight to the final project, you’ll want
to check out SierraSoftworks/bash-cli on GitHub.
Anybody who has worked in the ops space as probably built up a veritable
library of scripts which they use to manage everything from deployments
to brewing you coffee.
Unfortunately, this tends to make finding the script you’re after
and its usage information a pain, you’ll either end up grep-ing
a README file, or praying that the script has a help feature built
in.
Neither approach is conducive to a productive workflow for you or
those who will (inevitably) replace you. Even if you do end up adding
help functionality to all your scripts, it’s probably a rather significant
chunk of your script code that is dedicated to docs…
After a project I was working on started reaching that point, I decided
to put together a tool which should help minimize both the development
workload around building well documented scripts, as well as the usage
complexity related to them.
