Accessing an AWS hosted backend via IPv6

Reaching my API via IPv6 is not something I considered a high priority, but due to my prior experience with AWS I took the ability for granted. Recently I found out that it’s not as simple as I thought, since new AWS accounts do not get access to EC2-Classic, and to my surprise EC2-VPC has only recently started supporting IPv6, and only in us-east-1 with several limitations.

While not as trivial as I thought, there are simple solutions available, so I will describe the how and why of a couple of ways which we recently used at Takumi.

Continuous delivered Dockers via Codeship + Elastic Beanstalk

At Takumi we recently started deploying immutable pre-built docker containers through our CI system, onto our AWS Elastic Beanstalk nodes, while keeping the deployment procedure as simple as:

takumi-server (feature-branch) $ git commit -m "Important feature"
[feature-branch cf7edb2] Important feature
takumi-server (feature-branch) $ git push origin feature-branch

… wait for codeship build

takumi-server (feature-branch) $ cd ../takumi-deployment
takumi-deployment (master) $ dpl deploy takumi-server git_cf7edb2 takumi-server-dev
Deploying 'takumi-server:git_cf7edb2' to 'takumi-server-dev'

Flask and StatsD revisited

A couple of months ago I wrote about automatically emitting statsd metrics for Flask views using a Werkzeug middleware. There was one rather large caveat though: how I dealt with dynamic URL parameters. Optimally I would have matched the incoming request against the available URL rules or routes in Flask, and used the URL rule metadata to generate a stable metric name. To save time I relied upon the fact that all dynamic URL parts in our API were at the time UUID’s.

Adding swap to Elastic Beanstalk

If you’re using small t2 instances on Elastic Beanstalk which only have 1GB or less of memory, you may run out of memory while doing rare, yet memory intensive tasks such as deploying (and/or building) your app. If your app does not require a lot of memory except during those rare moments, increasing your instance size and being overprovisioned 99% of the time is not a solution which should satisfy a good engineer.

ebenv: Elastic Beanstalk environment copy/dump tool

At Takumi we use Elastic Beanstalk, which is a nice API/service from AWS which strikes a decent balance between a heroku-esque simplified service interface for developers, and the hands-on control required by those of the devops persuasion, such as myself. One of the main benefits of using Elastic Beanstalk is how quick and easy it is to spin up new environments, and I make heavy use of that in my work.

Flask and StatsD

I’ve written about StatsD before, but it’s time to pick up the pen again, at least in the proverbial sense (I’m typing this on a laptop-chiclet keyboard). A few months ago I joined a new company: Takumi and we’re building an iOS app married to a Python Flask-based backend. From many perspectives, a very similar tech stack as we used at QuizUp. And it’s no coincidence. One of the founders of Takumi is Jökull Sólberg, who I worked closely with at QuizUp and as far as I know had a major effect on the initial technology stack used there.

Setting up APNS for iOS

Last week we started setting up push notifications on the iOS app we are building at work. I knew from my time at QuizUp that this is more complicated than you’d think, but still I was surprised at the complexity Apple front-loads on people developing for their platforms.

Monitoring at QuizUp: Datadog

One of the services we use a lot for monitoring at QuizUp is Datadog. We use several software-as-a-service’s, but this one is one of my absolute favorites. Datadog is an aggregator for StatsD metrics, and StatSD is as I have mentioned before, one of my favorite technologies. The way we use Datadog is both through their large set of excellent integrations, which retrieve a host of standard metrics from every third party service in our stack, but also monitor all of our hosts for standard operating system metrics like load average, disk usage, memory usage broken down by application, cpu load, etc; and we’ve written our custom integrations if one did not exist before.

redis workload recorder

Recently I’ve been working on some redis profiling and research, and since we run several distinct redis instances at Plain Vanilla (due to reliability and configuration reasons) the necessity to record a certain amount of commands for several different redis instances became rather apparent.

Reinventing the wheel

We all tend to reinvent the wheel once in a while, and often it’s just a question of not having found the right tool with a quick search, or better: we prefer doing something differently and/or we enjoy the process of building something just for the heck of it. This is a small story of me being slightly stupid, but also about UDP and how awesome it is :-)